280536 - Popup blocker offers to unblock wrong host/domain on pages with frames

Status: REOPENED

(Firefox :: General, defect)

Description

[Thomas Hettenhausen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041122 Firefox/1.0

When I open the website at http://www.grendel-base.com a popup is blocked.
Clicking the icon for popup configuration in the bottom right, I have the option
to "Allow popups for www.grendel-base.com" and "Show:
http://www.industrialnation.nl/grendel/frameset.htm" because the popup is
located on another server. This is correct and not an attempt to hijack the
browser or something, but rather a technique used by lots of website owners who
store their website on a free webhoster and own a domain with very limited storage.

Reproducible: Always

Steps to Reproduce:
1. Open www.grendel-base.com with popup blocking enabled
2. "Allow popups for "Allow popups for www.grendel-base.com"
Actual Results:  
Nothing happens, no popup.
Only way tt see the popup is to open it manually via "Show:
http://www.industrialnation.nl/grendel/frameset.htm" and that everytime since it
does not create a ruleset.

Expected Results:  
Popup that was called FROM www.grendel-base.com should be opened as well as
those STORED ON www.grendel-base.com and a ruleset should be created for this,
since a user with no knowledge about servers and redirects will not know what
went wrong and blame it on Firefox.

Comment 1

[Kyle Smith]

I get a similar issue with http://ogame.org (a browser game).  When you are in the game, the url shows as http://ogame.org, but the actual address for the game info that gets shown in several frames on the page is different.  When it tries to bring up a popup message from the real address, the popup blocker gives you an "Allow popups for ogame.org" which doesn't do anything.

Comment 2

[Sebastian Busch]

i can confirm this. test case at:

  http://www.r3tro.de/frameset.html

(this frameset contains one frame which points to http://www.coding.de/popup.html)

the popup blocker gui wants to block/unblock "www.r3tro.de", which has no effect in this case. it _should_ block/unblock "www.coding.de" because this is the source of the popup.

you have to manually enter "www.coding.de" in the list of allowed sites to unblock popups originating from this frame.

if you directly visit http://www.coding.de/popup.html (without frameset) then the popup blocker gui correctly wants to block/unblock "www.coding.de").

Comment 3

[zug_treno]

*** Bug 325389 has been marked as a duplicate of this bug. ***

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 336020 has been marked as a duplicate of this bug. ***

Comment 5

[Adam Guthrie]

bz pointed out what the problem is on IRC: 

<bz> 426   fillPopupList: function (aEvent)
<bz> 433     var uri = gBrowser.selectedBrowser.webNavigation.currentURI;
<bz> 448         // Offer an item to allow popups for this site
<bz> 449         var allowString = bundle_browser.getFormattedString("popupAllow", [uri.host]);
<bz> Note that it's not using the requesting URI from the popup event or anything

So this should be pretty easy to fix if we can get the requesting URI of the event (which I assume is possible).

Comment 6

[jag (Peter Annema)]

I'm not sure that's the right solution.

I'd be reluctant to allow popups from www.coding.de if right now I'm looking at a page from www.r3tro.de. And imagine if both the main page and the frame trigger popups, now you've got to allow two domains so your popups work for that page (the frames and off-site hosting are mere details users shouldn't need to be bothered with).

I wonder if instead we can make it so we walk up the parent chain to see if any of the embedding pages' domains allow popups. In other words, if you allow popups for www.coding.de, and have an iframe for www.r3tro.de and that triggers a popup, the popup will just go through because popups are allowed for one of the embedding domains.

Comment 7

[Jesse Ruderman]

*** Bug 342204 has been marked as a duplicate of this bug. ***

Comment 8

[George]

I am not seeing this behavior on Firefox 2.0

Has this been fixed?

Comment 10

[Teune van Steeg]

Attachment: list hosts from which popups are blocked

This patch addresses the following comments:
http://mxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#562
> // XXXben - rather than using |currentURI| here, which breaks down on multi-framed sites
> //          we should really walk the pageReport and create a list of "allow for <host>"
> //          menuitems for the common subset of hosts present in the report, this will
> //          make us frame-safe.
> //
> // XXXjst - Note that when this is fixed to work with multi-framed sites,
> //          also back out the fix for bug 343772 where
> //          nsGlobalWindow::CheckOpenAllow() was changed to also
> //          check if the top window's location is whitelisted.

Comment 11

[Teune van Steeg]

Attachment: testcase: frameset with three frames each containing a popuptest from a different site

Comment 12

[Teune van Steeg]

Sorry but I misinterpreted this bug. The fix that the patch I attached proposes is not the correct way to fix it.

As I see it, popups from subframes should go through by default if popups from the domain in the top window are allowed (as is currently the case). If however popups from one of the domains in the subframes are explicitly blocked, these popups should not be opened (this is currently not true).

The same should happen when one of the domains of the subframes is explicitly allowed to open popups, and popups from the topdomain are blocked: popups from the allowed domain should be opened.

Of course, I think, there should be items in the popupmenu which enable you to allow / block popups for domains in the subframes.

Sorry for the bugspam.

Comment 13

[Asa Dotzler [:asa]]

This test case doesn't seem to work for me with the latest nightly build. If you can provide a working testcase or even point to a site where this is still happening, please re-open with that information.

Comment 14

[Sebastian Busch]

Sorry, I wasn't aware of this test case and removed the files some time ago...

I restored them and the test case works again. Ticket can be re-opened.

Regards,

Sebastian

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 16

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.