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

RESOLVED FIXED

Status

()

Core
Event Handling
RESOLVED FIXED
6 years ago
3 years ago

People

(Reporter: TinyButStrong, Unassigned)

Tracking

(Blocks: 1 bug, {regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(firefox8+ unaffected, firefox9+)

Details

(Whiteboard: [qa+])

(Reporter)

Description

6 years ago
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
(Reporter)

Comment 2

6 years ago
The regression begin in CSet f262c389193.

Build to try:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-08-13-03-07-46-mozilla-central/

The previous one CSet f262c389193e works fine:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-08-12-03-07-44-mozilla-central/

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

Comment 3

6 years ago
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

Comment 4

6 years ago
Sorry spam
Please ignore Comment #3

Comment 5

6 years ago
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

Comment 6

6 years ago
In addition to the comment #5.
If I execute the bookmarklet from Library, the problem does not happen.

Updated

6 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

6 years ago
Summary: Popup blocker blocks bookmarklets with window.open → Popup blocker blocks bookmarklets with window.open, if the bookmarklet execute from inside of menupopup.

Updated

6 years ago
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.

Updated

6 years ago
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?

Comment 8

6 years ago
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

Updated

6 years ago
OS: Windows 7 → All
Hardware: x86_64 → All

Updated

6 years ago
Component: General → Event Handling
Product: Firefox → Core
QA Contact: general → events
status-firefox8: --- → affected
tracking-firefox8: --- → ?
(Reporter)

Updated

6 years ago
Severity: normal → blocker

Updated

6 years ago
tracking-firefox8: ? → +
(Reporter)

Updated

6 years ago
Priority: -- → P5

Comment 10

6 years ago
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)
(Reporter)

Comment 11

6 years ago
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.

Updated

6 years ago
Duplicate of this bug: 697184

Comment 13

6 years ago
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 → --

Comment 14

6 years ago
I backed out bug 679961 for Firefox 8. It is still on aurora and central.
status-firefox8: affected → unaffected

Updated

6 years ago
tracking-firefox9: --- → ?
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
tracking-firefox9: ? → +
(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
pushed https://hg.mozilla.org/mozilla-central/rev/dfb168a4c4f9, https://hg.mozilla.org/releases/mozilla-aurora/rev/0955dfe7c0bf and https://hg.mozilla.org/releases/mozilla-beta/rev/3f481ad8d6ac

Comment 18

6 years ago
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
(Reporter)

Comment 21

6 years ago
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
Last Resolved: 6 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?
You need to log in before you can comment on or make changes to this bug.