{inc} 'height' on table-row-group isn't honored consistently
Categories
(Core :: Layout: Tables, defect)
Tracking
()
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
[Note, this bug report is derived from a fuzzer testcase from the "Layout QuickCheck" researchers; see https://pavpanchekha.com/blog/lqc.html for more]
STR:
- Load attached testcase.
- Click the "Click to make style changes" link.
- Click the "Click to relayout" link. (The second link just forces a more thorough relayout; it doesn't make any persistent changes to the page.)
ACTUAL RESULTS:
- The black-bordered area is initially zero-height.
- The rendering changes after step 3. (Specifically, the black-bordered element has no height at all up until step 3; and then step 3 makes it super-tall.)
EXPECTED RESULTS:
- Probably the black-bordered element should have started out being 50px tall, honoring the initial "trg" height value.
- We should grow it to be much taller in step 2 to honor its new taller 'height' value.
- There should be no change in step 3.
|
Reporter | |
Comment 1•3 years ago
|
||
Here's the original fuzzer testcase, for reference. To trigger the bug here, run "recreateTheProblem()" in your web console, and look at the output. For me, that yields:
Conflicting dimensions for element UnknownID<html>
Dimensions after reload: bottom: 20991.31640625, height: 20991.31640625
Dimensions after modify: bottom: 35, height: 35
Conflicting dimensions for element UnknownID<body>
Dimensions after reload: bottom: 20983.31640625, height: 20975.31640625
Dimensions after modify: bottom: 27, height: 19
...which is showing that "after reload" and "after modify" have different height values for the html and body elements.
(Note, some of the dynamic changes in this version don't actually have to be dynamic, which is why my version is a bit simpler.)
|
|
Reporter | |
Updated•3 years ago
|
|
||
Comment 2•1 year ago
|
||
I've just tested this in a recent Firefox (112.0.2, build 20230424110519) and the expected behavior is now showing up. I think we can mark this fixed!
|
|
Reporter | |
Comment 3•1 year ago
|
||
(Sorry, didn't notice comment 2 until just now)
Nope, this is still broken in 119.0a1 (2023-09-19) (64-bit) and a handful of older builds that I tested.
Testcase 1(interactive) still behaves as-described in comment 0.- The
original fuzzer testcasedoesn't report any issues now if you have overlay scrollbars turned on. But it does report a layout change if you activate traditional scrollbars (i.e. check the box for "Always Show Scrollbars" in Firefox preferences on linux, or toggle the equivalent setting in system preferences on Windows/Mac)
There was a behavior-change since this was filed, which is that we turned on overlay scrollbars by default in linux (unchecking the "always show scrollbars" box by default, essentially). The fuzzer testcase is focusing on the size of the html and body elements, and that changes (as detected by the fuzzer testcase) when a scrollbar shows up, under a traditional-scrollbars configuration. But it doesn't change under an overlay-scrollbars configuration.
Description
•