491700 - hang while resizing windows (CPU hits 100%, no interaction is possible)

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Alice0775 White]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b5pre) Gecko/20090506 Firefox/3.5.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090506 Minefield/3.6a1pre ID:20090506045618

Can anyone confirm the following issue?
Since CPU becomes 100%,  the View Souse Window can not be resized and Operation of Firefox becomes impossible. 


Reproducible: Always

Steps to Reproduce:
1. Start Minfield with New profile.
2. Open http://www.mozilla.org/projects/minefield/
3. View > Page Source
4. Resize width of the Page Source window.
5. Resize width of the Page Source window again.
Actual Results:  
CPU 100%
You can not operate Minefield.


Expected Results:  
Low CPU usage.
You can operate Minefield.


Works Fine:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090505 Minefield/3.6a1pre ID:20090505041741

Broken:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090506 Minefield/3.6a1pre ID:20090506045618

P.S. You can push "Window key" to enable operation again.

Comment 1

[Alice0775 White]

Push log between the above regrassion range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2a82ba52ed30&tochange=7518078cb842

Comment 2

[Alice0775 White]

More specific regrassion range:
Works fine:
http://hg.mozilla.org/mozilla-central/rev/47e935bd7f3b

Broken:
http://hg.mozilla.org/mozilla-central/rev/a08d1947ec5a

Push log:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47e935bd7f3b&tochange=a08d1947ec5a

Regression of checked-in of  Bug 67752. Implement interruptible reflow.

Comment 3

[klonos]

don't see this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090503 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090503044327

just updated in today's latest nightly, so restarting and shall see...

Comment 4

[klonos]

ok, I confirm this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090506 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090506045618

Also noticed that it only happens with resize operations that alter the window's width, not its height. In other words dragging the left side, right side or any of the corners of the window, but not when dragging the upper or lower side of it.

Hope this small detail helps.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Hmm.  I can't seem to reproduce this on Mac.  I'll see what I can do about reproducing this on Windows.  Fun times!

Comment 6

[Boris Zbarsky [:bzbarsky]]

And in a VM, vmware seems to go bonkers if I resize any window whatsoever (uses tons of CPU until I resize the vmware window).  But if I do resize the vmware window, there's no untoward Firefox CPU usage.

If someone has a Windows build, does removing the "toolkit && toolkit->UserIsMovingWindow()" check at http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#7036 (in nsWindow::HasPendingInputEvent) help?

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> does removing the "toolkit &&
> toolkit->UserIsMovingWindow()" check at
> http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/nsWindow.cpp#7036
> (in nsWindow::HasPendingInputEvent) help?

Yep, it does. I can reproduce the bug, and removing that line fixes it.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Gavin did one more test for me.  While the CPU is at 100% there, we keep hitting that code and UserIsMovingWindow() keeps returning true.  ere, Neil, any idea how we get into that state, given that the user isn't actually moving or resizing the window anymore.

Comment 9

[[e-mail]]

Offhand the only idea I have is to use Spy++ to watch the WM_ENTER/EXITSIZEMOVE messages to ensure that they are matched up correctly.

Comment 10

[Timothy Nikkel (:tnikkel)]

I can not reproduce this on win2k if that helps.

Comment 11

[Bill Gianopoulos [:WG9s]]

This issue only occurs if you have "Show windows contents while dragging" selected in the Display->Appearance->Settings control panel.

Comment 12

[[e-mail]]

I was locally able to demonstrate that resizing the window could trigger a strange behaviour that prevents the system from exiting the resize state. Unfortunately this condition is extremely difficult to debug.

Comment 13

[Bill Gianopoulos [:WG9s]]

(In reply to comment #11)
> This issue only occurs if you have "Show windows contents while dragging"
> selected in the Display->Appearance->Settings control panel.

Ooops.  Meant to say Display->Appearance->Effects.

Comment 14

[Bill Gianopoulos [:WG9s]]

This issue is not confined to the view source window.  It also occurs with web content.

As pointed out in the Mozillazine forums, navigating to this page:

http://livedocs.adobe.com/coldfusion/7/

and if it isn't in two frames already, click the arrow in the top left to get another on the left, with a menu.

Horizontally resizing the window at this point produces the same result as resizing the view source window.

Removing the check as suggested in comment #6 "cures" the issue on this page as well.

Comment 15

[Radek 'sysKin' Czyz]

Simply mozillazine forum index is enough to trigger this bug, although not 100% of the time.

Now, I'm not sure if this is helpful, but on the pages where it does reproduce there's a funny reflow effect when changing size: part of the page reflows immediately, and part of the page reflows only where dragging pauses/ends.

I made a screenshot of this effect on mozillazine http://members.ii.net/~syskin/blue.png
This was taken *during* upsizing the window. The top part was fully reflowing while changing window size, while the bottom part was only increasing blue border size. As soon as I paused that drag (not necessarily ending it), the bottom part would reflow as well.

Now, the freeze seems to happen before/during the bottom part's reflow. Frozen browser can have such blue border displayed.

Hopefully this helps.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> part of the page reflows immediately, and part of the page reflows only where
> dragging pauses/ends.

That's what I'd expect in some cases, sure.  But if you're seeing this, I wouldn't expect the 100% cpu thing to also happen.  That should happen effectively when the bottom part never reflows.

We could just take the resize check out, I guess, which would suck for one of the main use cases of ireflow (resizing large pages).

Comment 17

[[e-mail]]

OK, so I think I know what the issue is.

Because of problems with plugins, nsAppShell.cpp explicitly processes keyboard messages first, then mouse messages, and then other messages. (Note that this unfortunately promotes keyboard messages over mouse messages which makes it difficult to mix the two on a slow system. It does at least manage not to change the relative ordering of keyboard and IME messages.) Thus when reflow is interrupted by a GetQueueStatus(QS_INPUT) test, these messages are immediately processed and cleared before the next attempt to reflow.

The problem here is that the resize loop is a modal message loop that presumably follows standard Windows message ordering, which is to promote posted messages over input messages. As nsAppShell::ScheduleNativeEventCallback posts a message to do its work, the next message is another attempt to reflow, which promptly interrupts itself ad nauseum (well, until the window loses focus, at which point the modal event loop bails out.)

Comment 18

[Boris Zbarsky [:bzbarsky]]

Is the resize loop something we control?  And if so, can we change the ordering?

Alternately, is there a way to reduce the priority of a particular posted message?

If the answers to both of those are "no", then the obvious options seem to be either not looking at the resize state if no input events have been processed since the last time we interrupted due to resizing, or to put the reflow event for interrupted reflow off on a timeout instead of just a simple runnable...

Comment 19

[[e-mail]]

No, we can't change the ordering, which is
    * Sent messages
    * Posted messages
    * Input (hardware) messages and system internal events
    * Sent messages (again)
    * Paint messages (these are synthetically generated)
    * Timer messages (synthetic events, not Gecko timers)

Looking at other events is no good, as it's the event that we're about to post that causes the problem. Firing it on a zero timeout would work though.

Comment 20

[Boris Zbarsky [:bzbarsky]]

> as it's the event that we're about to post that causes the problem

Yeah, but if we look at other events and then _don't_ interrupt based on that, we don't post the event.

I'll try the zero-timeout thing as a first cut and see how that goes.

Comment 21

[Emanuel Hoogeveen [:ehoogeveen]]

If I visit [url=http://blip.tv/file/2106626]this[/url] page, resizing the window in -any- direction (not just horizontal) freezes up firefox and explorer until I alt-tab to make it lose focus. Is this the same bug? 

tested on: Vista x64 with SP1
user-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090514 Minefield/3.6a1pre

Comment 22

[Emanuel Hoogeveen [:ehoogeveen]]

Sorry about the broken link. For convenience: http://blip.tv/file/2106626

Comment 23

[Boris Zbarsky [:bzbarsky]]

Almost certainly the same issue, yes.

Comment 24

[Emanuel Hoogeveen [:ehoogeveen]]

Attachment: Testcase demonstrating the freeze for horizontal resizing.

Here is an extremely reduced testcase for the freeze that happens with horizontal resizing. It seems to be linked to the vertical length of the page.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Honestly, we don't need a reduced testcase.  We know exactly why the problem happens and how we need to fix it....

Comment 26

[Emanuel Hoogeveen [:ehoogeveen]]

Sorry, I didn't get that from the comments. I know there's a one-line fix, but I thought you were trying to get to the bottom of why that line is making it fail.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Ah, ok.  The getting to the bottom was done in comment 17.  ;)

Comment 28

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

Gavin, do you think you could try this out?

Comment 29

[Timothy Nikkel (:tnikkel)]

Comment on attachment 378959 [details] [diff] [review]
Proposed fix

This did not fix the problem for me (in a winxp vm).

Comment 30

[Boris Zbarsky [:bzbarsky]]

Does not checking for resize in widget fix the problem in a vm?  For me, in a Vista vm trying to resize a window just kills vmware until I do something to make it wake up; see comment 6.

If it does, does changing the attached patch to use 10 instead of 0 as the timer delay help?

Comment 31

[Timothy Nikkel (:tnikkel)]

I'm using VirtualBox, and the behaviour I see wrt resizing is the same (as far as I can tell) as I see natively on Windows.

(In reply to comment #30)
> Does not checking for resize in widget fix the problem in a vm?  For me, in a
> Vista vm trying to resize a window just kills vmware until I do something to
> make it wake up; see comment 6.

Making the change described in comment 6 fixes the problem.

> If it does, does changing the attached patch to use 10 instead of 0 as the
> timer delay help?

Changing the 0 to 10 does not fix the problem.

Comment 32

[Boris Zbarsky [:bzbarsky]]

What about changing it to 100?

Comment 33

[Timothy Nikkel (:tnikkel)]

No change.(In reply to comment #32)
> What about changing it to 100?

Doesn't have any noticeable effect.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Neil, any idea why?  That patch with a 100ms timer should resolve the issue you describe in comment 17, right?

Comment 35

[[e-mail]]

I just tried the patch as is with 0ms timer and it seems to work for me.

Comment 36

[:Gavin Sharp [email: [e-mail]]]

That patch doesn't fix this bug for me.

Comment 37

[Sylvain Pasche]

adjusting the summary as this is not specific to the Page Source window. I hit this issue on Vista when resizing a large Google Docs document.

Comment 39

[Timothy Nikkel (:tnikkel)]

Attachment: Proposed fix v2

So the reason that running the interrupted reflow off on a timeout didn't work is that another reflow is posted via PresShell::ProcessReflowCommands. This patch runs that off a timeout as well and it fixes the problem for me.

I noticed that there is another Windows only problem when resizing. Since HavePendingInputEvent will always return true during a resize, after sInterruptChecksToSkip calls to CheckForInterrupt we will always have an interrupt. This causes a noticeable problem when we have a block frame with more than ~200 lines -- the lines after ~200 will not get reflowed (or is that reflown? I'm no good at imaginary grammar) and so draw the same width as before the resize started. File a followup for this?

Comment 40

[Timothy Nikkel (:tnikkel)]

Attachment: Fix some comments

Comment 41

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 381474 [details] [diff] [review]
Fix some comments

Good catch on the bogosity, but instead of removing "until SetInterruptState is called" it should be "until ReflowStarted is called" and similar in the other comment.

Also s/returend/returned/ and s/where returns true/where this returns true/.

And you can just roll this into the other patch.

Comment 42

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 381473 [details] [diff] [review]
Proposed fix v2

Excellent catch!  You need to keep doing the non-timer thing, I think if !interrupted.  But other than that, this makes perfect sense.

Do you want me to just update the patch (it'll need a one-over from roc anyway), or do you want to do it?

Comment 43

[Timothy Nikkel (:tnikkel)]

Attachment: patch v3

Using superreview to get roc to look at it, use whatever flag is appropriate.

Comment 44

[Timothy Nikkel (:tnikkel)]

Followup for issue mentioned in comment 39 filed at bug 496500.

Comment 45

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 381706 [details] [diff] [review]
patch v3

Beautiful.  Thank you!

Comment 46

[Timothy Nikkel (:tnikkel)]

With the patch from bug 496500 I can get this hang again; although it is hard to come by, so I can't really place blame on that patch.

It is caused by the posted reflow in FrameNeedsReflow. After a reflow we call DidDoReflow which calls HandlePostedReflowCallbacks which updates the attributes for the scroll bars, and that calls FrameNeedsReflow on some scroll bar frames.

Relevant stack:

gklayout.dll!PresShell::FrameNeedsReflow(nsIFrame * aFrame=0x03b2d0e0, nsIPresShell::IntrinsicDirty aIntrinsicDirty=eStyleChange, unsigned int aBitToAdd=1024)  Line 3572	C++
gklayout.dll!nsSliderFrame::AttributeChanged(int aNameSpaceID=0, nsIAtom * aAttribute=0x024a6db8, int aModType=1)  Line 323	C++
gklayout.dll!nsCSSFrameConstructor::AttributeChanged(nsIContent * aContent=0x03b2d0e0, int aNameSpaceID=0, nsIAtom * aAttribute=0x024a6db8, int aModType=1, unsigned int aStateMask=0)  Line 7736 + 0x15 bytes	C++
gklayout.dll!PresShell::AttributeChanged(nsIDocument * aDocument=0x03861240, nsIContent * aContent=0x026c72b8, int aNameSpaceID=0, nsIAtom * aAttribute=0x024a6db8, int aModType=1, unsigned int aStateMask=0)  Line 5025	C++
gklayout.dll!nsNodeUtils::AttributeChanged(nsIContent * aContent=0x0390948c, int aNameSpaceID=0, nsIAtom * aAttribute=0x024a6db8, int aModType=1, unsigned int aStateMask=0)  Line 110 + 0xbb bytes	C++
gklayout.dll!nsGenericElement::SetAttrAndNotify(int aNamespaceID=0, nsIAtom * aName=0x024a6db8, nsIAtom * aPrefix=0x00000000, const nsAString_internal & aOldValue={...}, nsAttrValue & aParsedValue={...}, int aModification=1, int aFireMutation=0, int aNotify=1, const nsAString_internal * aValueForAfterSetAttr=0x0012ede4)  Line 4369 + 0x1d bytes	C++
gklayout.dll!nsGenericElement::SetAttr(int aNamespaceID=0, nsIAtom * aName=0x024a6db8, nsIAtom * aPrefix=0x00000000, const nsAString_internal & aValue={...}, int aNotify=1)  Line 4300 + 0x22 bytes	C++
gklayout.dll!nsXBLPrototypeBinding::AttributeChanged(nsIAtom * aAttribute=0x024a6db8, int aNameSpaceID=0, int aRemoveFlag=0, nsIContent * aChangedElement=0x03a9cf00, nsIContent * aAnonymousContent=0x04668808, int aNotify=1)  Line 604	C++
gklayout.dll!nsXBLBinding::AttributeChanged(nsIAtom * aAttribute=0x024a6db8, int aNameSpaceID=0, int aRemoveFlag=0, int aNotify=1)  Line 969	C++
gklayout.dll!nsGenericElement::SetAttrAndNotify(int aNamespaceID=0, nsIAtom * aName=0x024a6db8, nsIAtom * aPrefix=0x00000000, const nsAString_internal & aOldValue={...}, nsAttrValue & aParsedValue={...}, int aModification=1, int aFireMutation=0, int aNotify=1, const nsAString_internal * aValueForAfterSetAttr=0x0012f200)  Line 4359	C++
gklayout.dll!nsGenericElement::SetAttr(int aNamespaceID=0, nsIAtom * aName=0x024a6db8, nsIAtom * aPrefix=0x00000000, const nsAString_internal & aValue={...}, int aNotify=1)  Line 4300 + 0x22 bytes	C++
gklayout.dll!nsGfxScrollFrameInner::SetCoordAttribute(nsIContent * aContent=0x03a9cf00, nsIAtom * aAtom=0x024a6db8, int aSize=14917441)  Line 2626	C++
gklayout.dll!nsGfxScrollFrameInner::FinishReflowForScrollbar(nsIContent * aContent=0x03a9cf00, int aMinXY=0, int aMaxXY=14917441, int aCurPosXY=1632420, int aPageIncrement=22920, int aIncrement=1140)  Line 2364	C++
gklayout.dll!nsGfxScrollFrameInner::ReflowFinished()  Line 2433 + 0x1b bytes	C++
gklayout.dll!PresShell::HandlePostedReflowCallbacks(int aInterruptible=1)  Line 4808 + 0x6 bytes	C++
gklayout.dll!PresShell::DidDoReflow(int aInterruptible=1)  Line 7034	C++
gklayout.dll!PresShell::ProcessReflowCommands(int aInterruptible=1)  Line 7290	C++
gklayout.dll!PresShell::FlushPendingNotifications(mozFlushType aType=Flush_InterruptibleLayout)  Line 4917 + 0x11 bytes	C++
gklayout.dll!PresShell::ReflowEvent::Run()  Line 6983	C++

Posting the reflow off a timer if HasPendingInterrupt() is true seems to fix it.

Comment 47

[Boris Zbarsky [:bzbarsky]]

Hmm.  That might just be the right approach, yes.  If HasPendingInterrupt() is true, that means that the previous reflow we tried interrupted.  If we don't have a reflow event posted, that means that we're about to post one (it can't be that we posted one and then fired it already, since that would have reset what HasPendingInterrupt() returns.

I guess we break out of the ProcessReflowCommands loop if we interrupt on some root, so we can't clobber state that way either.  So yeah, that sounds pretty good in general.  If we do that check in PostReflowEvent() itself (and add a new function for the guts of it, that the timer could call directly), we can undo some of the other changes the earlier patches in this bug made, too.

Want to do that?

Comment 48

[Timothy Nikkel (:tnikkel)]

Attachment: patch v4

Comment 49

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 382447 [details] [diff] [review]
patch v4

Boris is the right person to sr this.

Comment 50

[Boris Zbarsky [:bzbarsky]]

Robert, I wrote half the patch... I'd really appreciate a sanity-check on the approach.  ;)

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

   void     PostReflowEvent();
+  void     DoPostReflowEvent();

It would be useful to have a comment explaining what the difference is.

You also need a comment explaining why we use a timer instead of a regular XPCOM event. It seems to be something to do with Windows event processing.

Comment 52

[Timothy Nikkel (:tnikkel)]

Attachment: patch v5

Robert's comments addressed.

Comment 53

[Stephen Walker]

Are there not any tinderbox tests being ran that should be hit by this? For instance, the opening of a file input upload window without having to resize at all.

Comment 54

[Bill Gianopoulos [:WG9s]]

(In reply to comment #53)
> Are there not any tinderbox tests being ran that should be hit by this? For
> instance, the opening of a file input upload window without having to resize at
> all.

I you encounter a hang not related to resizing it has nothing to do with this bug.  Your issue sounds more like bug 439687.

Comment 55

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 382927 [details] [diff] [review]
patch v5

>+PresShell::PostReflowEventOffTimer()
>+  if (!mReflowEvent.IsPending() && !mReflowContinueTimer) {

The only caller of this method is PostReflowEvent now, and so we'll never be called when mReflowEvent.IsPending().  I'll switch that to an assert, and with that looks good.

Comment 56

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/121b6b6d728b with that change.

Timothy, thanks for digging into this and fixing it!

Comment 57

[Stephen Walker]

(In reply to comment #54)
> (In reply to comment #53)
> > Are there not any tinderbox tests being ran that should be hit by this? For
> > instance, the opening of a file input upload window without having to resize at
> > all.
> 
> I you encounter a hang not related to resizing it has nothing to do with this
> bug.  Your issue sounds more like bug 439687.

I don't think that is correct since I haven't been able to reproduce the hang simply by trying to upload a file with today's build.

Comment 58

[Timothy Nikkel (:tnikkel)]

(In reply to comment #57)
> (In reply to comment #54)
> > (In reply to comment #53)
> > > Are there not any tinderbox tests being ran that should be hit by this? For
> > > instance, the opening of a file input upload window without having to resize at
> > > all.
> > 
> > I you encounter a hang not related to resizing it has nothing to do with this
> > bug.  Your issue sounds more like bug 439687.
> 
> I don't think that is correct since I haven't been able to reproduce the hang
> simply by trying to upload a file with today's build.

Windows does go into a modal loop when a dialog is open, so a similar hang could happen in such a case. However the resize modal loop is a special case because we are constantly reflowing the page. So the resize hang only ends when focus is changed. So with a dialog I would think the hang would end when reflow is finished.

Comment 59

[[e-mail]]

I don't think it could go even into a similar hang in that case, as the hang here is caused by the reflow interrupting itself because it detects the resize in progress but being unable to defer itself because the modal resize loop prefers to redispatch the reflow event rather than respond to the mouse.

Comment 60

[Emanuel Hoogeveen [:ehoogeveen]]

I'm still getting the hang on this page: http://iran.whyweprotest.net/news-current-events/8590-green-brief-20-july-06-a.html I can't resize it unless I turn off 'show window contents while dragging'.

Comment 61

[Timothy Nikkel (:tnikkel)]

(In reply to comment #60)
> I'm still getting the hang on this page:
> http://iran.whyweprotest.net/news-current-events/8590-green-brief-20-july-06-a.html
> I can't resize it unless I turn off 'show window contents while dragging'.

Hmm, I'm not able to reproduce this.

Comment 62

[Emanuel Hoogeveen [:ehoogeveen]]

That's odd - I tried it in Safe Mode and it still happens. Can anyone reproduce? I can -maybe- get it to change the size once (it'll respond very slowly and jump to the new size all at once), but after that it locks up. (taking up 100% of a core) It happens to this bug as well - vertical resizing works fine by horizontal resizing makes it lock up.

I'm on Vista x64 w/SP2.

Comment 63

[-fullmetaljacket-]

yeah confirm, resizing the window of page source of this bugzilla page is sluggish 

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090706 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090706042748

Comment 64

[Timothy Nikkel (:tnikkel)]

Sluggishness is totally different from a hang where no interaction is possible.

Comment 65

[-fullmetaljacket-]

so file new bug.?

Comment 66

[Timothy Nikkel (:tnikkel)]

There are reports of slowness when resizing at bug 499447, so if you have anything to add do it there unless you think what you are seeing is different (although that bug is kind of vague right now since it hasn't been pinned down yet). The patch in bug 496788 might fix the slowness issue. But hard hangs that never end, with no interaction possible, that are solved by alt-tabbing or hitting the windows key (or anything else that focuses something else) are this bug.

Comment 67

[Emanuel Hoogeveen [:ehoogeveen]]

To clarify, I'm getting a hard hang sometimes (i.e. if I try to resize the window slowly) preceded by a single visible resize. After I alt-tab out the window is reset to the size it had before I began resizing. (still happens on latest nightly)

Comment 68

[Timothy Nikkel (:tnikkel)]

That definitely sounds like the same hang this bug should have fixed. I still can't reproduce. Are there any other pages it happens on? I think the patch bug 496788 would fix this, but unfortunately its not going to be taken and the tryserver builds with it have expired.

Comment 69

[Emanuel Hoogeveen [:ehoogeveen]]

I still get the hang on the test case I attached - any long page seems to do. The moment the vertical scroll bar gets small enough (I couldn't really tell you how small, I'm not sure if it's always the same) the hang starts to happen. Even for say, any google search, if I make the window thin enough it starts to hang.

Comment 70

[Timothy Nikkel (:tnikkel)]

I do not want to sound condescending, but are you sure you are using the latest nightly? Check Help > About Mozilla Firefox, it will report a date like 20090715.

Comment 71

[Emanuel Hoogeveen [:ehoogeveen]]

Yep, 20090722 at time of writing. I usually update daily, and since I'd just come home from my holiday I made sure to update right away. And don't worry, I know how frustrating it is to get reports you can't reproduce.

Worse, now -I'm- having trouble reproducing the problem. :\ I wasn't doing anything particularly extraordinary before, and I was definitely getting hangs. If it happens again I'll record exactly what tabs I had open at the time.