Re: 3 interesting bugs

Hi Clay,

Responses inline.

On Mon, Sep 26, 2016 at 8:08 PM, Clay Martin <clmartin@microsoft.com> wrote:

> Hey everyone,
>
>
>
> Ran into three interesting bugs that I thought might be worth discussing
> as they pertain to the specification:
>
>
>
> 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.
>

It's an interesting problem. With the original IE driver, we detected that
someone was about to type into a file input element, and added special
logic to handle the dialog box. In previous f2f sessions, we discussed
allowing users to set the values of the INPUT element types introduced in
HTML5 by using the string representation that the browser would return.

My personal feeling is that if someone decides to wander into the world of
pain that's interacting outside of the browser, then it's fine for that to
be completely undefined behaviour. Having said that, freezing is less than
ideal. :) FWIW, it's what we used to do when a modal dialog opened, so even
if it's less than ideal, it's something our users have seen before.


>
>
> 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.
>

See above: we discussed allowing users to set those values using the string
representation of the value to be returned. You'd need custom handling in
each driver, but I guess that'd be the case anyway (after all, who knows
whether these are native UI components, something clever done with the
Shadow DOM, rendered via the HTML engine...)


> 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.
>

 The really, really early versions of webdriver used to track whichever
window the browser had currently opened. In your example, the call to
"window.open" would have caused webdriver's "active window" to be the new
tab. Turns out, users found this behaviour incredibly confusing,
particularly when sites opened unexpected pop-overs or pop-udders.

It'd be helpful to users if, when under control of webdriver, the tab
currently focused in the UI was the tab that was webdriver's active window.
Of course, this might be problematic if there's different behaviour between
focused and unfocused windows. I'd imagine the other choice would be to
ensure that webdriver's active tab was focused on each method call.


> Thoughts on these? Feel free to share any bugs you all find target more
> gray areas of the spec, I find them interesting!
>

Very interesting. Lots of fun to think our way through these :)

Simon