Closed Bug 679961 Opened 13 years ago Closed 13 years ago

Popup blocker blocks bookmarklets with window.open, if the bookmarklet is executed from inside of menupopup.

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox8 + unaffected
firefox9 + ---

People

(Reporter: tinybutstrong, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression, Whiteboard: [qa+])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110817 Firefox/9.0a1
Build ID: 20110817061121

Steps to reproduce:

Add a bookmarklet to bookmarks menu that opens a pop-up, example:

javascript:var ThisAddonShouldBeIntegratedToFirefoxReleaseVersionASAP=window.open('http://br.mozdev.org/multifox/','','width=428,height=270,maximize=1,fullscreen=yes');ThisAddonShouldBeIntegratedToFirefoxReleaseVersionASAP.focus();

Try to open it now!



Actual results:

Firefox blocks the popup and show bar message "Nightly prevented this site from opening a pop-up window." or blue icon in urlbar, depending on user configuration.

In some internal pages the pop-up is not blocked, ie about:support, about:config, about:addons, etc.


Expected results:

Show my sweet pop-up, doh!
On IRC, the reporter narrowed it down to this regression range:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f262c389193e&tochange=9698a1031317

In that range, the only relevant change seems to be bug 463491.
Blocks: 463491
Keywords: regression
Reproduced on http://hg.mozilla.org/mozilla-central/rev/dcb25d71220d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110817 Firefox/9.0a1 ID:20110817061121

[str]
1. open ex. http://www.mozilla.org/projects/firefox/prerelease.html
2. execute the bookmarklet

However I cannot reprofuced with the following str.
1. open ex. http://www.mozilla.com/en-US/firefox/new/
2. execute the bookmarklet

Pushlog(m-i hourly)
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6a43079a1c0f&tochange=223d4f4bd252
Sorry spam
Please ignore Comment #3
Reproduced on http://hg.mozilla.org/mozilla-central/rev/dcb25d71220d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0a1) Gecko/20110817 Firefox/9.0a1 ID:20110817061121

When I execute the bookmarklet from a popup menu, this problem happens.
I.E. Menu popup such as Firefox Button, Bookmarks Menu, Bookmarks Widget Button and popup of folder placed in Bookmarks Toolbar)

If I execute the bookmarklet from Sidebar and Bookmarks Toolbar, the problem does not happen.

Pushlog(m-i hourly)
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=6a43079a1c0f&tochange=223d4f4bd252
In addition to the comment #5.
If I execute the bookmarklet from Library, the problem does not happen.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Popup blocker blocks bookmarklets with window.open → Popup blocker blocks bookmarklets with window.open, if the bookmarklet execute from inside of menupopup.
Summary: Popup blocker blocks bookmarklets with window.open, if the bookmarklet execute from inside of menupopup. → Popup blocker blocks bookmarklets with window.open, if the bookmarklet is executed from inside of menupopup.
OS: Windows 7 → All
Hardware: x86_64 → All
I removed the XUL_COMMAND special case because of bug 463491 assuming that all use of XUL_COMMAND will execute chrome privileged code (which by-pass the popup blocker now). Obviously, this is an edge case where XUL_COMMAND doesn't execute chrome privileged code and I guess we don't want to make the bookmarklet chrome privileged but still have some privileges. Am I right? I mean, do we want window.open() to be doable from bookmarklets?

I'm not sure what to do here... We could revert bug 463491 and find another way to fix it. We could also try to figure out a way to make clearer which privileges we want to give to bookmarklets but I don't know how we could do that.

Anyone has a suggestion?
At least, It should be same behavior between 'menupopup' and 'Sidebar,Libraly, Bookmaks Toolbar'.
(In reply to Mounir Lamouri (:volkmar) from comment #7)
> Obviously, this is an edge case where XUL_COMMAND
> doesn't execute chrome privileged code

The XUL command event should be firing in chrome privileged code. Presumably something about the popup menus is causing this issue. It shouldn't be related to the privileges of the code in the bookmarklet (those are always run with page privileges).
Status: NEW → UNCONFIRMED
Ever confirmed: false
OS: All → Windows 7
Hardware: All → x86_64
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86_64 → All
Component: General → Event Handling
Product: Firefox → Core
QA Contact: general → events
Severity: normal → blocker
Priority: -- → P5
I think what I'm seeing is this bug but just in case it's not...

I have several bookmarklets which open new windows, such as the wikipedia one here
http://en.wikipedia.org/wiki/Bookmarklet#Example
and from the squarefree site. I've used some of them for years.

These work in Fx7 but give a 'Fx is preventing this site from opening a popup window' here in Fx 8 beta (and also in Aurora).

But comment 5 says this problem doesn't happen when the bookmarklet is executed from the bookmarks toolbar - and it does. And I guess that's where most people execute bookmarklets from.

Using Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0 (& in safe mode)
Any news about this bug? That is very annoyance, I need to open any internal tab liks about:memory before to be able to open any bookmarklet.
TinyButStrong, please don't change Priority and Severity fields as long as you don't intend to fix it yourself. These fields are for engineers to prioritize their work.
Severity: blocker → normal
Priority: P5 → --
I backed out bug 679961 for Firefox 8. It is still on aurora and central.
Is anybody available to back this out on all remaining affected branches? We previously did so for FF8, but since we haven't continued the investigation here, we should back out everywhere (FF9 and up). a=akeybl
(In reply to Alex Keybl [:akeybl] from comment #15)
> Is anybody available to back this out on all remaining affected branches? We
> previously did so for FF8, but since we haven't continued the investigation
> here, we should back out everywhere (FF9 and up). a=akeybl

sorry this refers to bug 463491
So this should be fixed now, right?
Can someone explains what was the reasoning for backouting bug 463491? Given that bug 463491 was fixing a very bad bug/hole in our popup blocker (and easily exploitable), the choice didn't seem trivial but the decision was still made without any public and clear reasoning.
I understand that some users use a lot of bookmarklets and might have a reduced experience because window.open() doesn't work with those but some other users don't use bookmarklets or window.open() in bookmarklets and those users are going to be the targets of potentials exploit of this popup blocker issue. Is the first group big enough to compensate what the second is loosing?
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #19)
> Is the first group big enough to compensate what the second
> is loosing?

We decided yes. We know of many bookmarklets such as 

https://dev.twitter.com/docs/share-bookmarklet

that users use regularly. Pop ups happening while the save dialog box is unfortunate, but likely less common. We backed bug 463491 out for FF8, there was no change in the situation for FF9, so we backed out everywhere so that we can stop chasing this down. Once this is fixed, we'll take bug 463491 again.
Status: NEW → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true
My popups from bookmarklet is working again, someone else confirm?

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:11.0a1) Gecko/20111208 Firefox/11.0a1
fixed by the backout in comment 17
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [qa+]
Before to open another bug, I'll try commmenting in this one because it is very related to my issue.

I have noted that a bookmarklet that opens a new window is blocked by popup blocker if it is launched using a keyword via urlbar.
Is  it a bug or is it wanted by design?
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.