Inaccurate margin-right of horizontal rule (with vertical-rl writing-mode) in a horizontal block flow

RESOLVED FIXED in Firefox 40

Status

()

RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: bugzilla, Assigned: jfkthame)

Tracking

(Blocks: 1 bug, {testcase})

Trunk
mozilla40
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox40 fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Tests (with vendor-prefixes)
----------------------------

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s71-horizontal-rule-vrl-004.xht

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s71-horizontal-rule-vlr-005.xht

Expected results
----------------

http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/s71-horizontal-rule-vrl-004-ref.xht

Explanation
-----------

The margin-right at the righthand side of the green bar should be exactly 8px and *not 18px*.

Notes
-----
- Those tests (along with 2 other horizontal-rule tests) have been submitted to the test.csswg.org repository 
http://lists.w3.org/Archives/Public/public-css-testsuite/2015Mar/0003.html
but have not yet been reviewed
- Chrome 41.0.2272.89 pass these 2 tests. IE11 and Prince 9.0.5 fail these 2 tests.
- I am using Firefox 39.0a1 buildID=20150312145815
- I use Linux 3.16.0-31-generic x86_64, Qt: 4.8.6, KDE 4.14.1; Kubuntu (utopic) 14.10
- I've searched for duplicates and did not find any
- When vertically resizing the viewport, there is a reflow bug with these 2 tests. I will file another bug report for that issue.
(Reporter)

Updated

4 years ago
Depends on: 145503
Keywords: testcase
(Reporter)

Updated

4 years ago
Blocks: 145503
No longer depends on: 145503
(Assignee)

Comment 1

4 years ago
FWIW, in a debug build these testcases also hit an assertion (several times):

[58682] ###!!! ASSERTION: Shouldn't be incomplete if availableBSize is UNCONSTRAINED.: 'aReflowState.AvailableBSize() != NS_UNCONSTRAINEDSIZE', file /Users/jkew/mozdev/mozilla-inbound/layout/generic/nsBlockFrame.cpp, line 1571
(Assignee)

Comment 2

4 years ago
Created attachment 8589091 [details]
testcase showing incorrect handling of carried-out block-end margin

The problem here isn't specific to <hr>; this testcase shows similar behavior with a <div>. What seems to be happening is that when the preceding block element (the <p>) has a bottom (block-end) margin, that is being incorrectly incorporated into the computation of the available block-size (width) for the vertical writing-mode block (the rule).

This example includes four tests, with the <p> having a margin only on its top, right, bottom or left side. Note how in the case where it has a bottom margin, the width of the colored bar is reduced by the same amount; the other three cases render correctly.
(Assignee)

Comment 3

4 years ago
Created attachment 8589109 [details] [diff] [review]
Take account of orthogonal writing modes when adjusting available size to reflow a child frame

This fixes the rendering of the testcases here, and gets rid of the assertion we're hitting. It also fixes the reflow error described in bug 1144505.
Attachment #8589109 - Flags: review?(smontagu)
(Assignee)

Updated

4 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Comment 4

4 years ago
Created attachment 8589147 [details] [diff] [review]
Reftest for sizing of orthogonal frame after block-end margin

Reftest based on the testcase here: the writing mode of the 'hr' div should not affect rendering.
Attachment #8589147 - Flags: review?(smontagu)
Attachment #8589109 - Flags: review?(smontagu) → review+
Attachment #8589147 - Flags: review?(smontagu) → review+
(Assignee)

Updated

4 years ago
Blocks: 1138384
https://hg.mozilla.org/mozilla-central/rev/6e469cebd8d7
https://hg.mozilla.org/mozilla-central/rev/e73ef97e7ab0
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
status-firefox40: --- → fixed
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla40

Updated

3 years ago
Depends on: 1243125
You need to log in before you can comment on or make changes to this bug.