Linux 2.4.5/gcc-2.95/XFree86-4.0.3/0.9.2+ (don't know where this exactly belongs to) Since 0.9.2, I see form pages loading twice sometimes. They begin loading, then appear shortly and immediately load again. (can be seen most easily when clicking through bugzilla bug lists). This reminds me of the very annoying and time-consuming behaviour of the netscape 4.7x series, which exhibit this quirk always. Hope that's not a permanent regression.

grabow@darkstar.inka.de, we're going to need more information to be able to do anything about your issue. Can you please take a quick look at http://www.mozilla.org/quality/bug-writing-guidelines.html for the kinds of information we need in a bug report. Most useful would be URLs for the sites where you're seeing this unexpected behavior and descriptions of where in the layout of the page you see the reflow happen. Thanks for your help in testing Mozilla and reporting bugs.

I don't know what else you need here (I know the requirements, I've read the bugzilla advices several times...). If you read my report, any necessary information is given (except the build ID, which bugzilla did not set this time as usually: 2001063009) ==> >> (can be seen most easily when clicking through bugzilla bug lists) I think you know where to find your bugzilla bug lists.... By the way, I saw this problem also when writing >>THIS<< page (or to be more formal: http://bugzilla.mozilla.org/show_bug.cgi?id=88701). >> (don't know where this exactly belongs to) I'm REALLY not an expert in Mozilla internals, sorry... But my 20 years of programming experience tell me that this bug may not be located where it is expected to be. (I once thought that we germs (unfortunately I'm one of those) are the most annoying and formal guys, but you americans are quickly catching up....) Nevertheless, it's excellent work that you are doing and I will continue help as best as I can to catch those remaining quirks in this wonderful product !

grabow: one thing we need to reproduce this bug would be an URL or a testcase, which show this problem. This would make it easier for us to say, if it is a new bug and where it belongs to. I sadly can not reproduce it on the bugzilla page you mentioned (linux 2001070121). This bug is now in layout, why do you think it does not belong here? thanks ahead!

From the description provided, I can't reproduce this issue under Linux Redhat 7.1 with the July 2nd build. Reporter, please check in the latest Linux build.

Checked the last gcc2.95 build today 2001070309. No change in behaviour. Still THIS page here exibits the problem (among a couple of other bug reports), but it's not exactly URL bound. To be specific, I see the page building up to about the header of 'Additional Comments', then mysteriously the Mozilla dragon head appears twice nearly inside the 'Add CC:' and the 'Component/Status/Resolution' fields, and shortly after that the page clears and begins to build up again (seems there's some internal rearrangement of components going on which is visible to the outside). Other pages just load and show only a short halt instead of clearing and building up again, which is really time consuming for larger pages than this one. There's NO network activity (reload) during the second buildup, so the Layout component maybe the right addressee (I suspected also a caching problem or something specific to form handling, as this only applies to form pages). As said, the same effect can be seen on old Netscape 4.7x series on Solaris 7 for a wider range of page types. Please note that I use the gcc-2.95 build WITHOUT Redhat compatibility libraries, since I have a completely gcc-2.95 glib221 built 2.4.x linux system (no specific distribution, but closely resembling a Suse 7.2). The mainstream branch linux builds crash very quickly and violently on this system, whereas I've seen no such problems with the gcc-2.95 build.

i remember that I see this behaviour at home with a slow connection (56k). Perhaps Hyatt's 1.2 seconds painting suppression (bug 77002) makes reproducing with faster connections so hard, since the page is finnished before the 1.2 seconds are over?

Ah ! Good hint ! I downloaded this page and viewed it locally ==> no problems at all ! Seems an ISDN connection is just too slow.

I think its now on the layout freaks, to decide, if this is really a bug or a feature. Mozilla is very agressive and tries to render a page, even if it is not completly available. So the behaviour you described might be wanted in most cases, even if it looks strange in some situations. In that case, this bug would be invalid :-/ if someone from the layout department looks at it: go to a large bug in Bugzilla using a slow connections (56K or ISDN) and look at the place where all the pulldown menus and input forms comes in later...

Partly agree. I think this should be handed over to the performance group, maybe this gives a hint how unnessary page clearing and redrawing can be circumvented.

I have W2K, Mozilla 0.9.2, no proxy. I'm not sure if it's just an issue with forms, I'm seeing this behavior on _a lot_ of pages, e.g. http://www.rpgdot.com or the mozilla bug pages, more often the larger a page seems to be. And yes, it is only apparent with slow connections (I have ISDN)... Now, if Mozilla would merely redraw a page from scratch, making use of the cache, that would not be a problem, but it [i]reloads[/i] the entire site from the server. Sometimes downloading a page is almost finished, and suddenly it would start over. Very annoying. Arhu

FWIW, I see something like this with several bugzilla bug pages on Win98 using build 2001082703. When the page starts to load and do layout, the form controls appear where they are supposed to. Then something (reflow?) happens which causes many controls to disappear (but not the labels). The form controls and labels then appear below the original form. When I click on a remaining form control (input) in the top form, the page jumps to and puts focus in the corresponding control in the bottom form. The page source (using view source) looks to be OK. I'll attach a screenshot. Note that some page content is duplicated in the CC (textarea?) box also...don't know if it's related to this bug or not. The bad content in the textarea appears after scrolling the page with the scrollbar. Maybe bug 24397 is related?

Linux build 2001082708. I was seeing this with bugzilla bug reports, but with this version it appears to be fixed.

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

bug 87462 may also be a dup of this. In fact, everything may be a dup of bug 77702. Either way, I don't think this is fixed, it just takes a slow link and the right phase of the moons to reproduce.

reassigning to core owner...oh boy this is a doozy. I cant reproduce it at all, but apparently its low tide or something and i dont have a chicken to sacrifice.

see also bug 117347 (maybe dup) where the double load has side effect in reflow and when saving page locally

Maybe a good page to see this effect: http://aktuelles.t-online.de/nach/pano/ungl/arti/CP/ar-lima.html (this will probably not live long) The page reloads very late after it has completed status. This happens even if you click the reload button after.

Hi, I post here to confirm the bug is in Mozilla 1.2a Also, there seem to be many dups of this bug. Please look at: Bug #99981 and Bug #77702 How to reproduce: 1. use a tranparent proxy (Squid) 2. run "tail -f access.log | grep html" on your Squid proxy 3. restart Mozilla 4. Go to: www.gamespot.com 5. click on the top of the screen in the "News" link 6. in the top of the page, you find this line: "Read News: ALL | CONSOLE | PC | XBOX | PS2 | GC | GB " Click on the "PC" Link 7. the page load twice 8. in your Squid proxy log, you see this: 1032486987.858 3849 192.168.1.1 TCP_MISS/200 46764 GET http://gamespot.com/gamespot/filters/news/0,10849,6013054,00.html - DIRECT/206.16.7.15 text/html 1032486996.796 8849 192.168.1.1 TCP_MISS/200 46764 GET http://gamespot.com/gamespot/filters/news/0,10849,6013054,00.html - DIRECT/206.16.7.15 text/html Always reproducible: Yes How to reproduce again: Follow the above steps. Remember to restart Mozilla. Notes: This page has: - meta: <meta http-equiv="expires" content="Tue, 20 Aug 1996 01:00:00 GMT"> <meta http-equiv="Pragma" content="no-cache"> <meta NAME="ROBOTS" CONTENT="NOARCHIVE"> - page ends with this line: <SCRIPT LANGUAGE="JAVASCRIPT" SRC="http://www.zdnet.com/include/ads/campaigns/pages/spnlinks/includes/gamespot_perm.js"> </SCRIPT> </body> </html> - Only happends in Mozilla. In IE6.0 the page loads only once as reported by Squid proxy log. - Tested in Mozilla 1.1Final and 1.2a on WinXP

This has something to do with my profile. I created a new profile and can't reproduce the bug anymore. Then, I restart Mozilla with my old profile and the bug is still there. So, this has something to do with a corrupted profile. I have been using this profile since, mmm, don't remember. :-) It has to have like 1,5 years old and I tryied all the Mozilla official releases(betas or stable)

Solved! I was debugging my pref.js file, deleting lines and trying the test case from comment #19 and when I deleted this line: user_pref("intl.charset.detector", "zh_parallel_state_machine"); the bug was solved. I don't know in which build I got that line in my prefs.js file, but when I create a new profile in 1.2a, that line is not added in the new prefs.js file for the new profile. Can someone check this to see if it works for someone else too?

another to solve this bug is by selecting the menu: View->Character Coding->Auto-Detect->(Off)

Is this bug still reproducible after following sugestion in Comment #22 ? Auto-Detect->(Off)

Two things : - If the targeted page contains a good encoding line (ie <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> for instance) there's no problem. - This behavior exist on post forms too, so the data are posted twice ...

->Internationalization

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

Verified as dup.