User prompts for "beforeunload" event should not automatically be dismissed #1294
Labels
Comments
|
Hi - this burned us today whilst trying to write scripts to validate the appearance of a prompt on window close - is there some way we can get this addressed, please? This issue has been open quite a long time now. :) |
|
mozilla/geckodriver#1563 |
|
Dear team, are there are news on this one? I agree that the specification currently blocks the use case of testing the user prompts on page reload/exit, and some of the implementing parties claim that they need to be compliant with the spec so I think the first move should be done by the spec community |
jtnord
added a commit
to jtnord/webdriver
that referenced
this issue
Feb 22, 2021
The wording of the current entry implies to some that promots from beforeunloaded are always dismissed and thus the promot is in effect never shown and the user will have no chance to interact with it. This interpretation would lead it to be impossible to interact with them and test them - which seems to be the purpose of the webdriver spec, so this would imply that that interpretation is incorrect. This clarifies the wording to say that the promot is dismissed on *subsequent* navigations, thus if a prompt was shown and a navigation attempt was performed then it would be dismissed, however if the cause of the alter was a navigation then the promot will be shown so that the user can interact with it. fixes w3c#1294
jtnord
added a commit
to jtnord/webdriver
that referenced
this issue
Feb 22, 2021
The wording of the current entry implies to some that promots from beforeunloaded are always dismissed and thus the promot is in effect never shown and the user will have no chance to interact with it. This interpretation would lead it to be impossible to interact with them and test them - which seems to be the purpose of the webdriver spec, so this would imply that that interpretation is incorrect. This clarifies the wording to say that the promot is dismissed on *subsequent* navigations, thus if a prompt was shown and a navigation attempt was performed then it would be dismissed, however if the cause of the alter was a navigation then the promot will be shown so that the user can interact with it. fixes w3c#1294
whimboo
changed the title
|
The Browser Testing and Tools Working Group just discussed The full IRC log of that discussion<jgraham> Topic: User prompts for "beforeunload" event should not automatically be dismissed<jgraham> GitHub: https://github.com//issues/1294 <jgraham> whimboo: This is an older issue. We can't handle beforeunload prompts in webdriver classic. Per spec we always dismiss these prompts during navigation, which makes it impossible to test. In BiDi we have user prompt handling and will implement it soon. Question is what to do with beforeunload handlers. In Firefox we've totally disabled these prompts in WebDriver so it would also affect BiDi. The problem <jgraham> is that we have to make sure that the prompts end up getting dismissed. We have to allow people to test the prompts. Maybe for classic we should have a capability to set a prompt handler? Or maybe we should handle it differently. Should never block closing a tab. <orkon> q+ <jgraham> ack orkon <jgraham> orkon: In puppeteer whenever you close a page there's an option to decide if unload handlers should run, or if they should be ignored. If they run they are treated like alert dialogs i.e. an event is emitted and the prompt can be dismissed or accepted by the puppeteer user. <jgraham> whimboo: Does it work when Puppeteer is closing the browser? <sadym> q+ <jgraham> jgraham: Three cases. 1) Tab closed. 2) WebDriver initiatted navigation, 3) Other navigation. We've discussed page close, but what about webdriver inititated navigations, do they need an option to suppress a prompt? <jgraham> ack sadym <jgraham> sadym: The main problem for the user side is that they want to test what happens with the prompt. Does having an auto-close help with this? <sadym> q+ <jgraham> jgraham: Definitely need an event and a way to respond to it. Question is how that interacts with classic webdriver where we just dismiss these prompts automatically so that they don't interefere with navigation. Other question is related to what Alex said where clients might benefit from having a way to ensure that the navigation command will always return without having to listen for the possibility <jgraham> of a blocking prompt. <jgraham> ack sadym <jgraham> sadym: I meant that as a user of BiDi I'd expect the default behaviour to be that if I start a navigation then it completes. If user wants to test the prompts, would it be enough to have a specific command to close the context without suppressing the prompts? <whimboo> q+ <jgraham> jgraham: I think that might meet the requirements, but it feels a bit strange to suppress the default behaviour except via certian commands / parameters. I think maybe we need a more detailed proposal to discuss? <jgraham> ack whimboo <simons> q+ <jgraham> whimboo: A problem here is what we should do with classic? Do we just want it for BiDi? Could block commands in classic. People wanting to test these prompts might have to use BiDi, so we don't need to change classic. <jgraham> ack simons <jgraham> simons: From Selenium experience, I don't recall people wanting to test this. We do want to be able to refomulate classic on top of BiDi, but that should be possible with events. My favoured position is to leave classic with the existing behaviour and add the new behaviour to BiDi. <jgraham> jgraham: Are you thinking of classic as "specifically when HTTP kicks off a navigation" or "any sesssion with the HTTP protocol enabled"? <jgraham> simons: I think it's any time the HTTP protocol is enabled. <patrickangle_> q+ <jgraham> simons: If a session has both classic and bidi enabled then it should use the bidi events for the prompt. <jgraham> simons: For BiDi you'd need to subscribe to the event. Classic would dismiss the prompt. So you'd get a notification that the dialog happened, but it would be automatically dismissed by classic. <jgraham> ack patrickangle_ <jgraham> patrickangle_: I think it would be unfortunate for the behaviour to be different between a classic command and a bidi command. But it seems like we can't change how classic works when you introduce bidi. I'm not sure how to solve that, but I find it concerning. |
|
Note that there is ongoing work for extending WebDriver classic for WebDriver BiDi purposes on PR #1791. |
|
This should no longer be a problem with a recent Nightly build of Firefox 129. By default As such I'm closing this issue. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In my opinion Section 18 contains not correct logic.
Example:
If we have onbeforeunload event and user try close window:
In chrome 68.0.3440.106 user should interact with promt before window will closed.
In firefox 61 user should interact with promt before window will closed.
In firefox 62beta user should interact with promt before window will closed.
In firefox 63nightly user should interact with promt before window will closed.
But in automated test with geckodriver we have different behavior.
geckodriver 0.21.0 silently set dom.disable_beforeunload to true. (in firefox 61, 62, 63)
and when test close window promt not showing and window closed.
It is different behaviour.
The text was updated successfully, but these errors were encountered: