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

VERIFIED FIXED in Firefox 29

Status

()

VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: cyberscorpio, Assigned: dao)

Tracking

({regression})

17 Branch
Firefox 29
regression
Points:
---

Firefox Tracking Flags

(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)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 698397 [details]
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]

Comment 2

6 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
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.
Assignee: nobody → enndeakin
status-firefox18: --- → wontfix
status-firefox19: --- → affected
status-firefox20: --- → affected
tracking-firefox18: ? → -
tracking-firefox19: ? → -
tracking-firefox20: ? → -
tracking-firefox-esr17: ? → +

Comment 8

6 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.
(In reply to John Van Essen from comment #8)
> Remember - this also affects confirm().
and prompt() also.
Duplicate of this bug: 828475
tracking-firefox-esr17: + → -

Updated

6 years ago
Duplicate of this bug: 871142

Updated

6 years ago
status-firefox21: --- → affected
status-firefox22: --- → affected
status-firefox23: --- → affected
status-firefox-esr17: --- → affected

Updated

6 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

Updated

6 years ago
Duplicate of this bug: 875743

Comment 13

6 years ago
this bug also affects javascript-initiated print dialog popups.

Comment 14

5 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

5 years ago
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected
status-firefox29: --- → affected
status-firefox-esr24: --- → affected
(Assignee)

Updated

5 years ago
Assignee: enndeakin → dao
(Assignee)

Comment 15

5 years ago
Created attachment 8360277 [details] [diff] [review]
patch
Attachment #8360277 - Flags: review?(enndeakin)

Comment 16

5 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)
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.
(Assignee)

Comment 19

5 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.
https://hg.mozilla.org/mozilla-central/rev/7cbf6359300b
Status: NEW → RESOLVED
Last Resolved: 5 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
status-firefox29: affected → verified
status-firefox-esr24: affected → wontfix
You need to log in before you can comment on or make changes to this bug.