Open
Bug 644322
Opened 13 years ago
Updated 8 months ago
New non-modal alerts are skipped/confirmed via page navigation.
Categories
(Toolkit :: Content Prompts, defect)
Toolkit
Content Prompts
Tracking
()
NEW
People
(Reporter: bugzilla, Unassigned, NeedInfo)
References
Details
(Keywords: regression)
Attachments
(2 files, 3 obsolete files)
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 The new non-modal popups are very oddly dismissed and have the underlying queued events fire. You can't block a form submit via javascript for example. This seems horribly broken. This means that attempting to visit bookmarks can post data. You could accidentally delete something instead of avoid the confirmation that would have normally worked. Reproducible: Always Steps to Reproduce: Attempt a navigation (href/form post) blocked by a new non-modal popup (alert/confirm/prompt). Then navigate by using virtually any other method available. Home, Bookmark, Back, Forward, Refresh, manually typing in the address bar. Or just load the example file below. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Firefox 4 Alert/Confirm/Prompt Navigation Bug</title> <script type="text/javascript"> function testConfirmation() { var qs = document.location.search if (qs == '?confirmed=1') { document.getElementById('confirmed').style.display = 'block'; document.getElementById('f').style.display = 'none'; } } </script> <style type="text/css"> #confirmed {text-decoration:blink; color:red; font-weight:bold; font-size:30px; width:300px; margin:30px auto; } </style> </head> <body> <p id="confirmed" style="display:none;">MACHINE ERASED</p> <form id="f" action="tab-alert-bug.html" method="get" onsubmit="return confirm('Are you certain you wish to erase your machine?');"> <h1>Firefox 4 Alert/Confirm/Prompt Navigation Bug</h1> <p>Any sort of navigation will confirm these popups illogically.</p> <ul> <li>Home</li> <li>Refresh</li> <li>Manually typing in the address bar</li> <li>Bookmark</li> <li>Back</li> <li>Forward</li> </ul> <p>Why would navigation or unloading the existing page execute the alert/confirm dialog?</p> <p>Even if it did why would it return true?</p> <input type="hidden" name="confirmed" value="1"/> <input type="submit" value="Initiate Bug via Form Submit"/> <br/><a href="tab-alert-bug.html?confirmed=1" onclick="return confirm('Are you certain you wish to erase your machine?');">Initiate Bug via Href (confirm)</a> <br/><a href="tab-alert-bug.html?confirmed=1" onclick="return (prompt('Are you certain you wish to erase your machine?') == 'I doubt you typed this.');">Initiate Bug via Href (prompt)</a> <br/><a href="tab-alert-bug.html?confirmed=1" onclick="alert('You are going to erase your machine?');">Initiate Bug via Href (alert)</a> </form> <script type="text/javascript"> testConfirmation(); </script> </body> </html> Actual Results: You won't successfully navigate to any page other than the new one queued by the previous step (i.e. You won't get to your homepage you'll instead submit the form). Expected Results: Navigate to another url without somehow executing the possible result from the non-modal window.
|
Reporter | |
Comment 1•13 years ago
|
||
|
||
Comment 2•13 years ago
|
||
Confirmed with Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110323 Firefox/4.2a1pre ID:20110323074443
Blocks: 59314
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Product: Firefox → Toolkit
QA Contact: general → general
This should be invalid, programmer should be using a better way to get user conformation. See Bug 578828 for workaround. Or for now use onbeforeunload suggested in the attachment see "modified tab-alert-bug.html" Current behavior is users want, see comments at bug 59314
Attachment #521421 -
Attachment is obsolete: true
Attachment #521423 -
Attachment is obsolete: true
Attachment #521426 -
Attachment is obsolete: true
|
|
Reporter | |
Comment 7•13 years ago
|
||
(In reply to comment #3) > Created attachment 521421 [details] > modified tab-alert-bug.html > > This should be invalid, programmer should be using a better way to get user > conformation. See Bug 578828 for workaround. > > Or for now use onbeforeunload suggested in the attachment > see "modified tab-alert-bug.html" > > Current behavior is users want, see comments at bug 59314 You've misunderstood the point. I'm not trying to stop the page from unload. I want it to unload. That's the whole point of say hitting the Home button. But the act of unloading it shouldn't cause the attempted navigation to fail. It shouldn't even navigate on its own. The example method of triggering the bug doesn't matter. None of your changes to the original file matter. A tab-modal dialog shouldn't somehow still fire when attempting to navigate via a completely non-tab-content action.
|
||
Comment 8•10 years ago
|
||
Bulk move to Toolkit::Notifications and Alerts Filter on notifications-and-alerts-component.
Component: General → Notifications and Alerts
|
||
Comment 9•2 years ago
|
||
In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.
Severity: major → --
|
||
Updated•10 months ago
|
Component: Notifications and Alerts → Content Prompts
|
|
||
Comment 10•8 months ago
|
||
The severity field is not set for this bug.
:mtigley, could you have a look please?
For more information, please visit BugBot documentation.
Flags: needinfo?(mtigley)
You need to log in
before you can comment on or make changes to this bug.
Description
•