Closed
Bug 827084
Opened 12 years ago
Closed 11 years ago
window.alert() and confirm() won't work in new tear-off window
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
VERIFIED
FIXED
Firefox 29
People
(Reporter: cyberscorpio, Assigned: dao)
References
Details
(Keywords: regression)
Attachments
(2 files)
347 bytes,
text/html
|
Details | |
1.12 KB,
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232
Steps to reproduce:
Open the attached file in Firefox (tested on 17.0.1 and 20a1), then darg it out from the original window to generate a new window (so we have two windows on the screen).
Then click the button, the 'alert()' won't work. Check the error console, there is an error message like this:
Timestamp: 1/6/2013 3:52:45 PM
Error: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMWindow.alert]
Source:file:///I:/code/test/alert.html
Line:11
window.confirm() also has the same problem.
Actual results:
window.alert() and .confirm() won't work in the new window (by dragging the tab into a new window).
Expected results:
There should be a dialog box displayed.
![]() |
||
Updated•12 years ago
|
Attachment #698397 -
Attachment mime type: text/plain → text/html
![]() |
||
Comment 1•12 years ago
|
||
Unsure if CORE or Firefox UI/Chrome Bug. Moving nevertheless for Investigation.
![]() |
||
Comment 2•12 years ago
|
||
Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/22288130fea2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120813211942
Bad:
http://hg.mozilla.org/mozilla-central/rev/d9183f015df8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120814055342
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22288130fea2&tochange=d9183f015df8
Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/538c9b700037
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120813111146
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/6e12afd7b4bb
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 ID:20120813121942
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=538c9b700037&tochange=6e12afd7b4bb
Suspected: Bug 391834
Blocks: 391834
Status: UNCONFIRMED → NEW
tracking-firefox18:
--- → ?
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → ?
tracking-firefox-esr17:
--- → ?
Ever confirmed: true
Keywords: testcase → regression
Comment 3•12 years ago
|
||
Oh, do we end up calling http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml#1677
Comment 4•12 years ago
|
||
That should check whether we're just moving tab or something?
Comment 5•12 years ago
|
||
The easier solution would be to have the preventFurtherDialogs call happen after swapBrowsersAndCloseOther swaps the docshells. But we would need to make sure that doesn't regress bug 700080.
Comment 6•12 years ago
|
||
The easier solution would be to have the preventFurtherDialogs call happen after swapBrowsersAndCloseOther swaps the docshells. But we would need to make sure that doesn't regress bug 700080.
Component: DOM → Tabbed Browser
OS: Windows 7 → All
Product: Core → Firefox
Hardware: x86 → All
Whiteboard: [dupeme]
Comment 7•12 years ago
|
||
This is a fairly recent regression, so we should fix/uplift as soon as possible. That being said, the user impact here isn't significant - it's fairly uncommon to drag the tab out and alert. If we have any in-product alerts that are hindered, please re-nominate.
Assignee: nobody → enndeakin
status-firefox18:
--- → wontfix
status-firefox19:
--- → affected
status-firefox20:
--- → affected
Comment 8•12 years ago
|
||
Remember - this also affects confirm().
When I start FireFTP, it opens in its own window. I then drag its tab to the window with the tab group for the pages that I'm working on (it's more convenient there). After that, any attempt to delete anything either locally or remotely, which should pop up a confirm dialog, instead generates the NS_ERROR_NOT_AVAILABLE error. The workaround is to start FireFTP in its own window again and delete files from there, but that's a bit of a hassle.
Comment 9•12 years ago
|
||
(In reply to John Van Essen from comment #8)
> Remember - this also affects confirm().
and prompt() also.
Updated•12 years ago
|
![]() |
||
Updated•12 years ago
|
status-firefox21:
--- → affected
status-firefox22:
--- → affected
status-firefox23:
--- → affected
status-firefox-esr17:
--- → affected
![]() |
||
Updated•12 years ago
|
Summary: window.alert() and confirm() won't work in new window → window.alert() and confirm() won't work in new tear-off window
Comment 13•12 years ago
|
||
this bug also affects javascript-initiated print dialog popups.
Comment 14•11 years ago
|
||
Update: It's been over a year since this bug's initial report, and still exists in the latest version (26.0)
This but does affect our intranet business processes, which exclusively leverage Firefox. Prevents `alert`, `prompt` and `confirm` dialogs.
![]() |
||
Updated•11 years ago
|
status-firefox26:
--- → affected
status-firefox27:
--- → affected
status-firefox28:
--- → affected
status-firefox29:
--- → affected
status-firefox-esr24:
--- → affected
Assignee | ||
Updated•11 years ago
|
Assignee: enndeakin → dao
Assignee | ||
Comment 15•11 years ago
|
||
Attachment #8360277 -
Flags: review?(enndeakin)
Comment 16•11 years ago
|
||
Comment on attachment 8360277 [details] [diff] [review]
patch
Seems ok to me. In comment 5, Gavin suggests that this is the harder solution. Maybe he was thinking of some issue with this?
Attachment #8360277 -
Flags: review?(enndeakin) → review+
Flags: needinfo?(gavin.sharp)
Comment 17•11 years ago
|
||
preventDialogs affects the current inner window - what if the inner window of the docShell being swapped in to the closing tab has an onbeforeunload dialog? This doesn't happen in the "tear off" case (the tab being swapped should always be about:blank then), but is it possible for swapBrowsersAndCloseOther's aOtherTab to not have about:blank loaded?
Flags: needinfo?(gavin.sharp)
Comment 18•11 years ago
|
||
I suppose there are always add-ons to worry about.
Assignee | ||
Comment 19•11 years ago
|
||
(In reply to :Gavin Sharp (email gavin@gavinsharp.com) from comment #17)
> preventDialogs affects the current inner window - what if the inner window
> of the docShell being swapped in to the closing tab has an onbeforeunload
> dialog?
The onbeforeunload handler won't be called, but that's already the case without this patch, since we check aTabWillBeMoved before calling contentViewer.permitUnload.
Assignee | ||
Comment 20•11 years ago
|
||
Comment 21•11 years ago
|
||
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment 22•11 years ago
|
||
Reproduced in nightly 2014-01-10.
Verified fixed 29.0a1 (2014-01-16), win 7 x64.
Status: RESOLVED → VERIFIED
Updated•11 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•