Closed Bug 109050 Opened 23 years ago Closed 17 years ago

UI freezes for a few seconds loading pages on RedHat.com

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.2alpha

People

(Reporter: bulbul, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: perf, Whiteboard: [cp:20011129])

If you go <http://www.redhat.com> (and many of the daughter pages), the user interface will become inactive for up to five second after the page appears to have already completely loaded. This is reproducible always. Using Linux trunk build 2001-11-07-21, but i've been seeing this for a while.
I also see this on 2001110808. Odd.
WFM 2001110803 on Win2k. Reporter: You may wish to try a fresh profile. You can manage/create profiles with "mozilla -profilemanager".
Sorry, opening Mozilla with a new profile had no effect.
Leston: So, are you saying that opening Mozilla with a new profile doesn't work, or are that opening Mozilla with a new profile resolves the problem for you, or that the issue remains even with a new profile?
The issue remains even with a new profile, including on the latest build: Linux trunk 2001-11-08-15. I should clarify that not only does the page appear to have completely loaded, but the progress meter has cleared as well. I'm counting four seconds of UI unresponsiveness after the progress meter has cleared. That's on a Pentium II 500 mHz, i believe.
I'm seeing a similar long freeze (over five seconds) after a Bugzilla bug list with with about 90 bugs. Again, the progress meter is empty and the status line says "Document: Done" when i start counting.
Dupe of bug 77460? -> Search, on a hunch
Assignee: asa → sgehani
Component: Browser-General → Search
QA Contact: doronr → claudius
Yes, i think this may indeed be a dupe of bug 77460. When i load the RedHat.com page, the CPU load goes up to 97%, just as it does for me with the bug lists.
Ok, marking as dupe of bug 77460. *** This bug has been marked as a duplicate of 77460 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
I'm pretty sure this bug is not a duplicate of 77460. I too was seduced by the behavior - but there is no search plugin at work here with this page/site. maybe for you but I certainly don't have a sherlock file for it and by simply going to the homepage you aren't triggering any search code (well not much). So these aren't really dupes. Moreover, I'm not sure this is a browser bug so much as some poor site design. With MacOS X I correctly get the spinning beachball for a few seconds after the page appears to have finished loading (I have no idea what the hell the page is doing). Try it with a different browser - you'll see similar results - the same freaskish pause after the page has already loaded.
Status: RESOLVED → UNCONFIRMED
OS: Linux → All
Hardware: PC → All
Resolution: DUPLICATE → ---
I'm confirming because it really does happen however, my instinct is to close this as 'Invalid' but I'll wait a bit for comments before I do that.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can't reproduce this on a current build. At any rate, this is not search. (BTW, resolution of bug 91168 should have fixed your large bugzilla list problem.)
Assignee: sgehani → asa
Component: Search → Browser-General
QA Contact: claudius → doronr
Using Linux trunk 2001-11-15-06, i am still seeing this freeze with the RedHat pages. I do not get a similar delay when viewing the page in either Konqueror or Netscape 4.7. As for the poor page design argument, does anyone have an idea as to what in this page could be causing the delay? I ran the page through a validator and the only problem found was the frequent use of slashes in closing tags. I don't think that this bug should even be considered for being marked "invalid" until someone attempts to isolate what it is in the page which causes the freeze. We cannot know whether this is a Mozilla bug or a page design bug until we know precisely how the freeze occurs.
what you could do is minimize the html code to make a minmized testcase.
->layout
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen
I'm able to reproduce this issue in the Linux build (2001-11-29-13) build. After the page appears to be loaded, clicking on the menu items (File, Edit,View...) takes about 3-4 seconds to drop down the menu list. If you disable JS in the browser, the menus lists appear immediately for me.
petersen tested and verified issue on 11/29
Priority: -- → P3
Whiteboard: [cp:20011129]
Target Milestone: --- → mozilla1.2
I don't have time at the moment to make a testcase (maybe later) but, FWIW, I think the culprits on redhat.com are those drop down JS menus labelled "Products and Services", "Solutions", "Support and Docs", etc. I've been seeing similar cpu pegging going on at http://www.cnnfn.com and I believe it only happens on pages with expandable menus on the left hand side. For e.g. go to the main cnnfn page and you'll probably notice that it pegs the cpu and freezes the UI for a while. Now mouse over the "Money 101" option and notice that it has an expandable menu (as do many of the other options). Now click on the "Money 101" option and notice that the page loads pretty quickly. After loading, you'll also notice that none of the menus on this page are expandable like the ones on the main page were. Likewise, if you click on one of the articles on the main page, instead of the "Money 101" option, you get the same cpu pegging and, after loading, a page with expandable menus. My (highly uneducated) guess is that there's an algorithm in mozilla's JS implementation that's taking a heck of a long time to construct those expandable menus in the background.
Using Linux build 2002041521, and seeing the problem at both http://www.redhat.com/ and http://www.cnnfn.com/ The problem at cnnfn is relatively recent (they have introduced the expandable side menus recently), but it's extremely annoying because cnnfn pages are refreshed at regular intervals, and the browser hangs (even in other windows/tabs) whenever the page reloads.
Another site that appears to have this problem: http://www.nwa.com (Northwest Airlines) Adding perf keyword.
Keywords: perf
Blocks: 71668
Any news about that with a recent build?
2003032108/trunk/Linux redhat.com -- Not seeing the problem, but then they no longer appear to have those JS menus anymore. cnnfn.com -- Still seeing the problem, although maybe to a lesser extent than at first. nwa.com --same as for cnnfn for main page. Really slow while loading search results (e.g. type LGA and LAX in dep and arr fiends and run a search) but that probably has more to do with the tables the results are displayed in than this bug.
Just upgraded to 2003032604 and it looks like this got worse at cnnfn.com.
WFM Mozilla 20030327 but it's possible beacuse i have 1.8 GHz Athlon.
I'm testing on a 233MHz PII Not exactly top of the line, but not stone age either :-)
Could someone just create a testcase independent of various pages and attach it to this bug? That would allow us to try to figure out where the time goes more easily....
Is anyone still seeing this? If so, please attach a testcase...
shouldn’t this be closed?
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b4pre) Gecko/2008022005 Minefield/3.0b4pre. Windows 2000, Pentium 4. Page loads like any other webpage. Bug has no testcase showing possible issue. Suggest to resolve bug as WORKSFORME.
Resolving WorksForMe as per comments.
Status: NEW → RESOLVED
Closed: 23 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.