Render bug, part of page blank at Homey Developer Documentation (developer.athom.com)
Categories
(Core :: Layout: Flexbox, defect, P3)
Tracking
()
People
(Reporter: eli5saado, Assigned: dholbert)
References
()
Details
(Keywords: regression, Whiteboard: [webcompat])
Attachments
(3 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36 Steps to reproduce: Steps: 1. Open Firefox 2. Navigate to `https://developer.athom.com/docs/apps` (be sure the zoom level is set to 100%) when you zoom to 200%, the page renders fully. Actual results: Part of the page is not rendered (see attachment) Expected results: The page should render like chromium renders it (see attachment)
Updated•2 years ago
|
![]() |
||
Comment 1•2 years ago
|
||
eli5saado, Could you please re-test with [1]Beta and [2]Nightly? It seems to be fixed on Beta aand Nightly. ATTENTION: Please backup your profile folder before start them. The profile will be incompatible. [1]https://www.mozilla.org/en-US/firefox/beta/all/ [2]https://www.mozilla.org/en-US/firefox/nightly/all/
![]() |
||
Comment 2•2 years ago
|
||
Fixed range: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ef8cd81d40542b7319127fdb8be840ab16c4cd4&tochange=7845d51b6f3cd691ec3ec97061021f18cda74c0c Fixed by: Bug 1490890
![]() |
||
Updated•2 years ago
|
Comment 3•2 years ago
|
||
I can still repro if I zoom in / out on Nightly. I need to head out now, but if somebody could find the regression range for that it'd be appreciated (doesn't need to be you if you can't Alice, you already do a lot!).
![]() |
||
Comment 4•2 years ago
|
||
so, Bug 1490890 only fix initial load. Layout is broken after zoom in/out. And re-loading page will fix.
Assignee | ||
Comment 5•2 years ago
|
||
I get this as the regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c0f88b376e33&tochange=c18776175a69 Given the flexbox association from the kinda-fixed-by attribution in comment 2 (bug 1490890): in that range, I'd guess that this was a regression from bug 1054010.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
Here's a reduced testcase that directly triggers the bad rendering. Basically, from the perspective of the outer (horizontal) flex container: this is a case where we're supposed to be considering its flex item to have a **definite size**, per Flexbox 9.8 category 3 (https://drafts.csswg.org/css-flexbox-1/#definite-sizes ). In this case, the flex item in question happens to be the (inner) vertical flex container. We're incorrectly behaving as if it has an indefinite size, which means we're not honoring "height:100%" on its own child.
Assignee | ||
Comment 7•2 years ago
|
||
As shown in the testcase, we actually get this correct if the item (the inner flex container) has "overflow:initial" (the default behavior). But we get it incorrect with "overflow: [hidden]" and probably any non-default value, presumably because it puts one more layer of separation between the percent-height thing and the container whose size we'd really like to resolve the percent against.
Comment 8•2 years ago
|
||
Anonymous boxes strike back? :-)
Assignee | ||
Comment 9•2 years ago
|
||
Indeed. Also, for extra confirmation: I tested the latest versions of Chrome, Safari, and Edge, and they all agree with each other on the attached testcase's rendering -- they make the lime boxes as tall as the container, covering up all the red that we show.
Assignee | ||
Updated•2 years ago
|
Reporter | ||
Comment 10•2 years ago
|
||
(In reply to Alice0775 White from comment #1) > eli5saado, > Could you please re-test with [1]Beta and [2]Nightly? It seems to be fixed > on Beta aand Nightly. > > ATTENTION: > Please backup your profile folder before start them. > The profile will be incompatible. > > [1]https://www.mozilla.org/en-US/firefox/beta/all/ > [2]https://www.mozilla.org/en-US/firefox/nightly/all/ Hi Alice, I could not test with nightly, as I did not have enough time to build it, for beta I found binaries in the AUR so I could test. When I initially load the page, it renders correctly, and everything works. However, when I zoom in and out part of the page disappears and turns gray/blank again. , Eli Saado
Too late for a fix in 63, but we could still take a patch for 65.
Comment 12•2 years ago
|
||
Sean, this bug is marked as a P2 ("Fix in the next release or iteration") but is unassigned and we have shipped multiple versions of Firefox with this bug, can we either get this assigned or move that to P3 ("backlog")? Thanks
Comment 13•2 years ago
|
||
Daniel: Have you looked at this at all recently and/or have any ideas on how to fix the regression? Otherwise I say we track this in our backlog and try to fix by 68 if possible.
Assignee | ||
Comment 14•2 years ago
|
||
I have not, but I can try to look soon. Anyway, agreed on that course of action.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
I've got a patch here - just gonna add some automated testcases & will post later today.
This is just an incremental tweak on top of bug 1128354 comment 10 -- just adding a further restriction on the adjustment that we made there.
When deciding whether a flex item needs a final reflow, we ask ourselves "Are there any descendants that have a relative-size dependency on this flex item?" And our current conditional way to check for this in fact checks NS_FRAME_CONTAINS_RELATIVE_BSIZE on the flex item, which actually gives us an answer to a different question -- it tells us whether there's anything with a relative height dependency on some ancestor of the flex item. And this isn't a useful answer, since the flex item is the thing that is becoming definitely-sized -- we want to probe for things that have a relative-BSize dependency on it, not on its ancestors.
To get the answer we really want, I think we have to query each of the flex item's children for NS_FRAME_CONTAINS_RELATIVE_BSIZE.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 16•2 years ago
•
|
||
For reference, here's the NS_FRAME_CONTAINS_RELATIVE_BSIZE documentation (emphasis added):
// If this bit is set, this frame or one of its descendants has a
// percentage block-size that depends on an ancestor of this frame.
Assignee | ||
Comment 17•2 years ago
|
||
Assignee | ||
Comment 18•2 years ago
|
||
Comment 19•2 years ago
|
||
Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/40890267a589 When deciding whether a flex item needs a final reflow, check RELATIVE_BSIZE state bit on its children. r=emilio
Comment 20•2 years ago
|
||
bugherder |
Comment 21•2 years ago
|
||
Updated•2 years ago
|
Description
•