User-Agent: Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 On the page http://www.washingtonpost.com/ once it is loaded, it will reload cyclically substituting a series of images in the place of the main image. In other browsers and previous builds, the image would change only upon revisiting the site (a cookie would aid in this, I suspect) I can stop the relaoading when I open another tab. If I resize the window, the reloading will resume. Reproducible: Always Steps to Reproduce: 1.Open http://www.washingtonpost.com/ 2.Wait. (page will reload continuously) 3.Open new tab (reloading will stop on http://www.washingtonpost.com/ tab) 4.click on http://www.washingtonpost.com/ tab. 5 Resize browser window (continuous reloading resumes) Actual Results: Page continues to reload Expected Results: Page should be static. Main image should change only upon revisiting the page from antother. Behavior was as expected with IE and with Mozilla 1.6

Disabling cookies does not affect this behavior

Worskforme in a Feb 26 Linux cvs build....

Dupe of bug 235293? I seen a few bugs like this in the past few days(I'm looking at bugs about a month old). It seems like the onresize is always firing. And the onresize function is to refresh the page. NOTE: I didn't see the onresize handler but when I resize the page it does refresh. WFM LInux 2004032308

I saw the same problem, and isolated it to the Orbit 3+1 theme. Modern theme works fine. Adobe.com showed the problem more consistently. Moz 1.7b on WinXP Pro.

This bug for the Orbit themes may help diagnose the problem: http://mozdev.org/bugs/show_bug.cgi?id=6073

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

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

Testcase, courtesy Markus Wicki in bug 235293

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

Confirming: Component -> Skinability (see next comment) Hardware -> All OS -> All Changing Summary for better search results: was: page continually reloads; image changes repeatedly now: Continuous page reload with certain themes [refresh, skins, Orbit 3+1, javascript, onResize, resize, infinite, endless, loop]

This may belong in tech evangelism, though it didn't occur on Moz 1.6 and previous milestones, in my experience. However it's categorized, I strongly suggest leaving it open so future bug reporters don't file dupes. As far as I can tell, the cause is as follows: 1) Websites detect a 'Netscape' browser 2) Erroneously expecting old NS 4.x behavior, the site reloads the page on resize using javascript onResize 3) Some themes, at least Moz 1.7b with Orbit 3+1 (themes.mozdev.org/themes/orbit.html), resize the page during page load, triggering the reload, which triggers the resize, etc. I'm not clear on this point; see these bugs for more info: http://mozdev.org/bugs/show_bug.cgi?id=6073 http://bugzilla.mozilla.org/show_bug.cgi?id=178595#c6 (and following) Triage Notes: * The bug does *NOT* occur using Moz 1.6 (or any previous milestone) and Orbit 3+1, on WinXP Pro, in my experience. * For me, the bug occurs using Orbit 3+1 on Moz 1.7b on XP Pro * Bug 178595 contains some discussion of it. * See bug 237154 for same problem on Firefox. * Bug 201710 complains about a reload when the window is manually resized, but not an endless loop of reloads * Possibly related, though there's not enough info to verify it: bug 234499 bug 154154 * For more sites affected by this bug, see bugs duped to this one.

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

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

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

I can confirm this problem with 1.7b and Orbit 3+1 on pages like http://www.pg.com or http://www.wko.at Thanks to this report I changed back to Modern theme and performance is now normal.

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

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

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

Note: it's not just a bug in Orbit 3+1; other themes are also affected: from duped bug: http://bugzilla.mozilla.org/show_bug.cgi?id=239516#c9 ----------- Reporter mailed: "I went back and checked the theme page and discovered that I did have another theme loaded - OXilla from Multizilla. You were correct - that was the problem." -----------

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

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

Another example of other themes causing the problem, from bug 239740: > I disabled the MicroMozilla theme and it solves the problem

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

Because at least a few different themes exhibit the problem, I think skinnability might be broken. Skinnability might not be essential, but it would be embarrasing if it were broken for a stable milestone release. Requesting blocking 1.7.

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

Just tested it with 1.7 RC1 and Orbit 3+1 (Version for 1.7 from MIK) and it's still broken. My testpage is http://www.getmobile.de. After the Introscreen all screens are constantly reloaded. This is really annoing - please don't let 1.7 ship with this bug.

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

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

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

Can someone please fix the typo in the summary "OXilla" should be "OSXilla". It took me ages to find this bug without it :)

Summary s/OXilla/OSXilla/

Someone who cares about this bug and these themes which are triggering this problem would do everyone a huge favor by figuring out which build was the last working build (and in so doing, indentify a 1 day window of Mozilla cvs changes where this started happening). If we can identify the change in Mozilla that caused these themes to start resizing the window, that would probably go a long way toward getting this problem fixed. If it's older than the builds at http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/ then try http://archive.mozilla.org/pub/mozilla/nightly/

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

Just checked a number of Windows nightly builds with Orbit3+1 theme installed. This bug first time appears in 04-feb-2004 build, so the last working build dated 03-Feb-2004. Hope this helps to resolve this bug within 1.7 release.

Could it be the checkin for bug 47909? It was checked in at 2004-02-03 16:04. It toggles stuff in the statusbar "on-load and on-finished-loading", which kinda rhymes with this bug. In addition, there might be a one-pixel-off issue lurking there, possibly helping the matters further. (Bug 47909 comment 58 - attachment 144619 [details])

Sorry for the spam: mailed cbiesinger@gmx.at about this bug.

Hum hum... this bug still seems to be very much alive in RC1 on WinXP Pro (Orbit 3+1) and someone in #mozillazine verified that it is still in the nighlty releases.. I can also testify to that it is not an issue in 1.6 as mentioned above. It does not seem to be a problem with Adobe.com anymore but still is with washingtonpost.com and also a new contestant http://www.konsumenternasforsakringsbyra.se.

here's the list of bugs referenced in the bonsai log for that day: http://tinyurl.com/39bmx here's the bonsai URL for changes that day: http://tinyurl.com/28kb4

Visually this definitely looks like it's a regression from bug 47909.

Steps to reproduce this bug *without* any 3th party theme installed! 1) Menu>View>Show/Hide/Component Bar P.s. this is my (dirty) work around for WinXP/Classic Theme: .statusbarpanel-iconic { min-height: 2.5em !important; } Just undo the patch for bug 47909 and the problem is gone ;)

We can fix classic theme with this small change: http://lxr.mozilla.org/seamonkey/source/themes/classic/global/mac/global.css#139 - min-height: 1.9em !important; + min-height: 2.0em !important;

hmm, well, it does sound like a regression from that bug... But, it seems like this is an inherent problem when fixing that bug. shouldn't the themes be fixed?

(In reply to comment #43) > hmm, well, it does sound like a regression from that bug... But, it seems like > this is an inherent problem when fixing that bug. shouldn't the themes be fixed? I agree. Just add that CSS snip to your userChrome.css to see if that works for you (only to get the right value). I personally hope that we're going to use 2.5em because that also solves the 'hiding/showing component bar reloads page' bug. Toggling the component bar shouldn't reload a web page, because we have to pay on a per view basis because we use a VSAT connection for our Internet connection. Oh, and please note that our agency has 86.400 employees world wide that are using Mozilla/MultiZilla, so I'm not the only one with this problem. Lets also fix modern theme while we at this, because that needs padding/margin. Just look at the component bar (again, I'm using WinXP) and you'll notice that the images are almost touching the bottom of the window and that looks horrible.

Is there a way you could use a different hiding mechansism so that the progress meter and component bar still contribute to the height? (such as setting width to 0 or 1px and perhaps visibility to hidden?)

(In reply to comment #45) >Is there a way you could use a different hiding mechansism so that the >progress meter and component bar still contribute to the height? (such as >setting width to 0 or 1px and perhaps visibility to hidden?) You would have to find a form of styles that will override whatever any theme is likely to set - at a minimum that would be max-width: 0; margin-right: 0; margin-left: 0; visibility: hidden; - but that would only apply to the progressmeter, not to the similar component bar issue, because changing the way it is hidden will break existing profiles; to resolve that it really is up to the theme to define a reasonable minimum height for the status bar so that the component bar (or indeed the progress meter) may safely be hidden.

(In reply to comment #43) > hmm, well, it does sound like a regression from that bug... But, it seems > like this is an inherent problem when fixing that bug. shouldn't the themes > be fixed? IMHO backward compatibility is far more important, especially when it fails so spectacularly: * Whole, very popular websites are broken * Typical end users will have a hard time fixing it. They may think Moz is broken: They'll install their favorite theme, and everything will work fine. 3 days later they'll visit one of the 'broken' websites and Mozilla won't work. They won't know why. Mozilla will look broken, and the cause will be difficult for typical end users, like yo mama, to diagnose.

(In reply to comment #47) > They'll install their favorite theme, and everything will work fine. 3 days > later they'll visit one of the 'broken' websites and Mozilla won't work. > > They won't know why. Mozilla will look broken, and the cause will be difficult > for typical end users, like yo mama, to diagnose. As one of those technically challenged end-users (who happened to report this initially) I couldn't agree more. UNLESS it were released saying that only certain themes worked. But then that wouldn't look too good, given that skinability is such a great feature.

(In reply to comment #48) > As one of those technically challenged end-users (who happened to report this > initially) I couldn't agree more. UNLESS it were released saying that only > certain themes worked. But then that wouldn't look too good, given that > skinability is such a great feature. No, Mozilla 1.7 can't be released without a fix for Classic theme. Btw, this will also solve the other theme issues, simply because they are based on Classic.

Please note that the classic theme uses a native progress meter whose height on one platform may differ from its height on other platforms. That's an additional reason to prefer the approach in comment 45.

... oh, and never mind that the classic theme also uses system fonts, so if the user's system fonts are smaller than normal, 'em' will be smaller than normal, but the progress meter itself likely won't. (Yet another advantage of comment 45's approach.)

Regressed since 1.6. Testcase.

I try to update the Orbit 3+1 theme since the original developers don't do so any more. Today I heard, that the reloading problem ist theme based and added min-height: 22px !important; after max-height: 22px; in the statusbar section in global.css to prevent the reloading. Now the statusbar doesn't resize anymore, but the icons in the statusbar go up and down. Does anybody knowm how I can fix this? You can get the version with the fix here: http://www.student.informatik.tu-darmstadt.de/~mkunz/orbit-1_7-MiK.xpi

(In reply to comment #53) > You can get the version with the fix here: > http://www.student.informatik.tu-darmstadt.de/~mkunz/orbit-1_7-MiK.xpi Thanks for this. Using the ne new version of Orbit 3+1 provided by MiK, I have found that the fix works for http://www.washingtonpost.com/ However the page does reload when I resize the window on this same site (it doesn't resize on other sites where the original bug had no visible effects). I have also found that this same page reloads on resizing the window when it is one of several tabs (again, the other pages do not reload).

Yes, strange - after applying the "fix" to MicroMozilla, the sites that had the reload problem now reload when I close other tabs.

I increased the height to 23px. Now the up and down of the icons is gone. You can get this version at: http://www.student.informatik.tu-darmstadt.de/~mkunz/orbit-1_7-MiK.xpi

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

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

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

(In reply to comment #56) > I increased the height to 23px. Now the up and down of the icons is gone. Hi Mik - thanks for the updated orbit theme. It "solves" part of the problem. I tested it on my testside (www.getmobile.de) and it isn't continously relaoding any more. So at least the side is useable now. But I also can confirm #55 on 1.7b. My testcase was the other way round: - open one of the broken sides in a single windows moz - open a new tab (ctrl+t) -> the first side now is reloading I had no testside with post-data - but I can imagine that this could cause some problems here. So my conclusing would be: Altering the themes is a workaround only. It is solving most of the symptoms - but not the real bug. There are still circumstances where this bug is affecting the user. It should be fixed for 1.7. Best Regards, Thorsten

If I understand this correctly, the page allways reloads on a resize of the window. But this is a bug of the website and not of Mozilla. The Mozilla bug was the contiunous resizing of the window.

(In reply to comment #61) > If I understand this correctly, the page allways reloads on a resize of the > window. But this is a bug of the website and not of Mozilla. > The Mozilla bug was the contiunous resizing of the window. Yes - you're right. Just tested with JavaScript disabled and no reloading occurs. There is a "<body onresize="self.location.reload()" on this page. So the problem seems to be solved with your updated theme. Thanks, Thorsten

(In reply to comment #61) > If I understand this correctly, the page allways reloads on a resize of the > window. But this is a bug of the website and not of Mozilla. > The Mozilla bug was the contiunous resizing of the window. It's a combination of problems: The fix to bug 47909 causes a resize, and then the website causes a reload on a resize. We can't fix the websites, but we can fix our code.

guanxi (In reply to comment #63) > We can't fix the websites, but we can fix our code. If by "our code" you mean the broken themes, I think that's reasonable. It looks like we've made a change which exposes a bug in themes and for that we should probably just rev the theme version. That will "break" (disable in Mozilla) all older themes, forcing at minimum that the themes push their version forward and hopefully the people with broken themes can fix the statusbar problem when they update their themes. I can either file a new bug "rev Mozilla's theme version" and resolve this invalid (not a Mozilla bug) or we can morph this into the version update bug.

Asa, Either Mozilla or the theme developers must make a change. I agree that asking the theme developers to do it is an option, but if you would address the other options, I'll leave it to you: 1) CHANGE MOZ CODE If Mozilla.org can afford the cost (developer time, etc.) -- and that's a big if; there are many demands on those resources -- it seems more efficient: o One change fixes many themes, instead of many changes to fix many themes o It provides backward compatibility 2) PULL THE FIX TO BUG 47909 Not as desirable as option #1, but IMHO functioning themes is more desirable than the aesthetics of hiding the progress bar (which is very nice, though). 3) ASK THEME DEVELOPERS TO CHANGE THEIR CODE This seems like most costly (i.e. labor intensive) solution, but if Mozilla.org doesn't have the time to devote to any of the above -- I know I don't have the time -- then it may be the only option. I don't agree that the problem lies exclusively with the themes, nor is that a useful topic for discussion. Let's just solve the problem. Let's *not* mark this bug invalid, in any case: Many people will experience the problem, and another bug, or another half-dozen, will soon appear.

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

(In reply to comment #66) > *** Bug 244445 has been marked as a duplicate of this bug. *** I'm a normal user that just downloaded RC2 and I'm experiencing the bug (I'm using theme Orbit 3+1). It is very annoying. I hope that someone will know how to fix the cause rather than the symptoms of this problem.

So I see three choices. 1. rev theme version in mozilla which disables all themes and forces broken theme users to update to a hopefully fixed theme but also forces all not-broken themes to update as well. 2. don't rev the theme version and hope broken themes get updated and that people experiencing this bug know to go get updated themes. 3. yank the fix for hiding the progress meter. I think the best answer might be 3 for the branch and 1 for the trunk.

need some help putting together a patch for backing out from the branch. leaf? others?

(In reply to comment #69) > need some help putting together a patch for backing out from the branch. leaf? > others? I am a chemist with VERY limited programming experience. If that is not an impediment, I can dedicate some time. Payam

I'll look into backing out bug #47909 from the 1.7 branch only.

ok, I've installed orbit on my 1.7 debug tree and I'm able to see the problem with that theme (but not modern) using the test case (thanks markus wicki)

Comment on attachment 149641 [details] [diff] [review] backout patch neil, can you review this back out? the fix will remain in 1.8.

Comment on attachment 149641 [details] [diff] [review] backout patch david, can you sr?

Comment on attachment 149641 [details] [diff] [review] backout patch r=biesi

I've landed the fix. but I did not back it out of the trunk, so the bug still exists on the trunk. so this is no longer a 1.7 blocker, because it doesn't affect the 1.7 branch. it does affect 1.8, so I'll mark it as 1.8a2? I'll also re-assign to asa, to decide what should be done (fix mozilla? update themes?)

clearing tm

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

I am looking at a similar bug http://bugzilla.mozilla.org/show_bug.cgi?id=195057. That happens only on embedding browsers. Any thoughts?.

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

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

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

The hiding the progress meter could probably be done in a way so that it still contributes to the height of the status bar: it could be hidden with the styles 'visibility: hidden; width: 1px; min-width: 1px; margin-right: -1px' or something like that.

Is this still a problem to Seamonkey / SeaMonkey ?