Closed Bug 1503173 Opened Last year Closed 7 months ago

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

Categories

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

63 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- fixed

People

(Reporter: eli5saado, Assigned: dholbert)

References

()

Details

(Keywords: regression, Whiteboard: [webcompat])

Attachments

(3 files)

Attached image 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)
Component: Graphics → Untriaged
Product: Core → Firefox
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/
Flags: needinfo?(eli5saado)
Component: Untriaged → Layout: Flexbox
Product: Firefox → Core
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!).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(emilio)
Flags: needinfo?(dholbert)
so, Bug 1490890 only fix initial load. 
Layout is broken after zoom in/out. And re-loading page will fix.
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.
Blocks: 1054010
Flags: needinfo?(dholbert)
Summary: Render bug, part of page blank → Render bug, part of page blank at Homey Developer Documentation (developer.athom.com)
Attached file 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.
Flags: needinfo?(emilio)
Flags: needinfo?(eli5saado)
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.
Anonymous boxes strike back? :-)
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.
Priority: -- → P2
Whiteboard: [webcompat]
(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.

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

Flags: needinfo?(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.

Flags: needinfo?(dholbert)

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

Flags: needinfo?(dholbert)
Priority: P2 → P3
Flags: needinfo?(svoisen) → needinfo?(dholbert)

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.

Depends on: 1128354
Flags: needinfo?(dholbert)
Assignee: nobody → dholbert
Status: NEW → ASSIGNED

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

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
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.