Open Bug 1475491 Opened 6 years ago Updated 2 years ago

right-to-left (vertical-rl or direction:rtl) writing-mode <html> with "width: 100vw; height: 100vh; margin: 0; padding: 0;" causes overflow(scroll bars appear)

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

Tracking Status
firefox63 --- affected

People

(Reporter: zjz, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 1 obsolete file)

Severity: major → normal
Component: CSS Parsing and Computation → Layout
The following html shouldn't overflow, but it overflows in both the two directions: <!DOCTYPE html> <title>Test vertical writing page with exactly full viewport size</title> <style> html { writing-mode: vertical-rl; margin: 0; padding: 0; height: 100vh; width: 100vw; } </style>
Attached file test.html (obsolete) (deleted) —
Attachment #8991813 - Attachment is obsolete: true
I only see this with "vertical-rl", not "vertical-lr". Moreover, I see this with simple "direction: rtl". So I think this is a problem whenever the toplevel flow is right-to-left, and isn't so much about vertical-ness.
Summary: Vertical writing-mode <html> with "width: 100vw; height: 100vh; margin: 0; padding: 0;" causes overflow(scroll bars appear) → right-to-left (vertical-rl or direction:rtl) writing-mode <html> with "width: 100vw; height: 100vh; margin: 0; padding: 0;" causes overflow(scroll bars appear)
Attachment #8991814 - Attachment description: test.html → testcase 1: using writing-mode: vertical-rl
Here's a testcase that briefly tweaks the height after loading (and then reverts that tweak). This is sufficient to fix the problem, on my machine. So, it seems that we can eventually figure out that scrollbars are unnecessary, if stuff goes from easily-fitting to exactly-fitting.
(In reply to Daniel Holbert [:dholbert] from comment #6) > Here's a testcase that briefly tweaks the height after loading (and then > reverts that tweak). This is sufficient to fix the problem, on my machine. > > So, it seems that we can eventually figure out that scrollbars are > unnecessary, if stuff goes from easily-fitting to exactly-fitting. This sounds related to the fact that scrollbar reflow depends on state (do we have scrollbars) that persists between reflows. I think we also generally try to start from the assumption that we will have a scrollbar, since resizing huge things can be expensive, and huge things probably have a scrollbar.
My guess is that this code: https://searchfox.org/mozilla-central/rev/46292b1212d2d61d7b5a7df184406774727085b8/layout/generic/nsGfxScrollFrame.cpp#706-739 doesn't work when overflow goes to the left rather than the right.
Interestingly, I can't seem to get the issue to reproduce in an "overflow:auto" <div>, as shown by this testcase where I don't get any visible scrollbars (yay). I've only been able to get it to happen on the outermost scrollport.
(In reply to Daniel Holbert [:dholbert] from comment #9) > Interestingly, I can't seem to get the issue to reproduce in an > "overflow:auto" <div>, as shown by this testcase where I don't get any > visible scrollbars (yay). > > I've only been able to get it to happen on the outermost scrollport. That's probably because the document's scrollbar side matches the UI direction, but the scrollbar side of the overflow:auto div matches the document direction.
Hmm, OK. It sounds like you're saying that maybe things would break if I made the div disagree with the document on the scrollbar direction? But that doesn't seem to be what happens -- things are still fine (no scrollbars show up) even if I edit testcase 4's source to move the "direction:rtl" declaration to be on the .scrollable {...} rule. (Probably doesn't matter too much; just mentioning in case it's interesting/useful when we're fixing this & reasoning about levels of scrolling granularity.)
Priority: -- → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: