Closed Bug 2498 Opened 21 years ago Closed 19 years ago

Re-sizing is blocking on Windows

Categories

(Core :: XPCOM, enhancement, P5)

x86
Windows 95
enhancement

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: paulmac, Assigned: troy)

References

()

Details

(Whiteboard: [TESTCASE] klein_sh@inter.net.il)

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.
Status: NEW → ASSIGNED
Priority: P1 → P3
P1 bugs are reserved for crashers.
since when?
Setting all current Open Critical and Major to M3
QA Contact: 3832
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Severity: major → normal
Status: ASSIGNED → NEW
Target Milestone: M3 → M5
Severity: normal → enhancement
Priority: P3 → P5
Whiteboard: [TESTCASE] klein_sh@inter.net.il
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.
Severity: enhancement → minor
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Priority: P5 → P4
Resolution: --- → FIXED
Can´t believe you allow me - nobody - to change theses important fields.
I expect to get an error-message if I submit this.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
some weenie marked this resolved
Severity: minor → enhancement
Status: REOPENED → ASSIGNED
Priority: P4 → P5
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
Blocks: 12672
No longer blocks: 12672
Marking #12672 as dependent.
Blocks: 12672
Assignee: kipp → troy
Status: ASSIGNED → NEW
Since you are sweating the issue, you can hold onto the bug...
Status: NEW → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Summary: Re-sizing is blocking on Windows → We need incremental reflow
Summary: We need incremental reflow → Re-sizing is blocking on Windows
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...
Resolution: INVALID → ---
Summary: Re-sizing is blocking on Windows → We need incremental reflow
Summary: We need incremental reflow → Re-sizing is blocking on Windows
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...
Status: REOPENED → RESOLVED
Closed: 21 years ago21 years ago
Resolution: --- → LATER
reopening and marking invalid, no detail here and not much of a bug {clearing 
old cc's as a courtesy to reduce spam}
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: M15 → Future
I mark this invalid.
See Blakes last comment.
Status: REOPENED → RESOLVED
Closed: 21 years ago19 years ago
Resolution: --- → INVALID
Moving all threading bugs to XPCOM. See bug 160356.
Component: Threading → XPCOM
You need to log in before you can comment on or make changes to this bug.