1503173 - Render bug, part of page blank at Homey Developer Documentation (developer.athom.com)

Status: RESOLVED FIXED

(Core :: Layout: Flexbox, defect, P3)

Description

[eli5saado]

Attachment: bug.png

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)

Comment 1

[Alice0775 White]

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

[Alice0775 White]

Fixed range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6ef8cd81d40542b7319127fdb8be840ab16c4cd4&tochange=7845d51b6f3cd691ec3ec97061021f18cda74c0c

Fixed by: Bug 1490890

Comment 3

[Emilio Cobos Álvarez (:emilio)]

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

[Alice0775 White]

so, Bug 1490890 only fix initial load. 
Layout is broken after zoom in/out. And re-loading page will fix.

Comment 5

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

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.

Comment 6

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

Attachment: testcase 1

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.

Comment 7

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

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

[Emilio Cobos Álvarez (:emilio)]

Anonymous boxes strike back? :-)

Comment 9

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

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.

Comment 10

[eli5saado]

(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

Comment 11

[Liz Henry (:lizzard)]

Too late for a fix in 63, but we could still take a patch for 65.

Comment 12

[Pascal Chevrel:pascalc]

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

[Sean Voisen (:svoisen)]

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.

Comment 14

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

I have not, but I can try to look soon. Anyway, agreed on that course of action.

Comment 15

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

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.

Comment 16

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

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.

https://searchfox.org/mozilla-central/rev/532e4b94b9e807d157ba8e55034aef05c1196dc9/layout/generic/nsFrameStateBits.h#89-93

Comment 17

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

Attachment: Bug 1503173: When deciding whether a flex item needs a final reflow, check RELATIVE_BSIZE state bit on its children. r?emilio

Comment 18

[Daniel Holbert [:dholbert] (AFK from Oct 16-23)]

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=11952bfc939ff2b079d72929062bad16f7035883

Comment 19

[Pulsebot]

Pushed by [e-mail]:
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

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/40890267a589

Comment 21

[David Baron :dbaron: (away October 5-21)]

WPT PR at https://github.com/web-platform-tests/wpt/pull/16166