User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1+ When a popup is detected, the little panel that says "Firefox prevented this site ..." drops down. This resizes the area of the web page and triggers a resize event. If the site is set to reload on resize, this will repeat. Reproducible: Always Steps to Reproduce: 1. Go to washingtonpost.com or the sample data: URL 2. Watch 3. Actual Results: Page reloads continuously. Expected Results: Page loads only once.

*** This bug has been marked as a duplicate of 235871 ***

Um... I don't think so. Bug 235871 is a problem with custom theme that has to do with the progress meter. This is a problem with the default setup that has to do with the popup panel thing. While the distinction between custom theme vs. default browser is not really important, this is is a seperate issue because the code to fix bug 235871 would not fix this problem, so it deserves a different bug. Also, the powers in charge might choose to resolve this problem in a different way. For example, they might choose to let the other bug die by forcing theme authors to change, or they might decide that this is the fault of washingtonpost.com and not of the browser and so the popup panel is the best solution to the problem, marking this INVALID. Basically, these problems are going to be resolved separately, both code-wise and in design. That is why I am reopening this bug. Also, I would presume this also applies to pages with reload onresize to install XPIs as we have a similiar dropdown thing. Or using the find toolbar on a page with reload onresize.

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

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

Re comment #2. This is NOT an issue with the find toolbar becauswe the find toolbar persists when the reload occurs. The reason this is aproblem with the popup blocker is that it goes away when the reload is initiated so when the reload completes the bar reappears and triggers another resize. The simple solution is to NOT have the popup blocker bar go away on a server initiated reload.

Having it not go away on a server initiated reload would still cause an issue thou the issue would not be loop. The page would reload once when the page goes from no warning head to adding the popup warning header which I would consider non-optimal behavior. Some possibilities: 1) Have the top banner not push down the content, but just display on top of it so the size does not very to javascript. if there's support for it in mozilla, it could even be transparent to allow the page below to partially show below. 2) Have the banner push down, but have javascript returned size not take the adjusted size into account

re comment #6. Windows XP SP2 seems to do something akin to option 2.

re comment #7. I oviously meant to say the XP SP2 version of IE. Sorry for the bug spam.

I voted for this bug, can't reproduce it anymore now. Don't know about the trunk though. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040831 Firefox/0.9.1+

I glanced through the source of page including most of the includes from washpost and did not see the window size, if not matching reload, code that I saw when I first has this issue. So it would seem. Even my test page of a saved page from washingtonpost.com now does not have problems. Though the js includes from washingtonpost.com were saved in that instance, the js includes from doubleclick were and are served live. So it might appear that doubleclick changed their code to not reload page on a resize? Anyone have another site that still experiences the behavior?

Go to washingtonpost.com and maximize or resize the window. It still reloads. For some reason though, the popup notifier isn't showing up. This also seems to be true for the URLs provided in bugs duped to this one.

Does washpost still do pop-ups? I tried it in IE and didn't see any popups or warnings of any. Perhaps with IE having pop-up blocking, the sites have backed off using pop-ups.

(In reply to comment #12) > Does washpost still do pop-ups? I tried it in IE and didn't see any popups or > warnings of any. Perhaps with IE having pop-up blocking, the sites have backed > off using pop-ups. It appears they stopped with that. But they still force a pagereload if you resize the window

Two areas of concern have been brought up in this bug: 1) Popups on sites that reload on resize go into an infinite loop. This no longer occurs on washingtonpost because it seems they stopped pop-ups. Do we know sites where this still occurs? It would still seem to be an item to address in firefox to adjust some behavior such that popup notification and reload on resize can not cause an infinite loop be restricting the impact the pop-up notification has on the page's awareness of such notification (which would include resizing the page). 2) The current behavior of reloading on a resize. I would argue that this is ok behavior for firefox. There may be situations where a page author wishes to display things different in certain window sizes, so this is ok Firefox behavior. Thou, the necessity of this in site design is probably the area which should be questioned. Does washingtonpost (or it's advertising) really need to reload on a resize? Probably not, but that's more bad site design.

(In reply to comment #14) > Two areas of concern have been brought up in this bug: > > 1) Popups on sites that reload on resize go into an infinite loop. This no > longer occurs on washingtonpost because it seems they stopped pop-ups. No. Washingtonpost.com still has popups. Try turning popup blocking off and watch. For some reason, the popup notifier does not appear. > 2) The current behavior of reloading on a resize. I would argue that this is ok > behavior for firefox. There may be situations where a page author wishes to > display things different in certain window sizes, so this is ok Firefox > behavior. Thou, the necessity of this in site design is probably the area which > should be questioned. Does washingtonpost (or it's advertising) really need to > reload on a resize? Probably not, but that's more bad site design. Netscape 4.x had a lot of problems with layout on resize. Because of this many sites, including washingtonpost.com, force NS4 to reload on resize. However, the test they use not only detects NS4, but also Gecko and Opera (but not IE). They should be using a NS4 specific test (document.layers) for adding the reload handler or they should drop just NS4 support completely. This is evangelism bug 241165 .

data:text/html,<body onload="window.open()" onresize="window.history.go(0)"> WFM running the latest trunk build as well, I can only assume that it depends on some other bug that got fixed recently! Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040905 Firefox/0.9.1+ (trunk/zip/new profile)

Well, I no longer get pop-ups from www.washingtonpost.com, but a few days ago I still was, and it appeared at that time that inb recent aviary nightlies this was at least fixed such that the page only repainted once, because the blocked pop-up notifier bar persisted during the refresh.

Please use the provided sample data: URL, as it *used* to lead to the infinite reload loop as well...

See also bug 258917, similar problem with Find bar.

"Needless" to say that plugin finder will do the same

With a day-old branch build, Oliver's URL from comment 16 doesn't infinitely reload for me, but adding an unknown plugin does: data:text/html,<body onload="window.open()" onresize="location.href=location.href"><embed type="foo/bar"></body> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040923 Firefox/0.10

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

Firefox 1.0 preview release: webpage repeated reload loops being experienced at the following Urls http://news.google.com/ http://www.washingtonpost.com/ http://drudgereport.com/ http://www.timespatriot.com/ plus several others I can't relocate in browser history. Can stop constant reloads with stop button, but page doesn't load completely. Win2000 OS, Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10

OK - the second data: url case is the simplest test for this bug because it causes plugin/popup infobars to fight, causing the window to reload constantly. They fight because they're different heights, resulting in the window being of different size constantly. You may see this at washingtonpost.com etc if you don't have flash or another plugin they use for ads, etc. This patch causes the button element on the infobar to be visbility: hidden, not display: none, forcing all infobars to be the same height. The result is not the most attractive thing for the popup case but maybe we can fix this later by making the info button smaller

I've got a strange implication of this bug. When I first came across it, it had been already fixed, but even with new version of Firefox, new profile and after wiping out any mentioning of Mozilla Firefox in the regestry I still had it. So I decided to reinstall Windows XP from clean. After that the bug disappeared. But to my surprise it reshuffled again on a different account. Basically I have 3 XP User Accounts on my PC. On two of the Firefox works fine, but on one it still has that annoying bug. Wiping out profile did not help at all. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041011 Firefox/0.10 (JTw) OS WinXP SP2