Closed Bug 94009 Opened 20 years ago Closed 20 years ago

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

Categories

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

defect

Tracking

()

RESOLVED FIXED
mozilla1.1alpha

People

(Reporter: mattsheffield, Assigned: bzbarsky)

References

()

Details

(Keywords: testcase, Whiteboard: [awd:tbl])

Attachments

(5 files, 5 obsolete files)

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
Verified using 0.9.3 Build ID 2001080110 on Windows 2000.
WFM in the nightly build on Win NT, build ID 2001080603.
WFM also on recent nightly.
wfm using build 2001090703 on Win2k.
Reporter, can you reopen if the problem persists ? Please attach a screenshot.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
I had removed HTML code which obviated the error. It is now back with a
screenshot per cahagn_o@epita.fr's suggestion.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Attached file testcase
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
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?
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?
The problem seems to have been fixed with 0.9.5. Anyone on other platforms
encountering bug with 0.9.5?
wfm using build 2001101909 on Win2k.
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.
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?
Whiteboard: [awd:tbl]
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.
Is this a duplicate of bug 60499?
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future
The testcase I attached in comment #15 now works for me, with build 2002030604.
there is a difference between classic and modern theme for the URL (modern works
classic not).
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.
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
*** Bug 101762 has been marked as a duplicate of this bug. ***
OS: Windows ME → All
Hardware: PC → All
Attached patch Proposed patch (obsolete) — Splinter Review
We need to set available width, not just computed width.  Otherwise the table
won't bother to recalculate its dimensions on a resize reflow....
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).
Attached patch Refactor the code slightly (obsolete) — Splinter Review
Attachment #79597 - Attachment is obsolete: true
Attachment #79705 - Attachment is obsolete: true
Comment on attachment 79707 [details] [diff] [review]
Forgot |const| in a few places...

reflow branch has bitrotted this.
Attachment #79707 - Attachment is obsolete: true
Attached patch updated patch (obsolete) — Splinter Review
Comment on attachment 83165 [details] [diff] [review]
updated patch

Other than this change:

>-  reflowState.reason = eReflowReason_Dirty;

it seems fine.
Attached patch Don't remove needed code. (obsolete) — Splinter Review
That change should not be there....
Attachment #83165 - Attachment is obsolete: true
Comment on attachment 83175 [details] [diff] [review]
Don't remove needed code.

r=dbaron

bz should probably assign this bug to himself too :-)
Attachment #83175 - Flags: review+
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.
Oh, yeah.  To me.  :)
Assignee: karnaze → bzbarsky
Status: ASSIGNED → NEW
Priority: -- → P1
Summary: Fixed position elements of 100% width overlap vertical scrollbar → [FIX]Fixed position elements of 100% width overlap vertical scrollbar
Target Milestone: Future → mozilla1.1alpha
Comment on attachment 83175 [details] [diff] [review]
Don't remove needed code.

sr=attinasi
Attachment #83175 - Flags: superreview+
Fixed on trunk.  I don't think trying to land this on branch is worth it, so
marking fixed.
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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
So it is...  The testcase from comment 13 (which worked in yesterday's build) is
also broken.

Investigating.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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]).
Depends on: 143706
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.
Attachment #83175 - Attachment is obsolete: true
Let's fix it the right way.
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].)
sure thing.  :)
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!
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.