95007 - Page causes long pauses/lockups in browser

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[Sean Harding]

In Mozilla on Linux 2.4.7 and FreeBSD 4.2 (0.9.2 and 0.9.3 respectively),
http://www.cityofseattle.net/fire/ and most or all of its subpages causes
several second long browser lockups. During the "lockup," the browser consumes
as much CPU as it can get, doesn't respond to any input and none of the windows
update. This lasts between 5 and 20 seconds and happens every time the page is
displayed, incuding from the cache. The page doesn't seem to include any images
or content from another server, so I don't think it's timing out on something
like that. Maybe it's taking a long time bulding the <select> menus? I really
have no idea, but for me it's 100% reproducable.

Comment 1

[Doron Rosenberg (IBM)]

can you try "./mozilla -ProfileManager" and create a new profile and see if that
still occurs?

Comment 2

[Sean Harding]

Yes. This still occurs with a brand new profile.

Comment 3

[Christian Reis]

Doron, I can reproduce in 2001083108 just by scrolling that page a bit. Can't you?

Slow selectbox filling would be bug 97345 but this doesn't seem to be the
problem: you can load the HTML into the browser and get no hangs. I _think_ this
has to do with the two javascript snippets at the bottom. Checking.

Comment 4

[Christian Reis]

This page is an HTML nightmare (use the W3C validator to check). I think it's
probably a DOM/JS parser problem, but let me see. If you pay attention, the
slowness is involved with the initial menu draw (on the left) and then when
mousing over the menus. I can't get a small testcase working, however.

I'm afraid the JS in this page is too confusing for me to track down the problem
without wasting a lot of time. It's making heavy use of AllWebMenus if anybody
has a bit more time. 

Comment 5

[Christian Reis]

I've managed to get to a paired-down example. I think this is just mozilla being
slow, very slow, in taking a very hard lump of JS. Over to DOM/Perf gods for
their opinion, dupe?

Comment 6

[Christian Reis]

Attachment: (sorta) paired down testcase. hover mouse over pink table, about 50px down, and wait

Comment 7

[Doron Rosenberg (IBM)]

ok, seeing also on win98 2001083103

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

ARGH!!!!  ns4.7 ate my comments when I hit back to correct an email address. 
I'd typed in an extensive analysis of where the cycles are going.  ~70% are
going to table reflow.  About 37% are going into style data which is called from
the reflowstate::init routines.  Look at the flat hits and work up from #1 and
#'s 2-5 and #10.

This (as my jprof will show) is a reflow/style issue.  In particular  
nsTableFrame::ReflowTable
 nsFrame::Invalidate
   nsViewManager::UpdateAllCoveringWidgets

and 
nsHTMLReflowState::Init
  nsFrame::GetStyleData
    nsStyleContext::GetStyleData
      nsRuleNode::GetStyleData

Removing DUPEME since this appears to not be a JS engine/etc issue; it's a
reflow/style system issue and/or an issue with the JS code in the example.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

Attachment: jprof of loading and hovering with testcase

Comment 10

[Ashley Bischoff (blog at handcoding.com)]

Related to bug 95984?

Comment 11

[Christian Reis]

No, Alex, this bug is a specific JS slowness problem, not a general freeze.

Comment 12

[Brendan Eich [:brendan]]

christian: layout/style, not JS, slowness problem, per rjesup's jprof results. 
Cc'ing hyatt.

/be

Comment 13

[Prashant Desale]

Severity = MEDIUM [No Crash but its locking browser fro good amount of time, No 
severe functional failure, No Cosmetic failure]
Visibility = MEDIUM [Real world website usage, Gets one point of compatibility 
with other browsers since it works on other browsers.] 

Priority = Visibility * Severity

Priority = p3

adding word "qawanted" because I'm setting this priority on available data & if 
someone feels otherwise then please investigate this more & feel free to change 
this priority.

Comment 14

[Prashant Desale]

Priority=p3

Comment 15

[Nicholas Clark]

http://stat.fsu.edu/~geo/ will also cause an indefinate hang.
This may be the same bug. Maybe not, as http://stat.fsu.edu/~geo/ is a very
simple page and w3m's validator finds only 4 errors in it.

Comment 16

[Vadim Berezniker]

here it freezes 0.9.9 but not trunk 2002041211 ...

Comment 17

[Vadim Berezniker]

Nick, that problem is bug 121841 and it seems to have gone away ...

Comment 18

[Jacob Kjome]

We are using AllWebMenus and have a page that works fine with Mozilla 0.9.2, but
spikes the CPU and never renders any of the menus in the latest nightly build
(on Win2k sp2sr1).  I can't post the code because of NDA, but the same thing
seems to happen at AllWebMenu's home page:  

http://www.likno.com/

There should be an example menu on the left side of the page.  This works with
all modern browsers except for the latest Mozilla (not sure how far back you
have to go in builds before it works again?).  Again, this *does* work in
Mozilla 0.9.2...with a few quirks in the layering of the menus (some menus end
up behind text on the page).

And I just got word from a friend using Linux saying that he sees it working in
0.9.2 there.  He hasn't tried it on the latest nightly yet.

So, this bug is definitely still with us.

Any timeline on fixing it?

Jake

Comment 19

[Kevin McCluskey (gone)]

WFM: http://www.likno.com/ menu displays and sub-menu's appear when hovering
over them using 2002/7/12 Moz1.0 branch build on WinXP.

Comment 20

[Jacob Kjome]

Yep, on a recent trunk build, everything works on http://www.likno.com/ except 
that IE6 is still noticably faster than Mozilla in displaying the menus.  
However, the stuff I reported in comment 18 is no longer an issue.

Also, the page at http://www.cityofseattle.net/fire/ still does cause a small 
lockup at page load, but not anything too bad.  Actually, in IE6, I get a 
similar lockup on page load (slightly less time involved) and the menus are 
pretty slow in IE6, although still a bit faster than Mozilla.  I think the main 
issue with that site is that the javascript is simply inefficient rather than 
this being a particular browser issue.

I think this could probably just be covered under bug 21762 with 
http://www.cityofseattle.net/fire/ as a test case.  I'll let the reporter and 
jst decide what to do with this bug, though.

Jake

Comment 21

[Markus Hübner]

What are we gonna doing about this one now?
[suggest marking wfm]

Comment 22

[Christian Reis]

Yep, worksforme. Though I can't access the original site, the testcase is not
locking up any more, even if it's not exactly speedy on my slower boxes.