61684 - 99% CPU utilization and general freezing when viewing a large document

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Archit Shah]

The URL (http://www.kuro5hin.org/?op=displaystory;sid=2000/11/25/85818/349)
causes the latest nightly (20001130) to freeze up and go to 99% CPU utilization.
After freezing up, it was still able to accept my Ctrl-Q and quit cleanly.
Platform: x86 RedHat 6.1/2

Comment 1

[gstoll]

I also see this on Linux 20001130, although it didn't accept my Ctrl-Q.
Downloading the page (in something else) and loading it in Mozilla lets it load
the page, but still goes to 99% CPU usage and won't respond to stuff.  I'll
attach the page, then try to get a minimal testcase.

Comment 2

[gstoll]

Attachment: The page that makes it 99% CPU.

Comment 3

[gstoll]

*sigh*  Can't seem to get a minimal testcase.  I think the problem is the lines
of 4096 characters that are then cut off, often in the middle of a tag.  So it's
probably not really Mozilla's fault, but I don't think it should hog all CPU
time...anyway, that's all from me.

Comment 4

[Andreas Franke (gone)]

Not sure if this is a correct use of the "freeze" keyword, but adding it
together with "perf" to indicate a "freeze" that goes away after some time.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Stack trace for this one:

 #0  0x40035f76 in DeviceContextImpl::GetMetricsFor (this=0x85cc240,
aFont=@0x88278cc,
    aMetrics=@0xbfff4120) at nsDeviceContext.cpp:288
#1  0x40fc178b in nsRenderingContextGTK::SetFont (this=0x888f448, aFont=@0x88278cc)
    at nsRenderingContextGTK.cpp:631
#2  0x4148e517 in nsInlineFrame::ReflowFrames (this=0x8a42828,
aPresContext=0x863f150,
    aReflowState=@0xbfff4340, irs=@0xbfff41ec, aMetrics=@0xbfff4304,
aStatus=@0xbfff4460)
    at nsInlineFrame.cpp:498
#3  0x4148dfc7 in nsInlineFrame::Reflow (this=0x8a42828, aPresContext=0x863f150,
    aMetrics=@0xbfff4304, aReflowState=@0xbfff4340, aStatus=@0xbfff4460)
    at nsInlineFrame.cpp:323
#4  0x4149396a in nsLineLayout::ReflowFrame (this=0xbfff4500, aFrame=0x8a42828,
    aNextRCFrame=0xbfff4d80, aReflowStatus=@0xbfff4460, aMetrics=0x0,
    aPushedFrame=@0xbfff445c) at nsLineLayout.cpp:919
#5  0x41459e81 in nsBlockFrame::ReflowInlineFrame (this=0x89f0438,
aState=@0xbfff4d08,
    aLineLayout=@0xbfff4500, aLine=0x8a42860, aFrame=0x8a42828,
    aLineReflowStatus=0xbfff44af "") at nsBlockFrame.cpp:4362
#6  0x41459b6a in nsBlockFrame::DoReflowInlineFrames (this=0x89f0438,
    aState=@0xbfff4d08, aLineLayout=@0xbfff4500, aLine=0x8a42860,
    aKeepReflowGoing=0xbfff4aac, aLineReflowStatus=0xbfff497b "\002",
    aUpdateMaximumWidth=0, aDamageDirtyArea=0) at nsBlockFrame.cpp:4247
#7  0x41459972 in nsBlockFrame::DoReflowInlineFramesAuto (this=0x89f0438,
    aState=@0xbfff4d08, aLine=0x8a42860, aKeepReflowGoing=0xbfff4aac,
    aLineReflowStatus=0xbfff497b "\002", aUpdateMaximumWidth=0, aDamageDirtyArea=0)
    at nsBlockFrame.cpp:4179
#8  0x41459765 in nsBlockFrame::ReflowInlineFrames (this=0x89f0438,
aState=@0xbfff4d08,
    aLine=0x8a42860, aKeepReflowGoing=0xbfff4aac, aDamageDirtyArea=0,
    aUpdateMaximumWidth=0) at nsBlockFrame.cpp:4126
#9  0x41457c8b in nsBlockFrame::ReflowLine (this=0x89f0438, aState=@0xbfff4d08,
    aLine=0x8a42860, aKeepReflowGoing=0xbfff4aac, aDamageDirtyArea=0)
    at nsBlockFrame.cpp:3260
#10 0x41457182 in nsBlockFrame::ReflowDirtyLines (this=0x89f0438,
aState=@0xbfff4d08)
    at nsBlockFrame.cpp:2949
#11 0x41454b60 in nsBlockFrame::Reflow (this=0x89f0438, aPresContext=0x863f150,
    aMetrics=@0xbfff50b8, aReflowState=@0xbfff5014, aStatus=@0xbfff5e80)
    at nsBlockFrame.cpp:1740
#12 0x41465029 in nsContainerFrame::ReflowChild (this=0x89f03d8,
aKidFrame=0x89f0438,
    aPresContext=0x863f150, aDesiredSize=@0xbfff50b8, aReflowState=@0xbfff5014,
aX=0,
    aY=0, aFlags=0, aStatus=@0xbfff5e80) at nsContainerFrame.cpp:693
#13 0x41697e4f in nsTableCellFrame::Reflow (this=0x89f03d8, aPresContext=0x863f150,
    aDesiredSize=@0xbfff5264, aReflowState=@0xbfff51bc, aStatus=@0xbfff5e80)
    at nsTableCellFrame.cpp:807
#14 0x41465029 in nsContainerFrame::ReflowChild (this=0x89f0388,
aKidFrame=0x89f03d8,
    aPresContext=0x863f150, aDesiredSize=@0xbfff5264, aReflowState=@0xbfff51bc,
aX=0,
    aY=0, aFlags=0, aStatus=@0xbfff5e80) at nsContainerFrame.cpp:693
#15 0x416acf30 in nsTableRowFrame::InitialReflow (this=0x89f0388,
    aPresContext=0x863f150, aDesiredSize=@0xbfff5518, aReflowState=@0xbfff53b8,
    aStatus=@0xbfff5e80, aStartFrame=0x0, aDoSiblings=1) at nsTableRowFrame.cpp:1128
#16 0x416add20 in nsTableRowFrame::Reflow (this=0x89f0388, aPresContext=0x863f150,
    aDesiredSize=@0xbfff5518, aReflowState=@0xbfff5470, aStatus=@0xbfff5e80)
    at nsTableRowFrame.cpp:1532

and so on for about 200 levels of reflow recursion.

Comment 6

[Boris Zbarsky [:bzbarsky]]

And the console massages also point at reflow problems:

###!!! ASSERTION: reflow dirty lines failed.
: '0', file nsBlockFrame.cpp, line 1742
###!!! Break: at file nsBlockFrame.cpp, line 1742
nsBlockReflowContext: Block(li)(4)@0x894ad38 metrics=-559038737,-559038737!
nsBlockReflowContext: Block(li)(4)@0x894ad38 didn't set whad
-559038737,-559038737,-559038737,-559038737!
###!!! ASSERTION: reflow dirty lines failed.
: '0', file nsBlockFrame.cpp, line 1742
###!!! Break: at file nsBlockFrame.cpp, line 1742
nsBlockReflowContext: Block(ul)(90)@0x8944b6c metrics=-559038737,-559038737!
nsBlockReflowContext: Block(ul)(90)@0x8944b6c didn't set whad
-559038737,-559038737,-559038737,-559038737!
###!!! ASSERTION: reflow dirty lines failed.
: '0', file nsBlockFrame.cpp, line 1742
###!!! Break: at file nsBlockFrame.cpp, line 1742
nsBlockReflowContext: Block(form)(24)@0x884d8c4 metrics=-559038737,-559038737!
nsBlockReflowContext: Block(form)(24)@0x884d8c4 didn't set whad
-559038737,-559038737,-559038737,-559038737!
###!!! ASSERTION: reflow dirty lines failed.
: '0', file nsBlockFrame.cpp, line 1742
###!!! Break: at file nsBlockFrame.cpp, line 1742
nsBlockReflowContext: Block(body)(2)@0x86a94b0 metrics=-559038737,-559038737!
nsBlockReflowContext: Block(body)(2)@0x86a94b0 didn't set whad
-559038737,-559038737,-559038737,-559038737!
###!!! ASSERTION: reflow dirty lines failed.
: '0', file nsBlockFrame.cpp, line 1742
###!!! Break: at file nsBlockFrame.cpp, line 174

This is all on a 2000-12-19 linux cvs build.

Comment 7

[Keyser Sose]

Marking NEW as per comments. Nasty bug.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

A jprof profile made it look more like an infinite loop in frame construction
than in reflow, but I'm not sure.  (Yes, I find it faster and easier to use
jprof than to use gdb.)

cc:ing buster and waterson.  This seems quite bad.

Comment 9

[buster]

verified using NS6 on WinNT.  I'll take a look.

Comment 10

[buster]

This is the old "unclosed font tag" problem.  The content tree is getting
absurdly deep.  Not only are there thousands of unclosed font tags, but in
general they serve no purpose;  they have identical attributes.  For example:

ul@029FD980 refcount=3<
  font@029FD920 face=verdana, arial, helvetica, sans-serif size=2 color=#333333
refcount=3<
    font@029FD850 face=verdana, arial, helvetica, sans-serif size=2
color=#333333 refcount=3<
      font@029FD780 face=verdana, arial, helvetica, sans-serif size=2
color=#333333 refcount=3<


I'd propose that (in quirks mode), the parser throw away inline nodes that are
identical to their parent node, so the markup:

<font size=1><font size=1>x</font></font>

just becomes:

  font size=1
    text
      "x"

Likewise for redundantly nested <B>, <I>, etc.  It is possible, though
incredibly unlikely, that this could break somebody's script.  Highly doubtful
that anyone would have a script rely on such horrible source.

Rick, Harish:  what do you think?

Comment 11

[Hixie (not reading bugmail)]

Sounds like quite an interesting idea. I'd shy away from doing this to every
inline node though. Do other tags follow this patalogical usage pattern much?

Comment 12

[buster]

rick and harish sent me private mail in favor of the proposal.  so, I'm pushing
the bug to harish.

seems like what we want is to come up with a checksum for each inline frame that
we encounter, that takes into account the tag name, and each (attribute,value)
pair.  We could store this on the element stack in the parser, and eliminate
duplicates.  The only class of duplicate I can think of that we don't want to
eliminate are the <font size=+1>, which are additive.

Comment 13

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 66849 has been marked as a duplicate of this bug. ***

Comment 15

[karnaze (gone)]

*** Bug 57966 has been marked as a duplicate of this bug. ***

Comment 16

[dylang]

Loads quickly and without problems in Mozilla build ID 2001022321, both in
threaded and flat modes.  If a few other people can veryify, maybe we should
mark this as fixed?

Comment 17

[Ronald van Kuijk]

loads quickly on Mozilla 2001031021 for me to...

Comment 18

[harishd]

Hmmm.. that surprising I haven't done yet ;-)

Comment 19

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Harish, can you check if this still occurs...

Comment 20

[Jens-Uwe]

while it does load in an akzeptable time overall, it looks like it stops for
nearly a second now and then. 
I am sure there is still space to optimize, but since even with the pauses it is
still done in an akzeptable time, I am not sure about the priority. When I load
it a second time (should be in cache now) it takes arround 7 seconds, until
mozilla cleans the screen and additional 9 seconds until the page is rendered.
This is on a P3-550 / 256MB memory, using linux 2001040521.

Comment 21

[Heikki Toivonen (remove -bugzilla when emailing directly)]

nsbeta1+ for analysis to see if this might be a more general problem. If it
turns out to be an edge case, nsbeta1-.

Comment 22

[harishd]

Any fix up in the parser would only mask the actual problem ( in layout ). And,
btw, I don't think this would be trivial fix in the parser. IMO we should either
try to fix this in the layout ( which is "mission impossible" ) or should drop
the idea altogether ( ok atleast for 6.5 ).

Comment 23

[harishd]

Fixing this would mean rewriting the layout!!! I don't think we want to go 
there. Marking WONTFIX.

Comment 24

[Chris Waterson]

I'll hold on to this for now.

Comment 25

[Chris Waterson]

.

Comment 26

[Chris Waterson]

Okay, so we still suck on this page, but its significantly better now that the
list renumbering stuff has been fixed (bug 42138). I can get it to lay out in
about 15 seconds now on a 750MHz machine. (Hey, at least it's not a crash!)

Moving out to mozilla-1.0, need to re-profile (probably jprof, to avoid timer
problems introduced with Quantify) to figure out what's going on.

Comment 27

[Tom Mraz]

The original url:
http://www.kuro5hin.org/?op=displaystory;sid=2000/11/25/85818/349
shows the behavior no more - only the attachment.

Comment 28

[Vincent Nicolas]

I personnally see this bug very often, in most pages. The time of the freeze is
dependent on the complexity of the page, I guess. Though, with "litle" page, you
don't see it.
I don't remmber having this in mozilla 0.8.1 and before. The biggest issue to be
fixed for mozilla to be a great browser, ihmo.

I am currently using moz0.9.2, build id 2001062815

Comment 29

[harishd]

*** Bug 83605 has been marked as a duplicate of this bug. ***

Comment 30

[Benjamin Mucci]

Bug 83605 who is dup of this but stays THE BUG on Moz Mac who prevents me to
drop NS4.7 as main browser. For macuser this bug (or 83605) should be P1. It's
far from to be serious to have this result under Mac:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=40854

when it's look great under other platforms.

Comment 31

[Tom Mraz]

It seems to be WFM now (linux 2001092021), please retest the testcase.

Comment 32

[harishd]

>It seems to be WFM now (linux 2001092021), please retest the testcase.

Could be due to the fix for bug 98261 :-/  

Comment 33

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

I'll try to get a jprof of this.

Comment 34

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

WFM on Linux 20010928xx
Note: this is a very fast machine and I did see a fair bit of CPU use.  On a
slow machine perhaps there's more of an issue.  I can't jprof right now for some
reason.

Comment 35

[Christopher Hoess (gone)]

Bad news...I'm still seeing very high (88-96%) CPU during the rendering of this
page on Linux, today's CVS.

Comment 36

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

jprofs are working again for me; I'll try to check this on monday

Comment 37

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 38

[Tom Mraz]

I don't see any problems with the attachment (no freezing) on Linux 2001112706
nightly. (Celeron 566MHz w/ 256MB RAM machine)

Comment 39

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

Currently takes ~8-10 cpu sec to layout on a PIII/800, so it's still taking
quite a while (about similar to Waterson's figures).

In jprof of several loads of the attachment, I see ~45% in
StyleSetImpl::FileRules(); most of that in SelectorMatches(),
SelectorMatchesTree(), nsStyleContext::GetStyleData() and
nsRuleNode::GetStyleData().  Those are mostly called from
nsCSSFrameConstructor::ResolveStyleContext().  About 30+% is used in
nsLineLayout::ReflowFrame().

Would anyone like the full jprof?

Comment 40

[Markus Hübner]

This works fine in build 2002041903 on win-xp,1.1ghz,512RAM

Comment 41

[Ronald van Kuijk]

works fine in the 200204026 nightly build on linux to..displays instantaneously
no cpu load (800 MHz/256 MB)

Comment 42

[sonne]

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:0.9.9+) Gecko/20020426

it still eats a lot of cpu cyles on my PII-375 / 256 MB. Rendering time (file
from disk) is about 15s, and page loading never stops. After rendering cpu load
is low.

Comment 43

[sonne]

sorry, 
it never stops loading because of some jpgs he can't find. So no problem here...,
but IE renders in less than 1 second :-(

Comment 44

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

On a 233MMX 64MB Win95 machine running 1.0 RC1, I get about 21 seconds of 100%
CPU to do the initial layout of the page (with UI/throbber frozen).  I'm going
to do another jprof and post it here.

It does not hang, but the average user might assume it has.

Comment 45

[Markus Hübner]

Randell, any news on that one?

Comment 46

[Markus Hübner]

Are we still doing badly?

Comment 47

[sonne]

Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.1a) Gecko/20020611

we're getting better and better. 
With same hardware as in comment 43 mentioned it takes about 5 seconds do do the
inital layout. But IE is far better :-(

Comment 48

[Markus Hübner]

Testing with trunk 2002121808 on win-xp pro things are quite fine.
What needs to be done about it?
More work (also) relating this is covered in bug 94587.

Comment 49

[seventh]

This bug is also hit upon at the URL www.msnbc.com

Comment 50

[Markus Hübner]

A new profile would help here.

Comment 51

[Rick Stockton]

Problem is small/gone using Mozilla 1.4 on my Cyrix "266"-MMX (SLOW!!!) with
128MB. Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624

The www.kuro5hin.org page begins to display in only 3 seconds, and it's
completely done after about 6 seconds. (Empty cache, loading the page into an
empty tab via my Cable broadband ~900Kb/sec.) The content appears to be as
intended. Tonight's msnbc page (comment 49) is also about 5 seconds, but this
includes visible waits for pop-ups and ads from other sites (which required DNS
lookups).

'Hang' Behavior is definitely not present on 1.4/Win98. Does it make sense to
keep this Bug open when other Bugs deal with more specific issues in layout code
and the issues here ("general freezing", "slow") are solved?

Comment 52

[Troodon]

Testcase WFM very well (fast loading, normal CPU usage).
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040621 +
Tualatin 1400 MHz.
As comment 51 suggests maybe this should be closed.

Comment 53

[José Jeria]

Also worksforme: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5)
Gecko/20041019

Comment 54

[Robin Monks]

*** Bug 81993 has been marked as a duplicate of this bug. ***

Comment 55

[Martijn Wargers (dead)]

*** Bug 297884 has been marked as a duplicate of this bug. ***

Comment 56

[Martijn Wargers (dead)]

Attachment: Testcase2

This is a testcase based on http://www.xxxtorrent.com , from the duped bug
297884.

Comment 57

[Ryuichi KUBUKI]

*** This bug has been marked as a duplicate of 145425 ***

Comment 58

[Boris Zbarsky [:bzbarsky]]

KL, NOT ALL performance bugs are duplicates of each other.  Please DO NOT dup performance bugs without solid evidence (like a profile) that they're caused by the same underlying problem.

Comment 59

[Wayne Mery (:wsmwk)]

Comment on attachment 19991 [details]
The page that makes it 99% CPU.

agree with previous comments testmoz attachment WFM, so obsoleting

Martijn, would a reduced testcase be useful?

testcase attachment 186520 [details] on SM trunk much faster - takes half the time of FF 2. improvement because of reflow patch(s)?

Comment 60

[Martijn Wargers (dead)]

I'm not sure a more reduced testcase might be useful. It can't hurt, though.
Current trunk builds seem indeed quite a bit faster.

Comment 61

[Wayne Mery (:wsmwk)]

bz has data on attachment 19991 [details] in comment 5 and comment 6, and there is a little in comment 39. But no one has profiled the other testcase or URLs and reprofiled them to see if this reflow problem is totally gone. 

but there is general agreement the UI freeze is gone.

Comment 62

[[e-mail] (:bhearsum)]

I'm experiencing this bug on http://popcon.debian.org/by_inst with the latest 3.1 nightly: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081014 Minefield/3.1b2pre ID:20081014020405

Comment 63

[Richard Moldwin]

Firefox goes to 90-100% CPU use, hangs, and locks up my computer every time I view a flash movie of browse Google Maps.  FF (3.0.10 on Windows) switches itself to Above Normal thread priority, which is probably related to the computer lockup.  I have had to cold reboot my computer 5 times today because of this.  I have tried waiting 30 minutes, but it totally hoses my computer, with lots of data loss.  There of so many of these kinds of hang-related bug reports, it's hard to know where/how to report them.  I can't even get a trace or error log out of my computer, since it completely freezes up.

Comment 64

[Cees T.]

I find that hitting the Windows key sometimes helps to unfreeze Firefox and release my mouse cursor so i can mouse over Windows's task bar again.

Comment 65

[Danial Horton]

i've experienced this in googlecode when viewing large source code.

Comment 66

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

Comment 65: (Daniel Horton) If you have any details on what you were browsing when that happened, and if it was reproducible, that'd help.  Also FF version and machine details.

Comment 63 could imply Flash; though Google Maps is AJAX, so it'd be odd for that to lock you up.  Flash Movies may well also imply device-driver video acceleration being invoked; Google Maps generally wouldn't.  Hard to tell without more data.

Comment 62 appears to be a BIG <pre> file (11MB).  This is probably just a layout-perf issue, it will finish eventually modulo paging issues (and machine speed).  Ben Hearsum: Do you still see this?  (original report was from a nightly)

Comment 67

[Danial Horton]

Its been the same in Firefox 5 since Aurora, when the page is >100% zoom.

Click http://code.google.com/p/pcsx2/source/browse/trunk/plugins/GSdx/GSLocalMemory.cpp?edit=1

Window will hang for a moment then the stop script window will appear.

if you continue it will hang almost permanently, if you click stop and try to navigate the page it will hang permanently..

Comment 68

[Mark Côté [:mcote]]

The link in comment 62 is definitely still causing unresponsiveness in Nightly, though it does eventually finish loading.  Peptest result on a 64-bit Firefox in Ubuntu 11.10 on a MacBook Pro:

PEP TEST-START | test_largedoc.js
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 101 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 122 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 71 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 104 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 76 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 134 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 109 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 142 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 155 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 184 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 198 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 222 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 256 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 283 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 319 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 361 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 403 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 450 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 517 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 273 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 98 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 105 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 107 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 102 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 282 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 101 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 941 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 716 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 75 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 938 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 209 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 983 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1123 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1311 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1407 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1541 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1709 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1846 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1975 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1867 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1869 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 1393 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 321 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 298 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 278 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 275 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 309 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 122 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 2435 ms
PEP WARNING    | test_largedoc.js | open_page | unresponsive time: 99 ms
PEP TEST-UNEXPECTED-FAIL | test_largedoc.js | fail threshold: 0.0 | metric: 37629.951
PEP TEST-END   | test_largedoc.js | finished in: 30994 ms

This was measured using a simple test in the form of the first half of the example test in https://wiki.mozilla.org/Auto-tools/Projects/peptest#Test_Format.  See https://wiki.mozilla.org/Auto-tools/Projects/peptest#Running_Tests for instructions on running peptest.

Comment 69

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

Worksforme with trunk on Linux i686 32 bit.

Comment 70

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

(In reply to Danial Horton from comment #67)
> Its been the same in Firefox 5 since Aurora, when the page is >100% zoom.
> 
> Click
> http://code.google.com/p/pcsx2/source/browse/trunk/plugins/GSdx/
> GSLocalMemory.cpp?edit=1
> 
> Window will hang for a moment then the stop script window will appear.
> 
> if you continue it will hang almost permanently, if you click stop and try
> to navigate the page it will hang permanently..

Filed bug 775306 on this one (repeats on Aurora and Nightly)

Comment 71

[[e-mail] (:bhearsum)]

This bug is very old. It's almost certainly fixed, or otherwise invalid.