User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b; StumbleUpon.com) Gecko/20030210 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b; StumbleUpon.com) Gecko/20030210 This page flashes 6 or seven times in a very distracting way during page load, on a reasonably fast (1.3GHz) machine. The load time is also fairly high, even when loading a saved version from the filesystem. It looks like it is triggering some expensive behavior in the layout engine. IE renders this page in a snap, with no flashing. Reproducible: Always Steps to Reproduce: 1. Visit the URL given. 2. 3.
Even Nav 4.x doesn't flash loading the page :)
Probably bug 196308.
confirming with todays win2k trunk build
I confirm the problem with Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030304 and also Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4 No Problems with NC4.73, IE6, OPERA6 I think the problem here is not the same as in bug 196308 Here we see when loading: - Background is visible immediately - Text appears - goes away - reappears - goes away appears .... and so on until page is loaded completely - loading rendering page causes much CPU-load (on my system app 100%) Might be interesting: - "View Page Info" needs endless to list all links (there are very many) - On my DSL-Speed-Manager I see that always when the page reappears, the load-speed goes to 0 for a little moment - Problem is visible when I load the page in a new TAB and also if I load it in a new window - I see the Problem if I load the page in the composer, too
I ss it in Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.0.2) Gecko/20030208 Netscape/7.02 (Compact) too I had "Pipelining off"
This is a problem on Linux too. Could someone produce a minimal testcase? I suspect something's making us reframe the whole page or something dumb like that....
15 years ago
Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030311 Phoenix/0.5 I'm using the daily builds of Phoenix, and think this problem creeped in over the weekend 03-08 or 03-09. An easy way to reproduce this is just open two window tabs (about:blank) and switch back and forth. The flashing is very annoying. Looks like the code is redwawing the entire window in a black, then quiclkly refreshes the display.
Larry, you are seeing a DIFFERENT bug from this one. And the bug you are seeing is fixed on the Mozilla trunk.
Thanks Much! Sorry. After a two hour download of today's Phoenix build, the problem I was describing on IS gone. :)
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030312 200 mhz processor The page in the URL takes nearly 8 minutes to render from my C: drive. I corrected the markup by adding a <dl> before the first <dt> and a corresponding </dl> at the end of the page, and rendering time went to about 30 seconds, with no spurious redrawing. There over 1000 empty <p> </p> pairs in the page, and that may be contributing to the problem.
OK. Now how much stuff can you remove from the page and _still_ have it flash?
This is a duplicate of 115429.
15 years ago
Found invalid HTML: the DL tag is missing. Per HTML 4.0 the <DL> and </DL> are REQUIRED for defining a definition list. If you don't provide them then Moz renders the page different: now only DD's first line is indented versus the entire paragraph with proper usage of DL and DD. Compare my attached wgg-orig.html and wgg-fixed.html which I attach. It seems the original HTML contains over 1000+ DL lists where after adding DL tags we now have 3 proper DL's and no flickering. Someone mark this bug INVALID?
Created attachment 118166 [details] fixed HTML (.ZIP compressed) This is the modified HTML file. The only modification is the insertion of the <DL> and </DL> tags at proper locations. Speedy loading and completely flickerfree! (1.3 final)
Maarten, I agree that the HTML4.0 spec requires <dd>'s to be nested in <dl> </dl>'s. But the problem here is that the screen flashes and performance is awful when the markup is bad. I believe the browser should perform better than it is when rendering this specific case of bad markup. See bug 115429 for further details and a testcase exhibiting this problem.
Ronald, I completely agree with your statement above! I overlooked bug 115429, the missing DL behaviour is precisely known to bugzilla, that's a relief. It is really funny the amount of speedup you get just adding the missing DL tags! If there were a list of tips for develioping for Mozilla then this should definitely be on that list. Anyway the maintainer of the URL referenced clearly wants the functionality of the HTML definition lists so he should fix his code to include DL tags. Doing that there is no other problem with mozilla here so that renders this bug INVALID IMO. Mozilla clearly has a problem in this area but for this author that is not relevant once he adds the tags per the spec. Else make it a duplicate, but then you have two open bugs about the same thing.
*** This bug has been marked as a duplicate of 115429 ***