Closed Bug 93904 Opened 23 years ago Closed 23 years ago

Page loads very slowly/not at all.

Categories

(Core :: Networking, defect)

x86
Linux
defect
Not set
major

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: rtz, Assigned: neeti)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080104 Since 0.9.3 I have trouble loading some pages, e.g.http://www.unitedmedia.com/comics/dilbert/ and http://www.security-focus.com/ 0.9.2 works perfectly on the exact same page. If I load the page with 0.9.2 first, I can usually see the page in 0.9.3 too, probably because images are fetched from the cache. (try removing the entire Cache-directory if you can't reproduce) Reproducible: Always Steps to Reproduce: 1. Clear out the cache. (I remove the Cache-directory) 2. Go to http://www.unitedmedia.com/comics/dilbert/ or http://www.security-focus.com/ 3. See the page half-rendered, some images loaded, some waiting to load, or sometimes see just a blank page.
In like 15 seconds mozilla 0.9.3 on linux showed up the full page WFM
I'm having the same problem with unitedmedia.com in Mozilla 0.9.3 under Linux. However, Mozilla 0.9.3 under Windows loads the page just fine. Also, the first time I visit unitedmedia.com, the page only loads about half the images, but if I then try to go back to unitedmoedia.com, mozilla just sits there, with the animated stripey bars running in the bottom right corner. It never does actually display anything from the page.
Can you do a new profile check in Linux?
To clarify the behaviour I see: When I first hit the dilbert page, it loads partly, some images loaded, but most still unloaded, the progress bar hovering at about 20-40% (it varies). A netstat initially shows a lot of connections to unitedmedia. These are closed off, and after a few seconds there are no, or at most one, open connection to unitedmedia. If I press reload I see the "barber pole" rotating forever, it never turns into a progress bar. Here I see no new connection with netstat, and no DNS query in my querylog. If I quit mozilla, restart och hit the page again I get a few more images this time, and after two or three quit+restart the page is fully loaded. However I can never load the entire front page of http://www.security-focus.com/ in this way, possibly because some content isn't cachable.
I see exactly the same thing on Build ID 2001080810 on Linux. On the front page of www.unitedmedia.com (as well as the Dilbert page) lots of images never load. According to tcpdump there are no retransmissions or any signs of Mozilla trying to load the remaining images, but since the "barber pole" continues to spin and never stops, Mozilla obviously knows that it's not done. Loading the same page on Netscape 4.76 works fine on the same machine (both before and after the attempt to load it with Mozilla.) I have cleared out the entire .mozilla directory and started with a fresh profile, but this doesn't change the symptoms. I think this might be another instance of bug #68151.
I'm not seeing this on my Linux NS 6.1 RTM build. Can I get an update from everyone who reported a problem with either other two sites discussed above?
Yes, I have this problem with both unitedmedia.com and security-focus.com For the record, I'm running RH 6.2 with the latest Ximian Gnome stuff.
Reporter, please test against the latest nightly; many image problems have been solved lately and the page you suggest looks great in 2001090308!
Works fine for me now, with Build ID 2001090408 on Linux. (With 2001080810, I could reproduce the problem 100% of the time, provided that I cleared the disk and memory caches before trying.)
Reporter, we want to close this bug. Can you please provide feedback after testing with the latest nightly? Help the QA team! :)
All the sites I had trouble with load ok with Linux-2001090408. I guess it's fixed.
Whee! Another bug squashed as WFM.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Yeah, it works great for me too in the latest nightly.
If you have permissions, I am also trying to encourage people to verify their own bugs if it is untargeted and WFM (actually more like works for you...)
reporter: This bug is a "futured" or "untargeted" bug which has been "resolved/works for me". Most bugs meeting this criteria are usually somewhat out of date or working in the current builds. If this bug is not happening for you in a recent build (such as the Mozilla daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME" If you reported the bug on a platform (e.g. Linux) and other contributors reported on another platform (e.g. Mac OS), please comment that it works for you but do not verify it yet. For these multi-platform bug reports, we need to verify all reported platforms -OR- create new "still broken on platform X" bugs when you verify.
So I'm supposed to mark it as Verified? Oh well... <clickety-click>
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.