Bug 234980

Summary:	Various RenderLayer issue with <dialog>
Product:	WebKit	Reporter:	Tim Nguyen (:ntim) <ntim>
Component:	Layout and Rendering	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED CONFIGURATION CHANGED
Severity:	Normal	CC:	bfulgham, simon.fraser, webkit-bug-importer, zalan
Priority:	P2	Keywords:	InRadar
Version:	WebKit Nightly Build
Hardware:	Unspecified
OS:	Unspecified
Bug Depends on:
Bug Blocks:	84635

Description Tim Nguyen (:ntim) 2022-01-07 13:02:15 PST

Why?

- Avoid a myriad of establishesTopLayer() checks over the place
- Avoids needing to think about top layer later on


Tasks:
- Make RenderLayer::addChild/updateLayerPosition and anything else that relies on renderer hierarchy
- Need to look into a bunch of new assertions
- Fix visibility code to not be affected by layer reparenting (DOM/flat tree hierarchy should be followed for visibility, like for display)

Comment 1 Radar WebKit Bug Importer 2022-01-13 11:08:30 PST

<rdar://problem/87560426>

Comment 2 Simon Fraser (smfr) 2022-01-14 11:44:54 PST

These are the ancestor tree walks I've found that need thinking about in terms of top layer:

    setAncestorChainHasSelfPaintingLayerDescendant
    setAncestorChainHasVisibleDescendant

    SVGRenderingContext::calculateTransformationToOutermostCoordinateSystem

    enclosingScrollableLayer()

    RenderElement::moveLayers
    RenderElement::findNextLayer

    traverseAncestorLayers
    enclosingFragmentedFlowAncestor

Comment 3 Simon Fraser (smfr) 2022-01-19 12:08:24 PST

I think all the examples above are taken care of by RenderLayer reparenting (fixed in bug 235194).

So the only remaining issue is an incorrect opacity computation in ContentChangeObserver::isVisuallyHidden() (bug 235240).

Comment 4 Simon Fraser (smfr) 2022-01-19 12:20:56 PST

Closing since this is covered by other bugs.