Closed Bug 1741864 Opened 3 years ago Closed 3 years ago

'writing-mode: vertical-rl;' inside a fixed/absolute position container causes a wrong position

Categories

(Core :: Layout, defect)

Firefox 94
defect

Tracking

()

RESOLVED DUPLICATE of bug 1473789

People

(Reporter: martin.luft, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

Steps to reproduce:

<div style="position: fixed; right: 0px;">
<span style="writing-mode: vertical-rl;">TEST</span>
</div>

Actual results:

The label TEST is outside of the viewport.

Expected results:

The label TEST should be positioned at the right top corner (in Chrome it works).

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Layout
Product: Firefox → Core

Same problem with 'position: absolute':

<div style="position: absolute; right: 0px;">
<span style="writing-mode: vertical-rl;">TEST</span>
</div>

Summary: 'writing-mode: vertical-rl;' inside a fixed position container causes a wrong position → 'writing-mode: vertical-rl;' inside a fixed/absolute position container causes a wrong position

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jwatt)

Thanks for the bug report, and sorry for any trouble that it might be causing.

This is a version of bug 1473789. Unfortunately, there are some rough edges around sizing in orthogonal flows (nested elements with different writing-modes).

More notes on the relation to the other bug: if I load the testcase from comment 0 here...

data:text/html,<div style="position: fixed; right: 0px;"><span style="writing-mode: vertical-rl;">TEST</span></div>

...and use devtools to add and then remove e.g. padding:1px to the span, then the layout fixes itself ("TEST" snaps into view at the top right). So we're getting something wrong (incorrectly 0-sized) on the initial layout, which we then may later fix on incremental layouts (with the right set of dynamic changes, e.g. padding add/remove in this case). So: that makes this effectively the same underlying issue as bug 1473789.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jwatt)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.