- From: John Jansen <John.Jansen@microsoft.com>
- Date: Wed, 24 Jun 2015 19:56:53 +0000
- To: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
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 19:57:23 UTC