Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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.

Updated

13 years ago
Keywords: qawanted
Created attachment 154123 [details]
Testcase #1
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

Comment 3

13 years ago
In that range, the most likely culprit is bug 235778...
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)
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.