ViewportFrame is orthogonal to nsCanvasFrame's mCustomContentContainer when setting vertical writing-mode on <html>
Categories
(Core :: Layout: Block and Inline, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: TYLin, Assigned: TYLin)
References
Details
Attachments
(3 files)
The backout in bug 1102175 comment 39 happens only on Android because AccessibleCaret is enabled, making nsCanvasFrame create mCustomContentContainer.
When setting vertical writing-mode on <html>, ViewportFrame and nsCanvasFrame's child mCustomContentContainer become orthogonal during reflow. Thus, it causes this assertion in FindFontInflationDataFor(). In the assertion condition, aFrame is custom content container's primary frame where bfc is ViewportFrame.
Why is mCustomContentContainer's used writing-mode horizontal? When mCustomContentContainer is constructed, it inherits its writing-mode from nsCanvasFrame, which is a default horizontal-tb writing-mode inheriting further up from Viewport. Later in nsCanvasFrame::MaybePropagateRootElementWritingMode(), we then propagate <html>'s used mWritingMode (vertical) all the way up to Viewport. Bug 1102175 Part 1 changes how we propagate the used writing-mode up (either taken from <html> or <body>), but the situation is the same.
The attached test case can trigger the assertion on destkop browser by enabling layout.accessiblecaret.enabled=true and all the test-pref listed here.
| Comment hidden (obsolete) |
|
Assignee | |
Comment 2•6 years ago
|
||
The only caller SetRootElementFrameAndConstructCanvasAnonContent()
already passes nsContainerFrame* to aFrame.
A minor cleanup discovered while working on this bug.
Depends on D48942
|
|
Assignee | |
Updated•6 years ago
|
|
||
Updated•6 years ago
|
|
||
Comment 4•6 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/b46a40b2287c
https://hg.mozilla.org/mozilla-central/rev/0ba412a99ed5
Description
•