1283721 - Incorrect positioning of orthogonal (horizontal-tb) block alongside vertical-rl floats

Status: VERIFIED FIXED

(Core :: Layout: Floats, defect)

Description

[Toru Kawakubo]

Attachment: float-writing-mode-testcase.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160630030207

Steps to reproduce:

Open the attached testcase.


Actual results:

The red block comes to the left of the green float.
When 'writing-mode: horizontal-tb' is removed from the red block, it comes to the right of the green float, which is the expected result.


Expected results:

The red block comes to the right of the green float.

Comment 1

[Gérard Talbot]

Toru,

orange block has 'height: 100px'
http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-001.html


orange block has 'height: 100%'
http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-002.html
Chrome 53 places the orange rectangle below the blue square
Firefox 50.0a1 buildID=20160701121753 places the orange rectangle to the left of the olive square


Right now, I can not make a decision on your test and code scenario. At this point, I think it would be best to ask Elika to have a look and give her opinion on this.

regards, Gérard

Comment 2

[Gérard Talbot]

Hmm... I now think that Firefox is doing the right thing based on this test:

http://www.gtalbot.org/BugzillaSection/Bug1283721-wide-new-block-form-ctxt-alongside-floats-003.html

but again, Toru, I wish Elika would make the definite decision on your interesting code scenario.

regards, Gérard

Comment 3

[Toru Kawakubo]

In my testcase, the first float has zero height.
I have not read through Writing Mode spec, but I thought that the red block, which has 'height: 100%', should be below the first float since there is enough space for it.
If the first float had non-zero height, it would be natural for the red block to come to the left of the green float.

> Hmm... I now think that Firefox is doing the right thing based on this test:
> http://www.gtalbot.org/BugzillaSection/Bug1283721-wide-new-block-form-ctxt-alongside-floats-003.html

In your example, the first float (blue one) has non-zero width. If its width is zero, the orange block comes to the right of the first float.

Comment 4

[Gérard Talbot]

> In my testcase, the first float has zero height.
> I have not read through Writing Mode spec, but I thought that the red block,
> which has 'height: 100%', should be below the first float since there is
> enough space for it.

I see what you mean here. 
For reference purposes:
Bug 81710: Empty floats don't take up room [FLOAT] (zero height)

I am still hesitant... In your testcase, the red block - which creates a new block formatting context [1] - can not fit below its nearest, closest sibling, the narrow light green bar. So, it stops there and moves, "parks" itself immediately after (to the left of) that narrow light green bar. The red block is trying to be below that narrow light green bar and is not trying to do this with earlier siblings (the 0px height first float, further on the right side). Nearest (Firefox) versus earliest float with sufficient space (Chrome). Right now, I do not know why this is like that.

Toru, I am not saying you are wrong here. I do not know for sure right now.

> If the first float had non-zero height, it would be natural for the red
> block to come to the left of the green float.

Natural? Possible. What I am mostly looking for is what the spec states on this.

Right now, this test

http://www.gtalbot.org/BugzillaSection/Bug1283721-new-block-form-ctxt-alongside-floats-004.html

,assuming Firefox is compliant with the spec, suggests that you are correct: the orange rectangle could have "parked" itself on the right-hand side of the 2nd (olive) float since there was sufficient space available there but no, it "parked" itself on the right-hand side of the 1st (blue) float. The earliest sibling and not necessarly the nearest sibling. 

I think the following sentence of the spec that is decisive in that Bug1283721-new-block-form-ctxt-alongside-floats-004 test is: 

"
Since a float is not in the flow, non-positioned block boxes [such as the red block in your test] created before and after the float box flow vertically as if the float did not exist.
"
https://www.w3.org/TR/CSS21/visuren.html#floats

Another test:
http://www.gtalbot.org/BugzillaSection/Bug1283721-new-block-form-ctxt-alongside-floats-005.html
that seem to support your perspective.

So, that would explain why the red block goes all the way to the right side, below the first float with 'height: 0px'.

I am really eager to see what Elika thinks on all this.

- - - - -

[1]: 
"
If a box has a different writing-mode value than its containing block:
(...)
    If the box is a block container, then it establishes a new block formatting context. 
"
https://www.w3.org/TR/css-writing-modes-3/#block-flow

Comment 5

[Gérard Talbot]

> > http://www.gtalbot.org/BugzillaSection/Bug1283721-wide-new-block-form-ctxt-alongside-floats-003.html
> 
> In your example, the first float (blue one) has non-zero width. If its width
> is zero, the orange block comes to the right of the first float.

Yes. So, Toru, it seems this is a valid bug. 

I am waiting for Elika to confirm this. The spec on floats is sometimes very tricky.

Comment 6

[Gérard Talbot]

I have more tests which, I believe, will help. The 006vrl is basically the same code design as attachment 8767026 [details]; the only worth-mentioning difference is that attachment 8767026 [details] uses a 100% and 0% height whereas in the 006vrl test, I use a 80% and 20% height. That way, I can paint the rectangles and write a few words in those.


http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-006vrl.html
Firefox 47 and Firefox 50.0a1 buildID=20160704120323 position the orange rectangle on the left of the olive rectangle.
Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle below the blue rectangle.


http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-006htb.html 
is the 'horizontal-tb' equivalent of the previous test.
Firefox 47, Firefox 50.0a1 buildID=20160704120323, Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle on the right of the blue rectangle. Based on that test only, then we should conclude that Firefox 47+ fails 006vrl test and that Chrome 51+ passes 006vrl test.


- - - - - - 


http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-007vrl.html
Firefox 47 and Firefox 50.0a1 buildID=20160704120323 position the orange rectangle below the olive rectangle.
Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle below the blue rectangle and creates an overflow of the body element and a vertical scrollbar.


http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-floats-007htb.html
is the 'horizontal-tb' equivalent of the previous test.
Firefox 47, Firefox 50.0a1 buildID=20160704120323, Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle on the right of the olive rectangle. Based on that test only, then we should conclude that Chrome 51+ fails the 007vrl test and that Firefox 47+ passes the 007vrl test.

Comment 7

[Gérard Talbot]

(In reply to Gérard Talbot from comment #6)
> I have more tests which, I believe, will help. The 006vrl is basically the
> same code design as attachment 8767026 [details]; the only worth-mentioning
> difference is that attachment 8767026 [details] uses a 100% and 0% height
> whereas in the 006vrl test, I use a 80% and 20% height. That way, I can
> paint the rectangles and write a few words in those.
> 
> 
> http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-
> floats-006vrl.html
> Firefox 47 and Firefox 50.0a1 buildID=20160704120323 position the orange
> rectangle on the left of the olive rectangle.
> Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle
> below the blue rectangle.

IE11 and Edge position the orange rectangle below the blue rectangle in 006vrl.

 
> 
> http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-
> floats-006htb.html 
> is the 'horizontal-tb' equivalent of the previous test.
> Firefox 47, Firefox 50.0a1 buildID=20160704120323, Chrome 51.0.2704.106 and
> Chrome 53.0.2783.2 position the orange rectangle on the right of the blue
> rectangle. 

IE11 and Edge also position the orange rectangle on the right of the blue
rectangle in 006htb. 


> Based on that test only, then we should conclude that Firefox 47+
> fails 006vrl test and that Chrome 51+ passes 006vrl test.
> 
> 
> - - - - - - 
> 
> 
> http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-
> floats-007vrl.html
> Firefox 47 and Firefox 50.0a1 buildID=20160704120323 position the orange
> rectangle below the olive rectangle.

IE11 and Edge also position the orange rectangle below the olive rectangle in 007-vrl.


> Chrome 51.0.2704.106 and Chrome 53.0.2783.2 position the orange rectangle
> below the blue rectangle and creates an overflow of the body element and a
> vertical scrollbar.
> 
> 
> http://www.gtalbot.org/BugzillaSection/Bug1283721-ortho-htb-alongside-vrl-
> floats-007htb.html
> is the 'horizontal-tb' equivalent of the previous test.
> Firefox 47, Firefox 50.0a1 buildID=20160704120323, Chrome 51.0.2704.106 and
> Chrome 53.0.2783.2 position the orange rectangle on the right of the olive
> rectangle. 

IE11 and Edge position the orange rectangle on the right of the olive rectangle in 007htb. 

> Based on that test only, then we should conclude that Chrome 51+
> fails the 007vrl test and that Firefox 47+ passes the 007vrl test.

Comment 8

[fantasai]

Confirming, based on gtalbot's analysis and especially the testcases in comment 6. morizontal and vertical formatting must be analogous.

Comment 9

[Xidorn Quan [:xidorn] UTC+11]

I wonder whether it contains any impl-dependent behavior. (It doesn't seem to me.) If not, Gérard, are you going to submit this test to CSSWG's test repo?

Comment 10

[Xidorn Quan [:xidorn] UTC+11]

Attachment: Bug 1283721 - Use block-size rather than height for computing float available space.

Review commit: https://reviewboard.mozilla.org/r/62808/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/62808/

Comment 11

[Xidorn Quan [:xidorn] UTC+11]

Probably need a test... but if Gérard's going to submit that test to CSSWG's repo, I'd rather hold back and probably try to import the whole set of writing mode tests from CSSWG later (bug 1258916).

Comment 12

[Jonathan Kew [:jfkthame]]

Comment on attachment 8768725 [details]
Bug 1283721 - Use block-size rather than height for computing float available space.

https://reviewboard.mozilla.org/r/62808/#review59700

Looks like this was simply an oversight during the conversion to logical coordinates. Thanks!

Comment 13

[Xidorn Quan [:xidorn] UTC+11]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=634b6650381c

Comment 14

[Gérard Talbot]

(In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #9)
> Gérard, are you going to submit this test to CSSWG's test
> repo?

Yes, it was my intent to. This is furthermore important to do because Google Chrome 51+ does not render Bug1283721-ortho-htb-alongside-vrl-floats-007vrl.html as we expect.

Right now, I want to submit a different version of Bug1283721-ortho-htb-alongside-vrl-floats-006vrl.html and a different version of Bug1283721-ortho-htb-alongside-vrl-floats-007vrl.html tests to CSSWG's test repo: the code design (2 vrl floats followed by 1 orthogonal non-floated block) will be essentially the same but the expected rendered layout will probably be simplified (something like "Test passes if there is a filled green square and no red.") or something different... I do not know right now.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/83d9f2759228
Use block-size rather than height for computing float available space. r=jfkthame

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/83d9f2759228

Comment 17

[Gérard Talbot]

> (In reply to Xidorn Quan [:xidorn] (UTC+10) from comment #9)
> > Gérard, are you going to submit this test to CSSWG's test
> > repo?
> 
> Yes, it was my intent to. This is furthermore important to do because Google
> Chrome 51+ does not render
> Bug1283721-ortho-htb-alongside-vrl-floats-007vrl.html as we expect.
> (...)

Xidorn,

I will create and submit several tests related to this bug report (positioning of orthogonal horizontal-tb block alongside vertical-rl floats) this week; it is on my to-do-list right now. It's probably going to be very similar to the tests I did in here.

- - - - - 

I get correct and expected results in all of the tests in this bug report while using Firefox 50.0a1 buildID=20160711113740. Therefore,

Marking as VERIFIED

Comment 18

[Gérard Talbot]

> I will create and submit several tests related to this bug report
> (positioning of orthogonal horizontal-tb block alongside vertical-rl floats)
> this week; it is on my to-do-list right now. It's probably going to be very
> similar to the tests I did in here.


Done:
http://hg.csswg.org/test/rev/5eb3c56d3304

[src; test]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-002.xht

[src; reference file]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-002-ref.xht


[src; test]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-006.xht

[src; reference file]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-006-ref.xht


[src; test]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-010.xht

[src; reference file]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-010-ref.xht


[src; test]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-014.xht

[src; reference file]
http://test.csswg.org/source/css-writing-modes-3/ortho-htb-alongside-vrl-floats-014-ref.xht

- - - - - - - -


I changed 20%, 40%, 60%, 80% to 25%, 50%, 75% to reduce the occurences of fractional pixels. This will be more obvious to the testers when they will use Chrome 50+. I have figured that 3 times out of 4, the height of the document root element will cause a fractional pixel situation and there will be a 1px difference between the test and the reference file in Chrome 50+.

I tried to make a simple reference files but the layout is quite demanding, has many constraints and is not easy to achieve.

The slot numbers missing (003, 004, 005, 007, 008, 009, 011, etc..) are in case we need to create the same tests with vertical-lr, sideways-rl, sideways-lr writing-modes.

Each test has an URL to its equivalent 'horizontal-tb' test in a comment in the <head>.