Unnecessary horizontal scrollbar displayed

RESOLVED FIXED

Status

()

Core
Layout
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: omg itsh, Assigned: roc)

Tracking

({regression, testcase})

Trunk
x86
All
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (compatible;MSIE 5.5; GNU/Linux)
Build Identifier: Mozilla/5.0 (compatible;MSIE 5.5; GNU/Linux) (from FreeBSD ports)

mozilla used to display http://www.belgeo.be (best mapper for belgium, used by
thousands of people)'s input fields correctly, but now it displays a useless
horizontal scrollbar in the way of the lower input fields.

Reproducible: Always
Steps to Reproduce:
1. connect to http://www.belgeo.be
2. look for an address
Actual Results:  
you have to crawl thru the useless horizontal scroll bar that came up after 1.7.

Expected Results:  
don't display the horizontal bar

belgeo.be is #1 online mapper for belgium.
Keywords: qawanted

Comment 1

13 years ago
Created attachment 154123 [details]
Testcase #1

Comment 2

13 years ago
Confirming bug, 2004-07-22-05 trunk Linux.

Regression occurred between 2004-02-27-07 -- 2004-02-28-08
Assignee: general → nobody
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
Keywords: qawanted → regression, testcase
OS: other → All
QA Contact: general → core.layout
Summary: mozilla no longer displays belgeo.be (mapper) input fields correctly → Unnecessary horizontal scrollbar displayed
In that range, the most likely culprit is bug 235778...

Comment 4

13 years ago
Yes, using nsLineLayout::RelativePositionFrames() from rev. 3.182 works for me.
The problem is this chunk of code in nsLineLayout::TrimTrailingWhitespaceIn:

    if (childSpan) {
      // Maybe the child span has the trailing white-space in it?
      if (TrimTrailingWhiteSpaceIn(childSpan, aDeltaWidth)) {
        nscoord deltaWidth = *aDeltaWidth;
        if (deltaWidth) {
          // Adjust the child spans frame size
          pfd->mBounds.width -= deltaWidth;

Now, just trimming the span frame's bounds does not reduce its overflow area,
because the space remains in its pfd->mCombinedArea. But just trimming
pfd->mCombinedArea is incorrect if the span is relatively positioned with
overflowing absolute children.

To fix this mess, we should just always recompute the overflow area for spans
*from scratch* in RelativePositionFrames, don't bother maintaining it during
frame alignment and so on. I suggest that inline frames should *not* include
their frame bounds or the bounds of their inline children in the mOverflowArea
they return; only inlines with absolute children should accumulate the bounds of
the absolute children in there. So pfd->mCombinedArea will normally be empty
until RelativePositionFrames, which adds in the bounds of the inline frame and
its inline descendants. We will not try to maintain pfd->mCombinedArea during
frame alignment, since that's impossible to do accurately.
Created attachment 154169 [details] [diff] [review]
fix

This does just what I said.

The comments here are a little misleading, because nsTextFrames still report
their overflow area to be exactly their bounds. That doesn't affect the code
but I will tweak the comments to make it clear that can happen.

This patch is a bit aggressive and changes fragile code (but makes the code a
lot less fragile IMHO because we no longer try to maintain mCombinedArea during
alignment). I tested it with many testcases from the relative-positioning bug
tree and also with the IE-compat inline-image-in-table bugs. It seems to work
fine. Probably not 1.7 branch material though.

At some point in the future we want to change things so that the absolute
children of a relatively positioned inline are reflowed *during*
RelativePositionFrames. This will probably completely remove the need to store
mCombinedArea in the pfds, and will also clean up the anomalous treatment of
metrics->mOverflowArea that I'm doing here; inline frames will simply never
return an mOverflowArea from reflow, it will always be ignored.
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #154169 - Flags: superreview?(dbaron)
Attachment #154169 - Flags: review?(dbaron)

Updated

13 years ago
Blocks: 247938
(In reply to comment #6)
> At some point in the future we want to change things so that the absolute
> children of a relatively positioned inline are reflowed *during*
> RelativePositionFrames. This will probably completely remove the need to store
> mCombinedArea in the pfds, and will also clean up the anomalous treatment of
> metrics->mOverflowArea that I'm doing here; inline frames will simply never
> return an mOverflowArea from reflow, it will always be ignored.

Could you file a bug on this?

(In reply to comment #5)
> Now, just trimming the span frame's bounds does not reduce its overflow area,
> because the space remains in its pfd->mCombinedArea. But just trimming
> pfd->mCombinedArea is incorrect if the span is relatively positioned with
> overflowing absolute children.

I remember marking somebody else's patch review- for something like this.  I'm
wondering if that bug is fixed now.  I suspect not, since I think that bug was
about something else, but I'm not sure.
(In reply to comment #7)
> Could you file a bug on this?

Filed as bug 255139.

> I remember marking somebody else's patch review- for something like this.  I'm
> wondering if that bug is fixed now.  I suspect not, since I think that bug was
> about something else, but I'm not sure.

Neither am I :-)
Attachment #154169 - Flags: superreview?(dbaron)
Attachment #154169 - Flags: superreview+
Attachment #154169 - Flags: review?(dbaron)
Attachment #154169 - Flags: review+
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
*** Bug 257327 has been marked as a duplicate of this bug. ***
*** Bug 254690 has been marked as a duplicate of this bug. ***

Comment 12

13 years ago
*** Bug 272960 has been marked as a duplicate of this bug. ***

Comment 13

12 years ago
*** Bug 319944 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.