Open Bug 997189 Opened 7 years ago Updated 6 months ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

28 Branch
defect
Not set
normal

Tracking

()

Webcompat Priority revisit
Tracking Status
firefox28 --- affected
firefox29 --- affected
firefox30 --- affected
firefox31 --- affected

People

(Reporter: hvtorsekar, Unassigned, NeedInfo)

References

Details

(Whiteboard: [webcompat])

Attachments

(3 files, 1 obsolete file)

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.
Can you provide a testcase?
Flags: needinfo?(hvtorsekar)
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;
}
(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!
www.rentsixmile.com/login

hvt@me.com
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.
Flags: needinfo?(hvtorsekar)
Attached file Testcase (obsolete) —
(In reply to HVT from comment #4)
> www.rentsixmile.com/login
> 
> hvt@me.com
> 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.
Attached file 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)
Attachment #8408171 - Attachment is obsolete: true
Attachment #8408177 - Attachment mime type: text/plain → text/html
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
OS: Mac OS X → All
Product: Firefox → Core
Hardware: x86 → All
Per IRC, needinfo'ing roc. :-)
Flags: needinfo?(roc)
Summary: Margin-left is different in Firefox for a button element using Bootstrap3 → Abs-pos'd inline-block element with floating nextSibling is mispositioned
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?
Flags: needinfo?(roc) → needinfo?(dbaron)
Summary: Abs-pos'd inline-block element with floating nextSibling is mispositioned → Absolutely positioned inline-block (or inline) element with floating nextSibling and auto "left" is positioned to the right of the float
On attachment 8408177 [details] it matches WebKit and Blink.  Same on http://jsfiddle.net/SVs7Z/
(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.
I also stumbled up on this today with the following code: http://jsbin.com/wakuse/4/
Attached file 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).

Flags: webcompat?
Whiteboard: [webcompat]

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

Webcompat Priority: --- → ?

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

Webcompat Priority: ? → revisit
Flags: webcompat?
You need to log in before you can comment on or make changes to this bug.