437722 - Relatively positioned buttons should be abs pos containing block

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[negora]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9) Gecko/2008052906 Firefox/3.0

This error happens, at least, in versions 2.x and 3.0 of Firefox for Windows XP (32-bits).

When you set a form button (<BUTTON> tag only) with a relative position and try to put content into it using absolute coordinates, the rendering engine seems to fail. It looks like if the (0,0) coordinate were displaced to the right-bottom. This is also affected by surrounding borders, margins and paddings.

On Firefox 3 I've forced the property "display" of the button to be "inline-block", just in case, but the coordinates axys are wrong too. I tryed something similar into Firefox 2 with the "block" value, with no luck.

Reproducible: Always

Steps to Reproduce:
1. Use this HTML code:

<button><div></div></button>


2. Use this CSS code (or equivalent):

button { position: relative; left: 0px; top: 0px; width: 200px; height: 100px; border: none; background-color: #00ff00; }
div { position: absolute; left: 0px; top: 0px; width: 50px; height: 50px; background-color: #ff0000; }
Actual Results:  
The layer is displaced to the right-bottom side.

Expected Results:  
The layer should appear in the coordinate (0,0), on the left-top corner.

On Opera (as an "inline-block" element by default) and Internet Explorer (as an "inline" element) it works fine. 

On Fifefox 2 and 3, even setting the property "display" to "block" and "inline-block", if suffers from the same problem.

I've no idea about how the Gecko engine works, but I guess that has to do with the default behavior to render buttons and their content, as Gecko sets everything in the center and the middle.

By now the only way which I found to solve this is making a JavaScript which corrects any absolute position inside of a relatively positioned button, and then, perform it on the document load. My "formula" has been this one:

x = div.offsetLeft - 3;
y = div.offsetTop - Math.round (25 * button.offsetHeight / 47) + window.getComputedStyle (button, "") ["borderTopWidth"].replace ("px", ""));

Comment 1

[negora]

By the way, I forgot to comment that you must set the "padding" of the button to "0px" in order to make that algorithm work. If not, you must change some of its values.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep.  The issue is that we end up using the anonymous block inside the button as a containing block (because of the wacky reparenting into the insertion frame buttons do), and then centering it inside the button.  Since it has no in-flow kids, its height is 0, and you get the resulting rendering.

Really, we should be using the button itself as the containing block, but right now only inlines and blocks can be abs pos containing blocks...

Comment 3

[negora]

Ops, so it's improbable that a possible solution appears soon, Right? At least the JavaScript "patch" is working fine by now so, as long as the rendering method doesn't change and use that block, it will work always ;) .

I was wondering if there's a way to gain access to that anonymous block using JavaScript, but taking into account that's called anonymous I guess it's not "viewable" from the DOM, obviously. Is it correct?

Many thanks Boris.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I wouldn't wager on a timeframe here.  This is a very longstanding problem that not all frames can be absolute containing blocks, and roc has been thinking about fixing it for a while.  But I don't know when he or someone else will get to it.

And yeah, you can't get at the anonymous block.  It's actually just a CSS box; it doesn't even have an associated DOM element, really.

Comment 5

[negora]

Ok, then I'll have to continue using to my "home-made" JS solution. As long as it works, I don't mind to use these tricks. Anyway I'll keep an eye on this thread to track any news.

I also wanted to thank you all, the people who make the Mozilla products possible, for all the good job. All the things which you're making are astonishing.

Comment 9

[Filipe Martins]

I found a related issue. Absolute positioning inside a (relative positioned)<BUTTON> starts after the padding. Please see this URI for a demo: http://www.maisqi.com/abs-pos-with-padding.

Seen from the outside it seems <BUTTON> is broken in Firefox. Hope you can fix it soon. Thanks.

Comment 10

[Stoyan Dimitrov [:stoyan]]

(In reply to comment #5)
> Ok, then I'll have to continue using to my "home-made" JS solution. As long as
> it works, I don't mind to use these tricks. Anyway I'll keep an eye on this
> thread to track any news.

At least for me a usable workaround is to wrap a <button> in a 'position:relative;display:inline-block'-ed span and position the needed elements (they can be in the button) using the span boundaries. Beware that inline-blocks are not recognized in Fx before, I think, v3. An additional workaround for this is to use 'display:-moz-inline-block;display:inline-block' on the span as advised in various blog posts out there. Additional minor fixes must be applied to IE8. No JS, but conditional comments and you, probably, already use them anyway.

Comment 11

[Emil Ivanov]

Attachment: testcase

testcase from comment 0

Comment 12

[Emil Ivanov]

Attachment: testcase2

testcase with text inside the button

Comment 14

[Alex Dyer]

(In reply to comment #10)
> At least for me a usable workaround is to wrap a <button> in a
> 'position:relative;display:inline-block'-ed span and position the needed
> elements (they can be in the button) using the span boundaries.

I also do this.

I find that setting

  display:block;
  position:static;
  width:100%;
  height:100%;

on the button element means that the button listens to the wrapping span/div box. With these additions to the button element you may find it easier to position the wrapping element as you wish.

I found this neccessary in order to also position internal elements absolutely to the button (divs with image sprites etc). In effect it makes the button element invisible for positioning purposes - as it is just listening to the wrapping element.

Comment 16

[Ilia]

This is still a problem in Firefox 5, see example http://jsfiddle.net/j6q2e/3/
Why is this taking so long to fix? All the other browsers figured this out ages ago.

Comment 17

[(no longer active)]

The infrastructure for this has landed in bug 10209.

Comment 18

[(mostly gone) XtC4UaLL [:xtc4uall]]

Both attached Testcases + the JSFiddle Example of Comment 16 render the same as WebKit 535.5 for me with Bug 10209 fixed. Sufficient to resolve?

Comment 19

[Mounir Lamouri (:mounir)]

(In reply to XtC4UaLL [:xtc4uall] from comment #18)
> Both attached Testcases + the JSFiddle Example of Comment 16 render the same
> as WebKit 535.5 for me with Bug 10209 fixed. Sufficient to resolve?

It seems fixed indeed. Please reopen if I missed something.

Comment 20

[(no longer active)]

Even though that this fixed, I really want to get some tests for this in the tree.  Maybe tomorrow though...

Comment 21

[Mounir Lamouri (:mounir)]

(In reply to Ehsan Akhgari [:ehsan] from comment #20)
> Even though that this fixed, I really want to get some tests for this in the
> tree.  Maybe tomorrow though...

I might be pedantic, that is why 'in-testsuite: ?' was set. Technically, the bug is fixed. Though, I'm not going to complain if you want the bug to be open to write some tests :)

Comment 22

[(no longer active)]

Attachment: Reftest

Comment 23

[(no longer active)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/135f05446edc

Comment 24

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/mozilla-central/rev/135f05446edc
https://hg.mozilla.org/mozilla-central/rev/d6ea8647d990