210664 - unblocked popup-window does not appear on reload

Status: RESOLVED INVALID

(SeaMonkey :: UI Design, defect)

Description

[alex]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4) Gecko/20030624

opening http://www.nytimes.com (denying cockies) a popup window was blocked by
the browser by my defaults. adding the site to my exceptions list and reloading
the page did NOT result in the popup appearing.

Reproducible: Always

Steps to Reproduce:
1.go to http://www.nytimes.com (with blocked popups)
2.deny cookies
3. ad the site to the exceptions list
4. reload

Actual Results:  
no popup

Expected Results:  
allow popup

Comment 1

[hahn]

I can confirm this bug on build 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5a) Gecko/20030708 

The bug also appears on the site http://opac.tu-berlin.de
Reproduce as follows: go to http://opac.tu-berlin.de, enter some garbage
("asdfasdf") into the query form, press enter. Unblocking the popup does not work.

Reason: The popup is from a different site than the window opening it. Either
the suggestions "opac.tu-berlin.de" and "nytimes.com" are wrong or the algorithm
determining admissibility uses the wrong address: The suggestions are the hosts
of the pages calling window.open, the algorithm checking permissions compares
them to the hosts of the pages displayed in the popup, "libspro.tu-berlin.de"
and "ad.doubleclick.net", which obviously do not match.

Workaround: Find out the actual host of the page in the popup, in the testcases
libspro.tu-berlin.de and ad.doubleclick.net and add these to the whitelist.

Fix: Suggest the same host to be added to the whitelist that the algorithm
checking popup-permissions uses.

Comment 2

[Boris 'pi' Piwinger]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040514

I have observed that in other sites. I just wanted to file a bug on this.

This is a total loss of function (major). Since this makes popups which were
blocked once are practically unreachable for the average user, this must not
happen for a mojor release like 1.7. It should also not be in 1.8. Asking for
blocking. Yes, I know this is late.

pi

Comment 3

[Boris 'pi' Piwinger]

Actially, this is dataloss, hence critical. And it used to work, hence a regression.

pi

Comment 4

[Dan M]

nytimes.com sends slightly different advertising content every time you load it
(well, not *every* time because their set of advertising content is finite).
Sometimes the page includes an invisible image that tries to open a popup window
in its load handler. Sometimes it doesn't. You're likely to get the version that
tries to open a popup window on your first visit after some fairly lengthy time
delay, but after that you're very unlikely to get that version of the page, even
if you stand there and reload a dozen times. They probably track your IP number.

Mozilla doesn't offer to open a popup on the second load of nytimes.com because
the site doesn't try to open another popup. Kind of nice of them, in a not
particularly nice way.

Comment 5

[Boris 'pi' Piwinger]

I had the same problem with any other page where I unblocked. This is why I
found this bug.

pi

Comment 6

[Dan M]

The bug as described in the initial comment is INVALID. Do NOT reopen this bug.
Find a bug of your own if you have some other complaint, and be specific.

Comment 7

[Dan M]

Wait. This happens to you at /any/ site? That'd be a pretty big bug. Be sure
you've tried it without extensions and give a build date, before you file that
new bug, 'coz that ain't happening in my recent trunk build, or in a copy of the
Firefox Aviary build from two days ago I happen to have lying around.

Comment 8

[Boris 'pi' Piwinger]

That was any I tried to unblock. I do it very rarely, so I don't have examples
at hand. The last I had was not publicly available. After typing in many long
forms it would output an important result page this way. It failed and
unblocking did not help to get the page. Even after switching pop-up blocking
off completely, it took many attempts to get it. This was on Linux with a 1.7
branch build.

Now I tried to find test pages and could not get it to work.

pi

Comment 9

[Boris 'pi' Piwinger]

The last sentence meant: I could not see the bug.

pi

Comment 10

[Dan M]

I harshed on you unnecessarily; I apologize for that.

If you can find a publicly available site of course feel free to write up a bug.
However in my experience with this stuff, which is somewhat considerable, this
tiny bit of the code has never been broken.

Comment 11

[Boris 'pi' Piwinger]

Instead of a new bug I reopen this which exactly descriebes it.

I use Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040609.

The page in questions is: http://www.aqua-nova.at/html/seite1.htm. When I visit
the page, I get the icon for a blocked pop-up. I click and add the site (which
is identified as aqua-nova.at). Then I reload (even force reload) the page. I
again get the icon. When I click on it, I see that aqua-nova.at is indeed listed
as an allowed site.

pi

Comment 12

[Boris 'pi' Piwinger]

And the next example: http://www.ris.bka.gv.at/auswahl/ (again the www. is dropped)

pi

Comment 13

[Dan M]

Comment 0 remains reproducible yet invalid. Comment 11 WFM, tested with Firefox
20040614-11 (trunk) and 20040614-23 (0.9 branch), as well as Mozilla 20040614-10
(trunk) builds. I also tried the URL from comment 12 using some build or
another. All not reproducible.

Boris, your results will turn out to be a bug in one of your extensions. I'd be
curious to know which one, just for future reference. And while I do care about
bugs in extensions because they're perceived as bugs in the browser, this ain't
the place to report them.

I'm closing this bug invalid once again.

Comment 14

[Boris 'pi' Piwinger]

I don't use any extension. Those problems appear in different installations on
different systems (Windows and Linux). So it cannot even be a profile thing.

pi

Comment 15

[Dan M]

No extensions? Curses, I underestimated you once again.

The problem you're seeing, is it readily reproduced on the installations on
which it does happen? Does a new profile help on those systems? (It's a settings
bug that has cropped up on more than one of your systems, perhaps?) Does it
matter if you launch Mozilla with the site already allowed, or is it necessary
to add the site after getting the popup-blocked indication? Does it ever happen
more than once in a row? Does it perhaps depend on some login cookie that treats
you to a different popup?

I've never seen a bug like this that couldn't be explained by some other bug or
some condition. Maybe you're sitting on the first one. But you're not the first
to try.

You know if you opened a new bug and mentioned in the initial comment that the
bug's appearance was not guaranteed, I wouldn't be tempted to close that one so
readily. Nor could I fix it. But at least it'd be open, collecting dust. And in
any case, bugs for which the first dozen comments are not applicable, even if
the summary string seems to match, are only confusing.

Comment 16

[Boris 'pi' Piwinger]

>The problem you're seeing, is it readily reproduced on the installations on
>which it does happen? 

Yes.

>Does a new profile help on those systems? 

Also yes.

>(It's a settings
>bug that has cropped up on more than one of your systems, perhaps?) 

Could be, let's see what my user.js does, which is the same everywhere (I
removed things obviously unrelated):

//
// B R O W S E R
//
// JavaScript annoyances (which don't have a UI) off
user_pref("dom.disable_window_open_feature.close",       true);
user_pref("dom.disable_window_open_feature.directories", false);
user_pref("dom.disable_window_open_feature.location",    true);
user_pref("dom.disable_window_open_feature.menubar",     true);
user_pref("dom.disable_window_open_feature.minimizable", true);
user_pref("dom.disable_window_open_feature.personalbar", true);
user_pref("dom.disable_window_open_feature.resizable",   true);
user_pref("dom.disable_window_open_feature.scrollbars",  true);
user_pref("dom.disable_window_open_feature.titlebar",    true);
user_pref("dom.disable_window_open_feature.toolbar",     true);
user_pref("dom.event.contextmenu.enabled", false);
// When the dom.disable_open_click_delay pref is set to a non-zero
// number, window.open will fail when called more than that number of
// milliseconds after a mouse click.
user_pref("dom.disable_open_click_delay", 1000);

>Does it
>matter if you launch Mozilla with the site already allowed, or is it necessary
>to add the site after getting the popup-blocked indication? 

Now that is a surprise: Yes, if I launch the browser with the site already
added, the pop-up shows up.

>Does it ever happen more than once in a row?

What exactly do you mean here?

>Does it perhaps depend on some login cookie that treats
>you to a different popup?

There is no login in both cases I listed.

pi

Comment 17

[Dan M]

It's gotta be
>user_pref("dom.disable_open_click_delay", 1000);
(see bug 247017)

>Now that is a surprise: Yes, if I launch the browser with the site already
>added, the pop-up shows up.

I wasn't expecting that either. Note this is the thing I was sceptical about,
that it would make a difference whether you approached the site already
whitelisted. And indeed it doesn't seem to affect bug 247017.

>>Does it ever happen more than once in a row?
>What exactly do you mean here?

Basically I was asking the same question with a slight twist; with the site
whitelisted and the first attempt blocked, whether the window would successfully
open by simply trying a second time.

If the problem you're seeing is caused by the click_delay pref, by all means
let's move over to the bug report made for that problem.