997189 - Absolutely positioned inline-block (or inline) element with floating nextSibling and auto "left" is positioned to the right of the float

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[HVT]

Attachment: Screenshot 2014-04-16 10.42.00.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

Isolated the classes 'btn' 'btn-success' to have a margin-left that pushes the div too far to the right when using 'position: relative;' for the button inside a div.


Actual results:

Specific issue happens only in Firefox and not Chrome, Safari, or Opera.


Expected results:

Margin-left should be the same as other browsers for the button element inside the div.

Comment 1

[:Gijs (he/him)]

Can you provide a testcase?

Comment 2

[HVT]

I'm not sure how to run a test case.  I attempted to change my CSS to position the button in a fixed position using position: absolute.

It seems that it only has issue with Firefox.

If this isn't helpful to you, would you be able to give me an example of a testcase that might be useful for me to give you better information.  I'll write a testcase, just not sure how to go about doing it for the purpose of illustrating a CSS positioning component.


Relevant CSS classes that are acting on the same button : 

availabilitybutton {
  margin-top:0px;
  margin-left: 150px;
  font-size: 1.2em;
  z-index: 1;
}

.showavailabilitybutton {
        margin-top: 20px;
        position: absolute;
}

Comment 3

[:Gijs (he/him)]

(In reply to HVT from comment #2)
> I'm not sure how to run a test case.

Basically, it would help if you could provide a link to a webpage or jsbin/jsfiddle that shows the issue. Ideally a page that shows only that particular issue, ie with the minimal HTML and CSS required to reproduce the issue.

Thank you!

Comment 4

[HVT]

www.rentsixmile.com/login

[e-mail]
test1234

Go to the edit button and then the page will be the edit page. 

Please note the Availability Button is not centered as it is in other browsers.

Comment 5

[:Gijs (he/him)]

Attachment: Testcase

(In reply to HVT from comment #4)
> www.rentsixmile.com/login
> 
> [e-mail]
> test1234
> 
> Go to the edit button and then the page will be the edit page. 
> 
> Please note the Availability Button is not centered as it is in other
> browsers.

Thanks! I've distilled it down to a small HTML file that also shows problematic positioning.

Comment 6

[:Gijs (he/him)]

Attachment: Testcase v0.2

So this is clearly a core bug, moving there in a second. I'm not sure what's causing the problem (or even really what's happening). Some notes:

- div.wrongplace is mispositioned
- removing its next sibling (div.inner-container) fixes things (!?)
- removing the CSS rule for the width of the outer container makes the text disappear entirely (doesn't happen in Chrome)
- removing *any* of the remaining properties for the div.inner-container (float, width, height) or div.wrongplace (position, display) fixes things, too.

It seems to me like the abs-pos'd element is not positioned on top of the float (inner-container), even though it's position: absolute. Instead, its position is dictated by the float. I don't know why.

(I included #reference to have an idea where the text should end up)

Comment 7

[:Gijs (he/him)]

Per IRC, needinfo'ing roc. :-)

Comment 8

[Boris Zbarsky [:bzbarsky]]

So looking at the testcase....

div.wrongplace is absolutely positioned and is inline-level, but does not have "left" specified.  So its left position is supposed to based on the hypothetical box (see <http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width>).  What we do there is to use the position of the placeholder, which comes to the right of the float, because the float is 100% width and the placeholder is 0 width.

If the float were only 50% width, say, our behavior would clearly be "correct"; compare the horizontal position of div.wrongplace in that situation with and without the "position: absolute".  But if the float is wide enough it would get cleared past the element if it were statically positioned, which is the situation in the attached testcase, then the behavior looks odd.

Unfortunately, the spec doesn't actually define a specific rendering in this case, which is why you're seeing differences between UAs.

I'm a bit hesitant to make changes here without a plan, since it's pretty easy to produce different testcases (see the 50% example above) where our rendering is closer to what I think is desired than the other browsers' are...

David, is there a principled way to figure out whether floats would have gotten cleared past us when determining the hypothetical box?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

What does IE do?

Comment 10

[Boris Zbarsky [:bzbarsky]]

On attachment 8408177 [details] it matches WebKit and Blink.  Same on http://jsfiddle.net/SVs7Z/

Comment 11

[David Baron :dbaron:]

(In reply to Boris Zbarsky [:bz] from comment #8)
> David, is there a principled way to figure out whether floats would have
> gotten cleared past us when determining the hypothetical box?

This question requires a good bit of analysis.  I'm going to leave this in my needinfo? queue, but I'm unlikely to get to it before mid-June, and probably not for a bit after that.

Comment 12

[Martin Lundberg]

I also stumbled up on this today with the following code: http://jsbin.com/wakuse/4/

Comment 13

[Thomas Wisniewski [:twisniewski]]

Attachment: test.html

This just bit another site on https://webcompat.com/issues/22867

I've attached a reduced test-case in the off chance that it helps. (The text overlaps in Chrome, but not in Firefox).

Comment 14

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 15

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.