Closed Bug 827084 Opened 11 years ago Closed 10 years ago

window.alert() and confirm() won't work in new tear-off window

Categories

(Firefox :: Tabbed Browser, defect)

17 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 29
Tracking Status
firefox18 - wontfix
firefox19 - affected
firefox20 - affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- affected
firefox26 --- affected
firefox27 --- affected
firefox28 --- affected
firefox29 --- verified
firefox-esr17 - affected
firefox-esr24 --- wontfix

People

(Reporter: cyberscorpio, Assigned: dao)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached file alert.html
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.
Attachment #698397 - Attachment mime type: text/plain → text/html
Unsure if CORE or Firefox UI/Chrome Bug. Moving nevertheless for Investigation.
Component: Untriaged → DOM
Keywords: testcase
Product: Firefox → Core
Whiteboard: [dupeme]
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
Ever confirmed: true
Keywords: testcaseregression
That should check whether we're just moving tab or something?
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.
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]
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.
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.
(In reply to John Van Essen from comment #8)
> Remember - this also affects confirm().
and prompt() also.
Summary: window.alert() and confirm() won't work in new window → window.alert() and confirm() won't work in new tear-off window
this bug also affects javascript-initiated print dialog popups.
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.
Assignee: enndeakin → dao
Attached patch patchSplinter Review
Attachment #8360277 - Flags: review?(enndeakin)
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)
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)
I suppose there are always add-ons to worry about.
(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.
https://hg.mozilla.org/mozilla-central/rev/7cbf6359300b
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Reproduced in nightly 2014-01-10.
Verified fixed 29.0a1 (2014-01-16), win 7 x64.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: