Closed Bug 14782 Opened 20 years ago Closed 20 years ago

[dogfood] mousing over links causes massive reflows when status button crops

Categories

(Core :: XUL, defect, P1, critical)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: eric)

References

Details

(Whiteboard: [PDT-][HELP WANTED!])

as we discussed in my cube. turn on paint flashing

go to the bonsai link and mouse over the links in the bullet lists. these links
are long enough to make the titled button for the status bar crop. this causes
the window to repaint.

i think this is also the cause of why mousing over links at my.netscape is really
really slow.

this happens on all platforms.
cc'ing shaver, as he and i were talking about this earlier.
cc'ing shaver, as he and i were talking about this earlier.
*** Bug 13984 has been marked as a duplicate of this bug. ***
Assignee: evaughan → pinkerton
taking this back. fix in hand.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
fixed.
QA Contact: beppe → claudius
Claudius -- since this has to do with the the function of the window -- you get
it.
Status: RESOLVED → REOPENED
reopening bug, per discussions with pinkerton. It seems we're still
repainting much more than we have to
Resolution: FIXED → ---
clearing fixed resolution
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
fixed again, this time it was a problem in the view manager.
Whiteboard: 19991013: holding verification oending some discussion
I don't really think this is fixed - otherwise there is some other problem. pink and I will discuss.
Status: RESOLVED → REOPENED
yeah, we've regressed alright. this f*ing sucks.
Resolution: FIXED → ---
Summary: [PERF] mousing over links causes massive reflows when status button crops → [dogfood] mousing over links causes massive reflows when status button crops
Whiteboard: 19991013: holding verification oending some discussion → [HELP WANTED!]
Status: REOPENED → ASSIGNED
Priority: P3 → P1
Target Milestone: M11
you can easily see this when mousing over the "Module Owners" link in
mozilla.org. Mousing out of that link causes the content area and sidebar to
reflow, though I can't tell why. From that point on, it seems to want to continue
to reflow when mousing over links until you mouse over the "Milestone 10" link
(for example) at which point all is ok again.

It seems like we get into a state where everything causes a full reflow and then
mousing over other links (that don't appear to do any different) gets us back to
the happy place we started in.
p1, m11, accepting, cc'ing evaughan.
Whiteboard: [HELP WANTED!] → [PDT-][HELP WANTED!]
Putting on [PDT-] radar.
What does ``PDT-'' mean here?  What made people decide that this wasn't dogfood?
cc'ing pav
if i pull the status area out of the status bar this goes away, smells like
titledbutton/box bugs.
reassigning to brendan since i'm going on vacation.
More of pink's bugs he dumped on me, I'm dumping on you!

/be
Target Milestone: M11 → M12
Moving to M12
Assignee: kmcclusk → evaughan
The problem seems to be in FlowChildAt in nsBoxFrame.cpp.

nsresult
nsBoxFrame::FlowChildAt(nsIFrame* childFrame,
                     nsIPresContext* aPresContext,
                     nsHTMLReflowMetrics&     desiredSize,
                     const nsHTMLReflowState& aReflowState,
                     nsReflowStatus&          aStatus,
                     nsCalculatedBoxInfo&     aInfo,
                     PRBool& aRedraw,
                     nsString& aReason)

...

if (currentRect.width == calcWidth && currentRect.height == calcHeight) {
  shouldReflow = PR_FALSE;
}

The calcWidth varies (+ or -) 1 twip for the content area each time this method
is called. This forces the content are to be reflowed.

If the following HACK is used the reflows can be suppressed.

       if (currentRect.width == calcWidth && currentRect.height == calcHeight) {
         shouldReflow = PR_FALSE;
       }
       else {
         if ((currentRect.width - calcWidth == 1) ||
             (currentRect.width - calcWidth == -1) ||
             (currentRect.width - calcWidth == 2) ||
             (currentRect.width - calcWidth == -2)) {
               shouldReflow = PR_FALSE;
                printf("Reflow avoided\n");
             }
        }

I think the real problem is in nsBoxFrame::LayoutChildrenInRect(nsRect& size).
It uses a floating point value to apply a percentage to the boxes it is laying
out. I suspect the use the floating point is causing a round off error which
results in the +=1 twip variation in the calculated width.

Eric will be changing it so percentage values are expressed as integers instead
of floats. This may solve this bug.

Re-assigning to Eric.
This is a general bug which is exhibited whenever the status bar text is
changed. Changing the status bar text causes an incremental reflow which box
layout converts to a resize reflow for the content area if the calculated width
is not = to the current width of the content area.
*** Bug 16364 has been marked as a duplicate of this bug. ***
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
This is now fixed. It happened because the box layout was using floating point
arithmetic and because of roundoff things were sometimes off by 1 twip causing
weirdness. Now all calculations are done in integers.
Status: RESOLVED → VERIFIED
verified
You need to log in before you can comment on or make changes to this bug.