187123 - Large HTML files will sometimes never finish loading + more...

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Tom]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126 Phoenix/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021126 Phoenix/0.4

Go to the website given above, click on any artist under the ROCK section in the
left side frame.  If you click on one of the first few artists, the right frame
will display the ROCK.HTML file, which is currently over 1.7mb in size.  The
whole document does appear to fully load, but then if you scroll down to near
the end, and click an artist, such as Scorpions, for example, the right frame
blanks out, and never becomes occupied.  

And during the initial loading of the large HTML file (in this case, ROCK.HTML),
if there are other instances of Phoenix open (other windows open), they become
inaccessable until the load is finished, or has been given up on.  VERY annoying
for anything to become bogged down by anything else.

Reproducible: Always

Steps to Reproduce:
1. It's all explained in detail in the details section.

Actual Results:  
It's all explained in detail in the details section.

Expected Results:  
It should have loaded and displayed the large HTML file, and it should have done
so without bogging down other open instances of Phoenix.  Try it with other
browsers.  They all work.

Comment 1

[David Tenser [:djst]]

Just a bit annoyed by the CAPS. Also, this is NOT a major bug.

Comment 2

[David P James]

Why did you build a webpage with a 1.7mb HTML file? No one in their right mind
does that.

I can confirm this on 20022912 Linux and it did indeed bog stuff down for
several minutes and I got the blank frame as well when selecting Scorpions once
it had finished loading.

Have you tried using Mozilla to load your site? I also tried Galeon on Linux and
it locked up, forcing me to kill it. At least Phoenix survived the assault of
your oversized webpage (rose from the ashes, one might say). And Galeon is
native to Linux, whereas Phoenix is not!

This is NOT a Phoenix-specific bug. At best it is related to the Gecko rendering
engine; at worst it is INVALID. This would normally in all likelihood be an
evangelism bug but since you're the site's webmaster I'm marking it INVALID.

Comment 3

[David P James]

Got my build wrong - 20021229. I've never mixed that up before...

Comment 4

[Tom]

Suggest a way to do what I want to do in a smaller HTML file (that was generated
automatically by DiscPlay, by the way), and I'd love to do that.  The situation
will not permit it though.

This should not be invalid, as you yourself verified it.

Internet Explorer under Windows loads the document just fine.

If it is a Gecko based problem, then where should I report the bug to?

Comment 5

[David Tenser [:djst]]

Moving to browser

Comment 6

[Jesiah S]

The generated HTML file is missing </font> in the first part where it list the
artist and albums. When I load the original file Mozilla run out of memory and
dies.  When I add </font> Mozilla  uses  only ~53 MB of my memory.

I issued this command in vim
:1,7797s/<\/a><\/b><br>/<\/a><\/font><\/b><br>/
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
All files loaded off the hard drive and w/o frames.

Also Konqueror had a better time opening and scrolling through this file then
Mozilla. 

Comment 7

[Tom]

Thank you VERY much!  It's good to know the browser was not at fault.  I fixed
the template file to properly add the closing </font> tag, and all works fine now.

Comment 8

[Jason Bassford]

Reopening to resolve properly - Mozilla was neither broken nor fixed.

Comment 9

[Jason Bassford]

-> WORKSFORME