Closed Bug 1677568 Opened 4 years ago Closed 1 year ago

Element disappears when mouse hovers over it in Firefox, but not in Chrome

Categories

(Core :: Web Painting, defect, P2)

defect

Tracking

()

VERIFIED FIXED
114 Branch
Webcompat Priority P3
Tracking Status
firefox114 --- verified
firefox115 --- verified

People

(Reporter: twisniewski, Assigned: tnikkel)

References

Details

Attachments

(3 files)

Attached file testcase.html

In the attached test-case, when one hovers over the second link its text will vanish in Firefox, but not in Chrome. The text reappears when alt-tabbing away from the window.

This is a reduced test-case for https://webcompat.com/issues/61736. Note that the styles are a mix of the site's CSS and those generated by Bootstrap's dropdown component.

Yeah, the bug goes away with layout.display-list.retain=false, so it smells like RDL is at fault somehow.

Component: Layout → Web Painting

Bisects back to the initial landing of retained display lists with the pref forced on, so this might not be an instance of bug 1534549 (the only major regression from retained display lists that I am aware still exists).

Flags: needinfo?(tnikkel)
Severity: -- → S2
Priority: -- → P2
Webcompat Priority: ? → P3
Assignee: nobody → tnikkel

This testcase hits a rare condition where the abs pos frame is under the first continuation of the containing block frame, but the placeholder frame is under the next continuation of th containing block frame. This means that the walk in FindContainingBlocks which adds the ForceDescendIntoIfVisible bit to all ancestors of modified frames (walking through placeholders) never marks the first continuation of the containing block frame, which is the actual frame that contains the modified frame. That means that we don't walk into the containing block for the modified abs pos frame, and so we don't call MarkAbsoluteFramesForDisplayList, which computes the dirty rect for the abs pos frame, and if it is non-empty it would walk it's ancestor chain through placeholders and add the NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO bit. But we don't do that, so when we come to build the display list for the placeholder frame, the placeholder frame has size 0x0 of course, so we determine it is not visible, and even though the ForceDescendIntoIfVisible bit is set on it, since it's not visible we don't descend into it. We need the NS_FRAME_FORCE_DISPLAY_LIST_DESCEND_INTO bit which would have been set.

So for this to work we need to make sure in addition to the ancestor chain walking through placeholders has the ForceDescendIntoIfVisible bit set, we also need to make sure the normal GetParent ancestor chain has that bit set. So anywhere that we use GetDisplayListParent where this kind of fix seems like it is needed we need to modify. We try to be a bit clever to try to avoid any extra work for this rare case. We do this by checking if we are going to be jumping to the placeholder, and if so we make sure to mark the parent of the current frame, before continuing up the GetDisplayListParent walk. This doesn't visit anymore frames as in the common case we stop the walk when we get to the parent frame because the ForceDescendIntoIfVisible bit is set on it. This does add a function call overhead though.

When we hit this condition we do have to walk more frames. To make sure this condition isn't too common, and thus aren't making ourselves walk a lot more frames, I did a full try run on linux to see how often it was hit. We hit it 3 times. layout/base/crashtests/1464641.html which is a reduced testcase of another retained display list bug. testing/web-platform/tests/svg/layout/svg-with-precent-dimensions-relayout.html. And layout/reftests/display-list/1709452-1.html which is another retained display list bug, which also has to do with continuations and it is almost an identical copy of the reduced testcase of this bug.

Flags: needinfo?(tnikkel)
Pushed by tnikkel@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2e967a26d2ed
Handle a rare case of a placeholder and its out of flow frame not being in the same continuation of it's containing block frame in retained display list code. r=mstange
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch
Attached file frametree.html
Flags: qe-verify+

Reproducible on a 2023-04-10 Nightly build on Windows 10.
Verified as fixed on Firefox 114.0b2(build ID: 20230509180058) and Nightly 115.0a1(build ID: 20230509215006) on Windows 10, macOS 12, Ubuntu 22.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: