Open Bug 463491 Opened 15 years ago Updated 8 months ago

When save dialog is open in pop up blocker does not work at all


(Core :: DOM: Core & HTML, defect)




Tracking Status
firefox9 + wontfix
firefox10 + wontfix


(Reporter: aavakian, Unassigned)


(Blocks 1 open bug)


(Keywords: testcase)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2008092417 Firefox/3.0.3 (.NET CLR 3.5.30729)

When (save) dialog is open in pop up blocker does not work at all and this is reproducible every time.

Reproducible: Always

Steps to Reproduce:
1. Turn on the pop-up blocker

2. Go to a site that has pop-ups that are done via JS over a period of time (that means they have to re-try, and hence not only on page load.

3. Pick a graphic or whatever to save from the site and leave the 'save dialog' open and wait for the JS to launch the popup.

4. The pop-up will be launch every time.
Actual Results:  
The pop-up's appear even though the blockers is enabled

Expected Results:  
no pop-ups
This is a mass search for bugs which are in the Firefox General component, are
UNCO, have not been changed for 500 days and have an unspecified version. 

Reporter, can you please update to Firefox 3.6.10 or later, create a fresh profile,, and test again. If you still see the issue, please update this bug. If the issue is gone, please set the status to RESOLVED > WORKSFORME.
Whiteboard: [CLOSEME 2010-11-01]
No reply from reporter, INCOMPLETE. Please retest with Firefox 3.6.12 or later and a new profile ( If you continue to see this issue with the newest firefox and a new profile, then please comment on this bug.
Closed: 13 years ago
Resolution: --- → INCOMPLETE
I can confirm this problem in Firefox 7.0a1 on the testcase in bug 659882. Javascript repeatedly tries to open a window checking if it got success. The popupblocker bar appears and counts up windows it killed. When using File->Save as (the whole page) and having the save dialog open, the JS window succeeds to open.
Severity: major → normal
Component: General → DOM: Core & HTML
Ever confirmed: true
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Resolution: INCOMPLETE → ---
Version: unspecified → Trunk
Whiteboard: [CLOSEME 2010-11-01]
Attached file testcase
Keywords: testcase
The reason seems to be because the save and open dialogs are open through a XUL command event and those events are considered safe so the popup blocker level is reduced to "openControlled" thus making all popup to pass. So it doesn't happen when using an <input type='file'> which makes this bug less critical...

Though, I wonder why we need to check if the event is a XUL command and reduce the popup blocker in that case. Do we really want to have a popup blocker for chrome? I mean can't we just by-pass the popup-blocker check when we have chrome privileges?
So, I'm going to fix that in two parts:
1. Make sure popup blocker is by-passed when the caller has chrome privileges (bug 662519);
2. Don't reduce the abuse level when the command event is used.

I could probably do 2 without 1 but the only reason we could be reducing the abuse level is that the popup blocker was sometimes interfering with the chrome/xul pages. 1 will make sure that this can't happen. In addition, there is no reason to use the popup blocker in the chrome context. At least, I don't see any...
Depends on: 662519
Attached patch Patch v1 (obsolete) — Splinter Review
Assignee: nobody → mounir.lamouri
Attachment #537808 - Flags: review?(jst)
Whiteboard: [needs review]
Actually, my test is using "ctrlKey: true" but I wonder how would that behave on a Mac. Should I use metaKey in that case?
Jst, any update regarding the review?
Comment on attachment 537808 [details] [diff] [review]
Patch v1

Sorry for the delay, I thought I had already reviewed this... :(

Attachment #537808 - Flags: review?(jst) → review+
Ehsan, the test in this patch seems to fail because of other tests using mockObject.js. It seems that calling my test followed by toolkit/content/tests/browser/browser_save_resend_postdata.js or the latter followed by my test always creates a time out.

Here is the patch I pushed to try (the test has changed a bit):

And the error:

By any chance, do you have any idea of what could be happening?
Attachment #537808 - Attachment is obsolete: true
So, I'm trying to understand what's happening with this test... I've tried to improve mockObjects.js by unregistering the current factory and re-register it correctly at the end and that helped to narrow down the issue.
This code fails with an exception thrown when .createInstance() is called because no factory is found:
(I believe the variable names are self-explanatory)
componentRegistrar.unregisterFactory(this._originalCID, this._originalFactory);
componentRegistrar.registerFactory(this._cid, "",
                                   this._contractID, this._mockFactory);

It seems that nsComponentManagerImpl::RegisterFactory is correctly called and works so a factory is actually registered but when nsComponentManagerImpl::CreateInstance is called, there is indeed no factory but  these methods don't have the same CID in parameter. ::RegisterFactory has this._cid, as expected while ::CreateInstance is using the CID from the previous factory. I really don't understand why the previous CID is still around except if Components.classes[this._contractID] doesn't return the correct object and nsJSCID::mDetails hasn't been updated...
Depends on: 678166
Bug 678166 comes with the required fix to get the tests passing... Finally able to push! :)
Flags: in-testsuite+
Whiteboard: [needs review] → [inbound]
Closed: 13 years ago12 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
I backed this out of mozilla-beta / Firefox8 due to bug 679961:

We need to see if we can alter this a bit in bug 679961 (or get product to make an explicit decision)
Target Milestone: mozilla8 → mozilla9
Verified that this fix is backed out from Firefox 8 Beta 6 (build 2) using the test case attached in Comment 4. Tested on Windows XP, Windows 7, Mac OS X 10.6 and Ubuntu 11.10 - pop-ups appear when opening the save dialog.

Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0
Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0

Should this bug be reopened?
(In reply to Simona B [QA] from comment #17)
> Should this bug be reopened?

The patch has been backed out from Aurora but is still applied on mozilla-central so the bug remains fixed.
[Triage Comment]
Due to 679961, please back this bug out on aurora and beta, and also m-c if we don't think 679961 will be fixed in the short term.
Reopening, as it seems (bug 679961 comment 15) this has now been backed out everywhere.
Resolution: FIXED → ---
Blocks: popups
Target Milestone: mozilla9 → ---
I can no longer reproduce this using nightly on Linux x86_64 as of today.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: mounir → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.