Re: 3 interesting bugs

Hei Clay,

Clay Martin <clmartin@microsoft.com> writes:

> Bug #1:
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8073490/
> This has to do with opening external applications. In Edge this
> causes webdriver to hang (we plan to address this) but I realized the
> specification doesn't really handle what happens if the tester does
> something that would otherwise pull the user out of the context of
> the browser. Not a big deal at the moment for us as we plan to just
> return in this case.

I think Simon covered this, but with regards to the specific bug you
linked, there is actually no prose in the spec to cover what should
happen when interacting with <input type=file> elements currently.  I
intend to fix that this week.

The brief summary is that sending keys to <input type=file> should
trigger implementation-specific steps to ensure the first element of
the `files` property is replaced with a new File object.  If sending
keys to <input type=file multiple>, another File object should be
appended to the `files` property.

Give me a few days to write this down in specalese.

> Bud #2:
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8515651/
> This covers an issue I brought up at the July F2F around the various
> oddball inputs. We have issues "sending keys" to these as they are
> somewhat special, so thoughts on this would be interesting. I'm
> guessing value should just be set and any relevant events fired but
> wanted to know thoughts.

We covered this at our F2F in Boston.  Instead of sending key strokes
as we do for <input type=text> and <textarea>, we will treat all HTML
(5) input elements such as <input type=color> et al. by setting their
`value` attributes directly to the supplied string.

This means sending "#FFB6C1" to <input type=color> will cause its
internal colour state to change to pink.  Or to put it more simply, we
delegate to what the HTML spec tells the browser to do when setting
the property.

Again, this is also uncovered in the current specification draft.  As
above I will fix that this week.

> Bug #3:
> https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/8074852/
> This final one tackles which tab is active vs which webdriver tab is
> active. For Edge after doing a window.open() the active tab is the
> new tab while the webdriver tab hasn't changed (no switch to window
> call). If you execute a get command, the active tab will switch back
> to the opener which is also the webdriver active tab and then do a
> navigate. In Chrome it allows the get to happen in the webdriver tab
> without it being in focus. As this could change what a site does
> (being displayed vs not displayed) it seems like an interesting case
> to consider.

WebDriver has its own idea of what the the current top-level browsing
context is, and this does not necessarily correspond to which is
the currently focussed or active in the browser UI.

This relates back to what I said in my other reply, that in a WebDriver
context it does not matter whether the browser has focus or not.

Because of the stateful nature of the WebDriver protocol I think users
would find it rather confusing if their idea of which top-level
browsing context they were interacting with suddenly changed without
notice.  I can certainly imagine scenarios where a popup would appear
that would cause automation steps to be incredibly tedious to write.

Because the WebDriver protocol isn’t a duplex protocol and does not
have locks, there is no way we could guarantee race condition-free
behaviour if the current top-level browsing context was linked to
whichever one is in focus.

Received on Tuesday, 27 September 2016 13:12:17 UTC