- From: Luke Inman-Semerau <luke.semerau@gmail.com>
- Date: Wed, 24 Jun 2015 13:36:52 -0700
- To: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
Yes, your statement is correct and I think to the intention of the spec. Wording is hard :) The spec is also meaning to convey that when the Unexpected alert error gets raised, the Remote End also dismisses the dialog (and it's configurable whether that be a "dismiss" or an "accept" in the case of a window.prompt() or window.confirm().... although I would think there's an edge case here regarding prompt and an auto 'accept' with a blank value would cause javascript to re-prompt). On Wed, Jun 24, 2015 at 12:56 PM, John Jansen <John.Jansen@microsoft.com> wrote: > In the spec[1] it says, > "The remote end SHOULD have a mechanism to allow unexpected modal dialogs to be closed to prevent the remote end from becoming unusable. The default for this should be dismiss. The local end SHOULD allow a capability to be set that allows the default value to be overridden with accept. The local end SHOULD also allow setting the default behaviour to wait for a command to handle the modal. If the next command does not interact with the modal it MUST return a Unexpected alert open error to the local end." > > It is not clear how webdriver is supposed to know that the dialog is unexpected and then retain state so that the next action (that was meant to happen to the page, but actually happened to the modal dialog) is supposed to be stored. > > Current behavior for ChromeDriver seems to be that the test just times out. Since the modal is unexpected, the test fails, and the test author then needs to update the test. I expect most test authors have an 'unexpected alert open' exception handler in their code. Is this meant to replace that? > > I believe the design should be something like this: > "If a modal dialog is shown and the next command does not interact with the modal the remote end MUST return an Unexpected alert open error to the local end." > > And then we just let individuals deal with it how they want to, rather than add the complexity to the driver itself. > > Thoughts? > > Thanks! > -John > > [1] https://w3c.github.io/webdriver/webdriver-spec.html#sendkeys-1 >
Received on Wednesday, 24 June 2015 20:37:19 UTC