WebDriver F2F meeting July 2016 -- 14 Jul 2016

RRSAgent: Yo, wazzap?

RRSAgent: hello

RRSAgent: please make these logs world-visible

RRSAgent: please draft the minutes

RRSAgent: please make these logs world-visible

<scribe> scribe: ato

<scribe> scribe: Andreas Tolfsen

<scribe> scribenick: ato

chairnick: AutomatedTester

RRSAgent: please draft the minutes

<AutomatedTester> presents+ AutomatedTester

scribe- ato

title: WebDriver F2F meeting July 2016

RRSAgent: please draft the minutes

RRSAgent: drop scribe ato

RRSAgent: please draft the minutes

Agenda review

JohnJansen: The Edge performance PM wants to talk to the WG.
... Best around lunch.
... This is Tod.

ClayMartin: I wanted to talk to extensions.

ato: People have to leave early.
... JohnJansen needs to leave early.
... We should prioritise what JohnJansen thinks is important.

JohnJansen: I mentioned tests, but maybe we should wait.

Self-signed certificate handling

<AutomatedTester> scribe: AutomatedTester

ato: We had a discussion at Mozilla and had a number of concerns
... 1) Implementation specifics 2) and the security issues
... Selenium has the acceptUntrustedSsl

jimevans: only the FirefoxDriver can support this

ato: I was actually wondering that, it is probably because Firefox has its own NSS db
... Safari and IE uses the system stores

jgraham: Is this implementable for everyone?

brrian: Implementation and security are 2 issues here.

jgraham: this is our issue...

ato: we have concerns about the increased attacked surface...

ClayMartin: if webdriver is on the machine and starts the browser we are past the point of protecting the users

ato: for Firefox we could create the cert in the profile and put it through

brrian: safari we dont have profiles so we dont have this approach
... and while it could be done the browser team might be totally against this...

jimevans: the end users of webdriver often have very little control against the machine they are testing against.

<lukeis> https://w3c.github.io/webdriver/webdriver-spec.html#invalid-ssl-certificates

jimevans: this is unfortunately the reality...

ato: I agree, my concern is with the design...
... we could pass in a list of whitelist approach of domains to support

brrian: this is more realisable if it is using the whitelist approach

JohnJansen: we don't worry about it... if you have webdriver you machine is not secure anymore.

jimevans: in IEDriver you can install the cert in the cert store

brrian: we ship safaridriver in the OS

samuong: we ignore ssl certs, we use the flag thats in chrome

ato: it would be good to have the ability to to check the cert is invalid

samuong: acceptUntrustedSsl does this already

ato: yes, but I dislike the design
... the other question, do we like the current design. Currently it is only a boolean, it might be better to have a whitelist

brrian: the whitelist idea is a more palatable idea for security.

jgraham: what are the usecases here that we are trying to support?

brrian: testing mixed-content
... if you can't install a cert to your cert store on mac, you can't run safaridriver either

automatedtester: does anyone get telemetry on certs?

samuong: no, we dont currently

JohnJansen: we do, let me look
... no, we dont have this specific telemetry.

<scribe> ACTION: All vendors need to go speak to security teams about supporting this concept. Should we have whitelist ssl certs [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action01]

jimevans: the OSS project currently makes people opt into accepting selfsigned certs

samuong_: so what should we do since the OSS project is the opposite of the spec?

ato: we should move to the OSS way

brrian: what should we do with the error?

jgraham: that's badly spec'ed, we should move it to go()

<scribe> ACTION: ato to fix this ssl cert (chap 8) [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action02]

break

RRSAgent: draft minutes

<ClayMartin> scribe: ClayMartin

ato: We basically found out that every possible combination that is possible to do with webdriver and whatnot that no one is doing the same thing

samuong: It will break some users

JohnJansen: What will break some users

samuong: That we change the default of handling certs
... The default right now is that we accept invalid certs

jimevans: There is only one driver that allows invalid certs in the open source project, and that's firefoxdriver
... That is the only driver that attempts to do any manipulation of acception/rejection of ssl certs
... chromedriver starts with it accepted, iedriver doesn't handle it as it can't and I don't know what the edgedriver does
... So there is only one case in which the user can set a setting to manipulate ssl certs. The default for that one case is to not accept them.

ato: So the default behavior of the browser

jgraham: So for completeness if I understood correctly edge supports the current spec

JohnJansen: I think so yeah and it doesn't matter what the default is because you're already insecure

jgraham: I think to the extent that you're able to change it at all isn't a security feature

brrian: Its not like you can just change security willy-nilly because you have webdriver running

jgraham: When I say it's not a security feature I mean that you can change it at all it's no longer a security feature. If you can't accept invalid ssl certs then it is.

ato: So brrian are you positive that you would get the ability to implement something, like the ability to accept unsigned certs at all. Whether you're allowed to will determine if it's opt-in or opt-out.

brrian: If I went to them (security team) and said I'd like to make invalid certs acceptable they'd (security) say no

samuong: I'm not sure how safari driver works can it launch safari?

brrian: Yes

ato: My point earlier is that if Safari isn't able to implement it that it should be disabled in all browsers for interop reasons

brrian: Making default less secure is not doable. Some flag to opt-in to less might be okay.

samuong: Whether we make it true/false by default depends on the vendor.

ato: I'm going to rewrite the section (section 8) to be flipped. Would like to do that now and if necessary we can flip it back.

<scribe> New topic: Should it be possible to navigate to malformed URLs

samuong: Why do we want this?

jgraham: I don't think we do

<JohnJansen> RSSAgent: draft minutes

jgraham: At the moment the spec gets a string and tries to pass that into window location. It's not clear what should happened if that string isn't something that can be passed as a url.

ato: the idea of webdriver is that it should behave as if you typed something into the web browser

<JohnJansen> RRSAgent: draft minutes

ato: the idea of an address bar doesn't exist in the web platform
... so what we need to do is call the navigation algorithm in html

jgraham: the way it is specified at the moment is that sending a go command in wbedriver is more or less like clicking a link

brrian: does it have a referrer?

jgraham: possibly

ato: the point is that when you navigate to html you always start with something that is valid

jgraham: there are strings one can use that aren't valid urls of any kind. it's unclear what should happen if you create such a string and try to navigate to it.

ato: firefoxdriver returns invalid if you try to navigate to a bad url
... I think we need to be explicit that if it's not possible to navigate to the url we return an error

brrian: At what level is that supposed to happen?
... is it supposed to bypass other things like search

jgraham: yes

brrian: in any case it should return some form of an exception. the thing that isn't clear is what sorts of urls do we want to allow navigation to
... in osx there are all sorts of protocols to open an app, what about those?

jgraham: I think you could use webdriver for special url cases

samuong: the way it works in chrome is that a page can register a handler

ato: I think that's possible in firefox

jgraham: two issues - 1 is invalid url. 2 is a scheme that isn't straightforward
... 1 we agree on. 2 we don't want to specify as its browser-specific

JohnJansen: Why can't we just pass it into the navigation pipeline. In edge a normal string will do a search

ato: that's not interoperable

jgraham: I say we do what the browser wants because it can vary browser to browser

<scribe> ACTION: jgraham to check what the navigation algorithm says about specific schemes [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action03]

RESOLUTION: return malformed url error on being passed a url string that cannot be parsed

RRSAgent: draft minutes

<scribe> new topic: relative urls

samuong: no
... no to supporting relative urls (everyone laughs)

jgraham: why not? you go to the site, why not allow relative from there?
... go already navigates the top level navigating context

jimevans: you assume a level of competency that doesn't exist for webdriver users
... by enforcing absolute urls we eliminate the possibility of confusion as to where the next navigation is going

jgraham: it would just return a 404 as always and it would be clear what you did wrong

jimevans: no it would not be for the typical end user

ClayMartin: WebDriver doesn't have a context of a site

jimevans: it doesn't

jgraham: once you navigate to a site it sets the context

jimevans: you have the semantics of a method, driver.get, that between two subsequent calls using the same input you could have different bahvior
... case 1 - instantiate driver, use /foo, throws invalid
... case 2 - instantiate driver, go to x.com, use /foo and it works
... many webdriver users aren't sophisticated in that way
... those of us who work on browsers and automation forget that there is a large population of webdriver users who do not have that level of sophistication.

jgraham: seems difficult to believe that if they don't understand relative urls would be able to write a test to navigate the dom tree

samuong: why can't they just concat the string in their test code

brrian: so they don't know the web. why use relative urls

jimevans: what's the reason to use it instead of just using a full url?

ato: that it saves work/time

samuong: you can just get the current url and go from that

<JohnJansen> ato: mimics the web

brrian: it's a normal way to do a navigation

ClayMartin: navigation is the top most navigation context

samuong: users don't use relative urls

jgraham: define users, users use google
... if offers convenience to use relative urls

samuong: if you're in a state that you don't know what your full url is do you really know where you are in the website

brrian: are there tests in web platform tests that test relative urls

jgraham: there are tests for a browser

johnjansen: those tests have you click on the relative links

jgrhaam: tests that test web platform tests use relative urls all the time

claymartin: I've always thought conceptually about navigation being the top-level navigation

jimevans: I agree. I've never heard users demanding this

johnjansen: yeah

jgrahan: well I've just asked for it so you have :)

brrian: what about #someid

jgraham: if you're using some fancy new javascript framework what if it adds the hash but doesn't do a page load

samuong: if a user edits a fragment of the url it doesn't do a full navigate

atuomatedtester: firefoxdriver currently doesn't do a full navigate for this

johnjansen: in specific use cases it would be nice to write a webdriver test that can go between different hashes

claymartin: I don't see the benefit outwaying the costs if the argument is it makes thing simpler

brrian: It depends. why not let users use relative urls

<brrian> lukeis: send help

jimevans: I am out of consensus

johnjansen: the spec implements this in the same as window.location is an interesting proposal

jgraham: then that makes it more complicated. I view it as window.location.href

RRSAgent: draft minutes

<jgraham> https://html.spec.whatwg.org/#dom-location-href

we are skipping element retrieval and window handling

<scribe> new topic: extension testing

<ato> Scribe: ato

ClayMartin: We have an extension testing API.
... In that there are basic commands.

jgraham: Web extensions?

ClayMartin: Now that we have extensions, our developers are asking if they can test it using WebDriver.

<JohnJansen> https://github.com/MicrosoftEdge/webdriver/pull/4/files

ClayMartin: I would argue that WebDriver should have APIs that allow extension testing.
... [explains the complexity of extensions]
... The document related ones are already covered by content-WebDriver.
... But people want access to things such as background scripts.

brrian: Does that have a window context?

samuong: There is a background page in Chrome that the execution context run in.
... It’s essentially another page.
... In chromedriver we expose that.
... The extension is able to send messages between content and the background page.

brrian: What is the lifetime of the background page?

samuong: Complicated.
... You have the click the toolbar to get the background page to start up.
... They use sendMessage, and sends a message to the extension to launch the extension (background script document) because there is no WebDriver primitive for that.

ClayMartin: They can already get into content.
... But not background.
... Another use case is wtich to the popup window.
... There is a lazy-loading problem here.
... Are we ok that a WebDriver command would open the UI of the browser? And be able to dismiss that as well? Are we comfortable with that?
... Right-click context menu entrie.s

https://developer.mozilla.org/en-US/Add-ons/WebExtensions

ato: I think this is interesting.
... Marionette already allows you to interact with the UI.
... But it is not possible to switch into the background page execution context.
... And that is something we would potentially also be interested in.
... Because most browser vendors appear to be consolidating around the Web Extension API, I think it would be interesting to look into this in the future.
... But it should/will not be part of WebDriver L1.

brrian: I don’t think Safari does a full background page.

samuong: It is a global thing that doesn’t tie itself to any one tab.
... If you close the tab it shouldn’t shut down the extension.

ato: You can implement this under a vendor namespace.
... Marionette has ability to switch to contexts. Potentially it would be possible to have a "background" option there.
... … but it would have to be specific to each extension.

AutomatedTester: This is one of the things that are nice about the Marionette design. You are always in the WebDriver API.

ClayMartin: I think maybe that’s an interesting API design.
... We can do it initially using UIA.
... I just wanted to air the idea.

brrian: Apple is moving towards app extensions.

brrain: Your app provides a separate binary that can IPC to a script context on the page.

s/brsun/brrian/

ClayMartin: Do you have pop-ups in Safari?

brrian: You can add context to toolbar items, etc. (Yes.)

[discussion between ClayMartin and brrian about implementation specifics]

<JohnJansen> Todd Reifsteck <toddreif@microsoft.com> joins the room

Meeting with Edge performance PM

todd: We do performance measuring on top sites.
... We are using WebDriver to do this.
... But different browser vendors do different things.
... We navigate, wait a few seconds so we don't interfere with the page, then we return the performance.timing events.
... Then we either sleep or check again, or we pull the rest of our data.
... We have observed that Chrome and Edge on Windows have similar performance.
... But Firefox has much worse performance compared to if we do the same testing manually.
... We don’t really understand why.
... I want to get a take from people in this group, who are very knowledgable about WebDriver, to why this is.
... Because I imagine normal tests also want to be able to do this.

jgraham: How do you navigate?

ClayMartin: The get command.

samuong: So you are fetching traces?

todd: No.
... Just the performance object.

ClayMartin: navigation event start/end

todd: Functional tests written in WebDriver, i imagine a scenario where we can use this as a regression tool.

ato: I have mixed experiences with turning performance testing tools into regression tools in the past.

jgraham: Typically you don’t do this against live sites.
... You do it against cached sites.

todd: yeah.
... We are doing it enough times, that over time the network and cache, the variance should not matter.

brrian: Well…
... How do you control the variants in load time?

todd: You are referring to regressions?
... So there _is_ variance.
... But over hundred and hundred of loads, that variance should be minimised.

brrian: Or just different content in different browsers.

jgraham: Returning to the question.
... I don’t think anybody here actually worked on FirefoxDriver.

AutomatedTester: I worked on it.
... I am going through the code now.

jgraham: FirefoxDriver is going away.
... It is being replaced by Marionette.

AutomatedTester: The mechanisms are different.

jgraham: It might have different performance.

AutomatedTester: FirefoxDriver creates for a listener that waits for the page to load.
... FirefoxDriver has different checks for fragments, and things like that, and sometimes it will return quicker even if it has gone through some of the listening.
... And this is where some of the variance might appear.

todd: Because FirefoxDriver is injecting code on navigation, this could explain it.

JohnJansen: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/WebDriver

AutomatedTester: Once you start adding event listeners you are going to slow things down.

jimevans: [shows on whiteboard how to enable Marionette]

ClayMartin: I guess the question is, for initial navigation WebDriver might not be the best bet.
... But for _user testing_, simulating a user testing a browser, what other way would you have?

AutomatedTester: You need to make sure that your website has no variance at all.
... The website might change.
... You can’t just go to techcrunch.com every day.

samuong: Chrome does something simliar. We replay a session.
... With static content.
... Recorded sessions.

AutomatedTester: In a general sense it would be better to use HAR.
... This is how I’ve done it in the past.
... But this is from an end-user’s point of view.
... It’s not necessarily how a browser vendor would test.

todd: I feel that WeBDriver should be of minimal impact on the browser performance.

jgraham: Nobody wants WebDriver to be slow.

brrian: SafariDriver is going to be slower in creating a new session because we need to start without giving access to user data.

todd: We’re seeing this.

brrian: There’s a tonne of roundtripping.

jgraham: The design of WebDriver is not fast.

jimevans: Yeah.

<JohnJansen> lukeis: I sound exactly like siri with 2 cups of coffee

ato: It’s not a duplex program. It’s a request-response protocol.

todd: Right.
... I think the feedback is, switch from Firefox to Marionette.
... It’s not a core-tenant of the WeBDriver goal that performance testing is part of its top aspirations.
... It probably _can_ be used for performance measuring, but you need to be cautious with your methodology.

JohnJansen: Lunch?

[consensus]

<AutomatedTester> RRSAgent: draft minutes

RRSAgent: no listen

RRSAgent: nolisten

RRSAgent: please draft the minutes

<brrian> https://www.irccloud.com/pastebin/m6BPbXOY/missing-logs.txt

<jimevans> [Discussion about HTML5 controls and the need or lack thereof for separate end points for setting those values]

<jimevans> brrian: What's the common attribute of these controls?

<jimevans> jgraham: File upload input values can't be set through the DOM

<jimevans> jgraham: For most things that degrade back to a plain text input, you can set or get the value, but this is not so for type="file"

<jimevans> jgraham: Conceptually, sendKeys is the wrong command for this, because the user clicks on the button to bring up the file picker

<jimevans> brrian: Are there other places where we mitigate that?

<jimevans> jgraham: There are alerts (user prompts)

<jimevans> samuong: This seems like it's going to break a lot of things

<jimevans> JohnJansen: This feels hacky, but it's been around for a really long time, so we probably shouldn't mess with it.

<jimevans> [Discussion of what DOM methods allow one to do with inputs of type="file"]

<jimevans> jgraham: I am slightly concerned that users would think that using Actions would work similarly to sendKeys

<jimevans> ato: But since sendKeys is a "do what i mean" method, it doesn't work the same way.

<jimevans> ClayMartin: so do we need to specify this? Because it's not in the spec.

<jimevans> ato: No, it is in the spec (step 11 in the sendKeys command)

<jimevans> ACTION: ato to produce language on handling HTML5 form controls in sendKeys command in spec. [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action04]

<jimevans> jgraham: Another thing that is weird in a similar, but not exactly analogous way, are things like video and audio elements

<jimevans> brrian: Yes, there are lots of controls inside such an element.

<jimevans> brrian: These are often implemented using shadow DOM

<jimevans> brrian: I don't know how you'd interact with any of these with WebDriver

<jimevans> ato: I imagine I'd pass the element into a helper class in my language that would handle these.

<jimevans> samuong: But these should be saved for level 2

<jimevans> samuong: I think we can agree that using sendKeys for file upload is weird but we shouldn't mess with it now.

<jimevans> AutomatedTester: We did at one time consider returning more information when finding elements so that language bindings could provide appropriate helper classes

<jimevans> ato: You're talking about serialization of more information than just the UUID.

<jimevans> ato: And it's future-compatible.

<jimevans> AutomatedTester: In a future version of the spec, perhaps we could do this.

<jimevans> ato: for example, I can envision that one thing we might want to do for a video element is to produce a subset of end points under /video. But that's the "multimedia extensions for WebDriver"

<jimevans> brrian: These should be specified, but under separate cover.

<jimevans> RRSAgent: draft minutes

<brrian> https://www.irccloud.com/pastebin/7T43SvXG/missing-logs.txt

file: ///home/ato/1/webdriver/webdriver-spec.html#element-displayedness

https://w3c.github.io/webdriver/webdriver-spec.html#element-displayedness

brrian: file:///home/ato/1/webdriver/webdriver-spec.html#element-interactability
... https://w3c.github.io/webdriver/webdriver-spec.html#element-interactability

<AutomatedTester> MikeSmith: hey, we need to edit the RRSAgent minutes, we werent logging something, how do we do that

<ClayMartin> Scribe: ClayMartin

<scribe> New Topic: Window Serialization

ato: Let's start over. So execute script allows you to return the window object. The window object is serialized in the same fashion as an element.

jgraham: When it serializes this it assumes a 1:1 relationship between window proxies and either frames or actual windows (browsing contexts) which is not the case. For example you could have a window proxy object, close the window, and then return it.

ato: You're saying that since we associate the window handle with the browsing context, at the point where we return the window object, that window handle might not exist?

jgraham: Yeah.
... Or you could have navigated with document.open.

jgrhaam: So I think this is just a correctness thing though I'm not sure what we should do in this case.

ato: There's a distinction in HTML between the window object and the window proxy object. The window proxy object always stays the same. For example in the javascript context, when you have the lowercase window reference, that is always visible. It's always a pointer into the new window.
... So jgraham's point is that by the time you change that window object you lose that browsing context.

jgraham: Each browsing context has one window proxy object, but the reverse is not true.

ato: So by the point we try to serialize that proxy object, the corresponding browsing context might have disappeared and we don't know window handle so what do we do in that case?

jgraham: Maybe in this case it should just throw an error.

ato: You think so?

jgraham: What else should you do if the window closed?

ato: I can imagine this could happen with the wpt test harness if you do something crazy.

jgraham: The whole point of adding this is that it gives you a way to know the window that you opened rather than having to guess that.
... If you open/close a window and try to get it's handle maybe throwing an error is the reasonable thing to do.
... I would also be happy with some special value that also looked like a window.

<scribe> ACTION: ato and jgraham to figure out what to do with discarded window proxy objects that have discarded browsing contexts. [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action05]

ClayMartin: Any more thoughts? Are we done?

ato: I think so.

RRSAgent: draft minutes

Tests

ato: The meeting before last I was sort of charged with coming up with an implementation for a testing harness for the spec. The goal was that it needed to be embedded in the wpt framework. We now have a harness written in python. They use the pytest framework that lends itself really well to writing tests of this style. There is one example of this in the

wpt repo under the webdriver directory. There is also a PR open if you search webdriver on the repo. lukeis has reviewed it but ato still needs to merge.

brrian: Is the test sending raw requests out or?

ato: Good question. The original was using the python client. We needed to have a webdriver client that was a bit special: send raw data, packet introspection, etc. So jgraham had written a client for Servo and we imported that into wpt.

brrian: Are there tests that use it?

ato: Yeah, it's a little different from your normal clients.
... But I've also written what's in pytests called fixtures. I've written a fixture that allows you to have an HTTP client and by default knows about the webdriver server so you can write http.send and construct your own payload.
... It does not start a new session explicitly when you start sending raw commands to it.

brrian: So is there some sort of object model for a session or?

ato: Yeah the client gives you back a JSON object.
... I think that this is fine. Writing tests at the protocol level here is very easy.
... We need to be more granular than the Selenium tests.

brrian: I appreciate being able to tune that but am worried if we change some minor thing we'll need to rewrite all the tests.

jgraham: It has an API if you're testing at that level.
... If you're not testing the message handling at that endpoint then it has a higher level API.

ato: I can show you an example.

brrian: That would be fantastic.

<ato> brrian: https://github.com/w3c/web-platform-tests/pull/2752/files#diff-ec48a9aa5e79c6e2946029bfeb9fbd6dR74

<MikeSmith> AutomatedTester, about that minutes https://www.w3.org/2005/02/minutes

RRSAgent: draft minutes

<MikeSmith> AutomatedTester, anybody who has a local log of the channel can upload it there to produce formatted minutes. I can then publish them

<scribe> ACTION: ato need to normatively link to the HTTP spec [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action06]

<scribe> ACTION: ato and jgraham to have test suite test head requests for GET [recorded in http://www.w3.org/2016/07/14-webdriver-minutes.html#action07]

<AutomatedTester> https://github.com/seleniumhq/selenium/wiki/jsonwireprotocol#resource-mapping

Head Requests

ato: I think we should be good citizens and support it.

brrian: Just by referencing the HTTP spec we're good citizens.
... I think it's more important to test the right error codes.

ato: Let's not get into details on who implements what.
... No resolution at this point, we have actions on referring to the HTTP spec.

RRSAgent: draft minutes

Tests

ClayMartin: Why don't we want to divvy out the tests?

AutomatedTester: We can but historically that doesn't work.

ato: I support AutomatedTester in that.
... I'm happy to keep working my way through it and if there are incidental contributions I'm happy to accept those.

AutomatedTester: I'm happy to have people throw interns at it or people who have the capacity to test the spec.

samuong: Who is blessed enough to have the engineering resources to do it.

ClayMartin: I can do it in my free time.

ato: The W3C requires two independent implementations.

AutomatedTester: We don't have to use the web platform tests for this, we could use the Selenium tests.

ato: The selenium tests are going through a shim that might affect results.

AutomatedTester: I could see Mozilla not having enough resources to do this within the next three months. The amount of tests we write will decrease to make sure we have parity with firefoxdriver is more important than writing tests.
... Just need to find time to do that. Biggest priority is finishing Actions and then getting parity with firefoxdriver.

RESOLUTION: If people can contribute please do!

AutomatedTester: JohnJansen was working on a way to annotate the spec to show what tests run.

RRSAgent: draft minutes

- DRAFT -

WebDriver F2F meeting July 2016

14 Jul 2016

Attendees

Contents

Agenda review

Self-signed certificate handling

Meeting with Edge performance PM

Tests

Head Requests

Tests

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output