94009 - [FIX]Fixed position elements of 100% width overlap vertical scrollbar

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P1)

Description

[Matt Sheffield]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.3) Gecko/20010801
BuildID:    200108110

When an element (a table in this example) is of 100% width and set to be in the
top left corner, it will occasionally overlap the scrollbar

Reproducible: Sometimes
Steps to Reproduce:
1. Visit page

Comment 1

[Trevor Andreas]

Verified using 0.9.3 Build ID 2001080110 on Windows 2000.

Comment 2

[Christopher Hoess (gone)]

WFM in the nightly build on Win NT, build ID 2001080603.

Comment 3

[Trevor Andreas]

WFM also on recent nightly.

Comment 4

[Olivier Cahagne]

wfm using build 2001090703 on Win2k.
Reporter, can you reopen if the problem persists ? Please attach a screenshot.

Comment 5

[Matt Sheffield]

Attachment: Screenshot demonstrating error

Comment 6

[Matt Sheffield]

I had removed HTML code which obviated the error. It is now back with a
screenshot per [e-mail]'s suggestion.

Comment 7

[Bernd]

Attachment: testcase

Comment 8

[Jeff Williams]

I'm also seeing this bug on ratherbiased.com; I'm using SuSE Linux and build
2001101808. However, I don't see this bug with the current testcase.

Could someone change the OS to All?

Comment 9

[Jeff Williams]

I'm also seeing this bug on ratherbiased.com; I'm using SuSE Linux and build
2001101808. However, I don't see this bug with the current testcase.

Could someone change the OS to All?

Comment 10

[Matt Sheffield]

The problem seems to have been fixed with 0.9.5. Anyone on other platforms
encountering bug with 0.9.5?

Comment 11

[Olivier Cahagne]

wfm using build 2001101909 on Win2k.

Comment 12

[Gary Coady]

Using build 2001102106 on Linux.

Reference URL works if the page is sized further than the image in the banner.
If page is sized smaller horizontally, image and div overlap with the scrollbar.

Using http://www.lyranthe.org/mozilla/testcase1.html and resizing the browser to
show scrollbars, the div does not visibly overlap with the scrollbar, but the
scrollbar is unresponsive for half of its width, to the right of the div. If I
recall correctly, it used to be unresponsive for the whole width, so this is a
slight improvement.

BTW, the testcase attachment 49376 [details] for this bug has always worked for me - the
testcase uses tables whereas the issue seems to be with divs.

Comment 13

[Johannes Erdfelt]

Attachment: Another testcase showing problem with borders as well

Comment 14

[anthonyd]

I dont see the problem of the divs overlapping the vert scrollbar.  What I DO 
see on the second testcase is some ugly residual lines left by the cell when 
scrolling, does anyone else see this?

Comment 15

[Gary Coady]

Attachment: 100% width <div> overlaps ~50% of scrollbar

Anthony - I see the exact same results as you for both testcases you tried.
Attached is the testcase I linked to in comment #12, which still happens for
me.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this a duplicate of bug 60499?

Comment 17

[karnaze (gone)]

Temporarily moving to future until a milestone can be assigned. 

Comment 18

[Gary Coady]

The testcase I attached in comment #15 now works for me, with build 2002030604.

Comment 19

[Bernd]

there is a difference between classic and modern theme for the URL (modern works
classic not).

Comment 20

[Matt Sheffield]

The problem has always been that the full vertical scrollbar will appear if the
window is resized. It also seems to sometimes display correctly when target URI
is typed in by user but will hide scrollbar if page is entered from a link.

The Modern/Classic skin distinction does not seem to apply for me on XP, Me, or
Linux. The scrollbar is covered with both skins.

Comment 21

[Trevor Andreas]

I don't know if this is related or should be a new bug but the page

http://www.people.fas.harvard.edu/~dbaron/css/test/sec1704b

has a fixed position element that overlaps the entire scrollbar on build
2002032103 on Windows XP Professional

Comment 22

[Boris Zbarsky [:bzbarsky]]

*** Bug 101762 has been marked as a duplicate of this bug. ***

Comment 23

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed patch

We need to set available width, not just computed width.  Otherwise the table
won't bother to recalculate its dimensions on a resize reflow....

Comment 24

[Boris Zbarsky [:bzbarsky]]

David, what do you think?  This fixes the testcase from bug 101762 and makes the
test at http://www.people.fas.harvard.edu/~dbaron/css/test/sec1704b not overlap
the scrollbar (though it still renders oddly, for reasons I have not yet figured
out).

Comment 25

[Boris Zbarsky [:bzbarsky]]

Attachment: Refactor the code slightly

Comment 26

[Boris Zbarsky [:bzbarsky]]

Attachment: Forgot |const| in a few places...

Comment 27

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 79707 [details] [diff] [review]
Forgot |const| in a few places...

reflow branch has bitrotted this.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Attachment: updated patch

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83165 [details] [diff] [review]
updated patch

Other than this change:

>-  reflowState.reason = eReflowReason_Dirty;

it seems fine.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Attachment: Don't remove needed code.

That change should not be there....

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 83175 [details] [diff] [review]
Don't remove needed code.

r=dbaron

bz should probably assign this bug to himself too :-)

Comment 32

[Bernd]

Boris the remaining issues are covered in bug 84715. From my first investigation
we create a very large outertable table frame and position inside this frame the
inner table frame. Some people may call this a hack. The caption then assumes
margin-left:0 and goes to the left edge of the outer table frame.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Oh, yeah.  To me.  :)

Comment 34

[Marc Attinasi]

Comment on attachment 83175 [details] [diff] [review]
Don't remove needed code.

sr=attinasi

Comment 35

[Boris Zbarsky [:bzbarsky]]

Fixed on trunk.  I don't think trying to land this on branch is worth it, so
marking fixed.

Comment 36

[Jacob Kjome]

The first testcase still fails for me with build 2002051408 on Win2k (sp2sr1).

http://bugzilla.mozilla.org/attachment.cgi?id=49376&action=view

The red still overlaps the scrollbar.

Jake

Comment 37

[Boris Zbarsky [:bzbarsky]]

So it is...  The testcase from comment 13 (which worked in yesterday's build) is
also broken.

Investigating.

Comment 38

[Boris Zbarsky [:bzbarsky]]

Well... my patch fixed this.  Then the patch for bug 143706 immediately
regressed it, for tables and blocks both (hence the problem with attachment
55815 [details]).

Comment 39

[Boris Zbarsky [:bzbarsky]]

Attachment: This would fix it

This is a hacky patch to get around the problem.  See bug 143706, comment 9 for
why it is needed.  See also bug 143706, comment 10 for an alternate solution to
the problem.

Comment 40

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Let's fix it the right way.

Comment 41

[Jeff Williams]

If you wind up changing nsViewportFrame.cpp again, could you change "prinicpal"
to "principal" in the comment on line 319? (The comment I'm referring to appears
in attachment 83586 [details] [diff] [review].)

Comment 42

[Boris Zbarsky [:bzbarsky]]

sure thing.  :)

Comment 43

[Boris Zbarsky [:bzbarsky]]

OK, the regression fix has landed and this is now all good with build
2002-05-15-21 on Linux.

Jake, thanks for catching that!