"Accept Alert" and "Dismiss Alert" should check for remaining user prompts
Categories
(Remote Protocol :: Marionette, enhancement, P1)
Tracking
(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63 wontfix, firefox64 wontfix, firefox65 wontfix, firefox67 wontfix, firefox67.0.1 wontfix, firefox68 wontfix, firefox69 fixed)
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | unaffected |
firefox61 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | --- | wontfix |
firefox64 | --- | wontfix |
firefox65 | --- | wontfix |
firefox67 | --- | wontfix |
firefox67.0.1 | --- | wontfix |
firefox68 | --- | wontfix |
firefox69 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
()
Details
Attachments
(2 files, 1 obsolete file)
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Assignee | ||
Comment 3•6 years ago
|
||
Updated•6 years ago
|
Comment 5•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 6•6 years ago
|
||
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Updated•6 years ago
|
Comment 8•6 years ago
|
||
Comment 9•6 years ago
|
||
Comment 10•6 years ago
|
||
Assignee | ||
Comment 11•6 years ago
|
||
This bug is unblocked now! But I will wait with landing the patch until early next week, just to make sure no regression from landing the patch on bug 1370630 causes backout hell.
Assignee | ||
Comment 12•6 years ago
|
||
Workaround until we have a sane dynamic user prompt implementation
(see bug 1477977). At least for now this patch will give us the
opportunity to handle multiple open user prompts.
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 13•6 years ago
|
||
Note that we only want to land this patch for 69, but not 68 because bug 1487705 won't be fixed for that ESR release.
Updated•6 years ago
|
Assignee | ||
Comment 14•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Assignee | ||
Comment 15•6 years ago
|
||
It's actually not a regression. So removing this keyword to stop the release bot to change the bug type.
Comment 16•6 years ago
|
||
Comment 17•6 years ago
|
||
Assignee | ||
Comment 18•6 years ago
|
||
It's interesting that this didn't cause a single failure in the recent try push before landing the patch. I will have to investigate it.
Comment 19•6 years ago
|
||
Backed out changeset 3350eb992270 (bug 1487358) for causing the Mn and Wd intermittent/perma failures
Backout: https://hg.mozilla.org/integration/autoland/rev/c6a17846e2d2ff62c36b879dbfa234dad0d02565
Assignee | ||
Comment 20•6 years ago
|
||
Here the list of changesets and tests for the time period my patch was on autoland:
Assignee | ||
Comment 21•6 years ago
|
||
The Wd failures were actually not a problem with my patch but just a bad coincidence with bug 1553855, which was backed out via:
https://hg.mozilla.org/integration/autoland/rev/795082d54c998ff568d64472e8f0af828a011eae
As such the only failures are from the Mn job, and here for the newly added test test_handle_two_modal_dialogs
. After a couple of runs I was able to see this failure on MacOS too. Reason is most likely that after closing the first alert, the second alert isn't immediately shown but it takes some milliseconds.
Maybe accept
and dismiss
need to spin the event loop.
Assignee | ||
Comment 22•6 years ago
|
||
It looks like just spinning the event loop before checking for remaining alerts on the page after a prompt has been accepted/dismissed is not enough. Only when I add sleeps of about 30ms and more, a remaining prompt will be detected. Here is the HTML/JS snippet:
<script type="text/javascript">
function setInnerText(id, value) {
document.getElementById(id).innerHTML = "<p>" + value + "</p>";
}
function handleTwoDialogs() {
setInnerText("text1", prompt("First"));
setInnerText("text2", prompt("Second"));
}
</script>
[..]
<a href="#" id="open-two-dialogs" onclick="handleTwoDialogs()">Open two prompts.</a>
Olli, right now my code is waiting for the DOMModalDialogClosed
event before it immediately checks for any remaining prompt via this method:
https://searchfox.org/mozilla-central/rev/9eb2f739c165b4e294929f7b99fbb4d90f8a396b/testing/marionette/modal.js#62
Maybe you know if there is some other kind of event Marionette would have to wait for before checking for remaining alerts? Or is the first prompt just blocking, and the second opens after the first has been closed? If that is the case maybe we need a sleep call for now until bug 1477977 has been fixed.
Assignee | ||
Comment 23•6 years ago
|
||
Actually I found the problem with bug 1477977, so I'm going to fix that first. But then also the test has to wait for the second alert, given that in cases of high CPU load the tabmodal-dialog-loaded
observer notification is delayed, which means that the alert isn't getting opened immediately by Firefox. Not sure if that is expected or not. As such I will leave the needinfo request for Olli.
Comment 24•6 years ago
|
||
(In reply to Henrik Skupin (:whimboo) [⌚️UTC+2] from comment #22)
Or is the first prompt just
blocking, and the second opens after the first has been closed?
This
If that is
the case maybe we need a sleep call for now until bug 1477977 has been fixed.
Hmm, sleep where?
Can't you just handle DOMModalDialogClosed synchronously and once that is handled, the next prompt will be opened?
Perhaps I'm misunderstanding the issue.
Assignee | ||
Comment 25•6 years ago
|
||
We don't have control over this behavior. Marionette just needs to be able to handle websites which might make use of that. Current Marionette code is located here:
But as said in my last comment I will fix bug 1477977 first, so when a tab modal appears Marionette immediately gets notified, and we set the internal flag for an open prompt, and vice versa.
Assignee | ||
Comment 26•5 years ago
|
||
Now that bug 1477977 is fixed the patch for this bug works fine locally. I also include the enabling of the currently disabled wdspec tests.
Here is a try push:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2379544527902f13db9915a0f982fd40d7c215db
Assignee | ||
Comment 27•5 years ago
|
||
Depends on D32666
Comment 28•5 years ago
|
||
Comment 29•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9c28135106d3
https://hg.mozilla.org/mozilla-central/rev/64f906609a52
Assignee | ||
Comment 30•5 years ago
|
||
(In reply to Bogdan Tara[:bogdan_tara] from comment #29)
Can someone please backout only this commit? It causes a high frequent intermittent for wdspec tests, and I would like to get this fixed in a separate bug. There is no need to reopen this bug after the backout. Thanks.
Comment 31•5 years ago
|
||
It was backed out by: https://hg.mozilla.org/integration/autoland/rev/2af46ed2e59b9aab02bda25eebd5c610ef373e02
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•2 years ago
|
Description
•