This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In Section 15.1 It initially states that the remote end must handle the dialog via accept or dismiss, but then says that calls should could come from the local end. (Now that I am rereading it, I think it means that these alerts should act like all other alerts?)
Making dialouge handling on onbeforeunload a special case seems unneccessary. Especially considering that the text is ambigeous about the remote end's responsibilities. It goes on to contradict itself in the next paragraph: “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.” We normally expect the users of the API to know when to expect alerts and handle them accordingly. My suggestion is to treat modal dialogues on onbeforeunload as regular unexpected dialogues that will make the next command return an unexpected alert status.
The very reason alerts fired from onbeforeunload may deserve special consideration in the spec is that typically[1] they will be thrown *during* the time when remote end executes a command, like this: 1. page with onbeforeunload="alert(1)" is loaded, no alert is thrown 2. remote end receives a GET command to navigate away from that page (no alert active when remote end starts handling the command) 3. mid-way into executing GET command, the alert(1) gets fired. An alert may be fired from an onbeforeunload handler, but not during webdriver remote end executing a command, for example: 1. page with onbeforeunload="alert(1)" is loaded, no alert is thrown 2. while loading the page registered an asyncrineous action (a timer) that navigates away from the page (no alert is thrown still) 3. the timer fires off, navigation starts, navigation is interrupted by the thrown alert (but no webdriver command was executing at that time) 4. now webdriver remote end receives a command; when handling that command the remote end detects an alert; remote end handles that alert as any other normal alert Maybe the spec should be special casing the alerts that are initiated *while* remote end was executing a command (for example those thrown by onbeforeunload while executing a navigation com ? (and not al
[Please ignore Comment 2, I sent it before it was finished.] There is https://www.w3.org/Bugs/Public/show_bug.cgi?id=28968 that covers "normal" modal dialogs: those that are active when remote end *starts* executing a command. [example1] I propose this bug should cover modal dialogs that *become* active *while* remote end executes a command. [example2] Note that such alerts won't only be thrown by onbeforeunload, but example2 below shows how onbeforeunload="alert(1)" almost guarantees that to happen. A page with onbeforeunload="alert(1)", basically, renders webdriver unusable (any command including close() and quit() will provoke an alert and remote end will return an error) unless the spec provides a way to deal with that. One possible mechanism for dealing with them spec may provide is via "unexpectedAlertBehaviour" capability (currently implemented by FirefoxDriver and probably not any other driver). It could have 3 valid values "error", "dismiss", "accept" ("error" is the default). [example1] 1. page with onbeforeunload="alert(1)" is loaded, no alert is thrown 2. while loading the page registered an asynchronous action (a timer) that navigates away from the page (no alert is thrown still) 3. the timer fires off, navigation starts, navigation is interrupted by the thrown alert; alert is active (no webdriver command was executing at that time) 4. now webdriver remote end receives a command; when handling that command the remote end detects the modal dialog; remote end handles that alert as any other normal alert (it becomes an "unexpected modal dialog" if the command remote end handles should fail because of it) [example2] 1. page with onbeforeunload="alert(1)" is loaded, no alert is thrown 2. remote end receives a GET command to navigate away from that page (no alert active when remote end starts handling the command) 3. mid-way into executing GET command, the alert(1) gets fired.
"unexpectedAlertBehaviour" capability is on the heavy handed side to me. It should work well for those who crawl the web and don't acare about the alerts. But some other user may not like to enable unexpectedAlertBehaviour=dismiss for the entire session. A way to unexpectedAlertBehaviour=dismiss (or accept) mode for one specific command would be nice.
this is done in the specification
(In reply to David Burns :automatedtester from comment #5) > this is done in the specification This is not done! So we need to be able tot handle user dialogs and the current specification needs to be updated. Chapter 17 needs to be updated to handle all cases. We need to add prose that allows us to do get() and then go through steps and check that onbeforeUnload
*** Bug 25106 has been marked as a duplicate of this bug. ***
*** Bug 28968 has been marked as a duplicate of this bug. ***