This came out of bug 2254. When you re-size a page (or just load it initially), you can not do anything else until the re-size has finished. On a large page like this one, that takes quite awhile. This does not happen on Nav4.x. Using Jan. 14 build on win95.

P1 bugs are reserved for crashers.

since when?

Setting all current Open Critical and Major to M3

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Cannot reproduce a test case, so here it's goes: 1)Go to URL of a big page 2)Resize it's window What's should happen: the windows should change is size normaly What's happen: The layout wait until the page is complete loading and the resize him self * The bug don't occur with Windows 98 in M8 it's seems that the problem is in the refresh rate or something like that.

Can´t believe you allow me - nobody - to change theses important fields. I expect to get an error-message if I submit this.

some weenie marked this resolved

Resetting the other fields that the little joker modified (P5/enhancement/ assigned).

There was an interesting thread on mozilla.xpcom about this problem. The URL to the first message is news://news.mozilla.org/379FBA71.C764654E%40netscape.com CCing hyatt and troy

Marking #12672 as dependent.

Since you are sweating the issue, you can hold onto the bug...

That's because the Nav4.x browser doesn't do _anthing_ while the page is being resized. Then when you finish resizing it completely reloads the page from the cache which takes forever. The old browser didn't do anything incremental...

This bug is not invalid: try our browser on a big page and you will see how annoying that is. I suggest QA to reopen it, change the name to "We need incremental reflow" and reassign to rickg.

done

I marked the bug INVALID because it was claiming that Nav4.x doesn't have that problem when re-sizing a large page. That's not a valid comparison, because Nav4.x doesn't incrementally reflow the page while it's being resized...

Look, we have incremental reflow. Maybe you think it should be faster, and that's fine, but general bugs that encompass large and vague areas of the product are not acceptable I do not want a bug that has no clear resolution for resolving and is very subjective. I can always find a page that's large enough or a machine that's slow enough for any browser to be sluggish...

reopening and marking invalid, no detail here and not much of a bug {clearing old cc's as a courtesy to reduce spam}

I mark this invalid. See Blakes last comment.

Moving all threading bugs to XPCOM. See bug 160356.