Last Comment Bug 437722 - Relatively positioned buttons should be abs pos containing block
: Relatively positioned buttons should be abs pos containing block
Status: RESOLVED FIXED
[fixed by bug 10209]
: testcase
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: All All
: -- normal with 8 votes (vote)
: mozilla10
Assigned To: :Ehsan Akhgari (busy, don't ask for review please)
:
Mentors:
https://bugzilla.mozilla.org/attachme...
: 544212 551923 582196 632368 655591 (view as bug list)
Depends on: 10209 63895 455338
Blocks: 503289
  Show dependency treegraph
 
Reported: 2008-06-06 18:43 PDT by negora
Modified: 2015-12-17 00:31 PST (History)
21 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (334 bytes, text/html)
2010-11-01 12:13 PDT, Emil Ivanov
no flags Details
testcase2 (309 bytes, text/html)
2010-11-01 12:16 PDT, Emil Ivanov
no flags Details
Reftest (2.98 KB, patch)
2011-10-06 14:57 PDT, :Ehsan Akhgari (busy, don't ask for review please)
roc: review+
Details | Diff | Review

Description negora 2008-06-06 18:43:21 PDT
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 2008-06-06 18:53:53 PDT
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 [:bz] (Out June 25-July 6) 2008-06-06 19:09:22 PDT
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 2008-06-07 02:49:44 PDT
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 [:bz] (Out June 25-July 6) 2008-06-07 05:22:45 PDT
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 2008-06-12 05:42:41 PDT
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 6 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-02-04 07:02:48 PST
*** Bug 544212 has been marked as a duplicate of this bug. ***
Comment 7 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-03-12 07:23:37 PST
*** Bug 551923 has been marked as a duplicate of this bug. ***
Comment 8 Boris Zbarsky [:bz] (Out June 25-July 6) 2010-07-27 08:22:05 PDT
*** Bug 582196 has been marked as a duplicate of this bug. ***
Comment 9 Filipe Martins 2010-10-25 09:50:35 PDT
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] 2010-10-26 22:23:35 PDT
(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 2010-11-01 12:13:59 PDT
Created attachment 487381 [details]
testcase

testcase from comment 0
Comment 12 Emil Ivanov 2010-11-01 12:16:06 PDT
Created attachment 487382 [details]
testcase2

testcase with text inside the button
Comment 13 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-02-08 07:36:26 PST
*** Bug 632368 has been marked as a duplicate of this bug. ***
Comment 14 Alex Dyer 2011-03-02 13:11:39 PST
(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 15 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-05-09 08:40:49 PDT
*** Bug 655591 has been marked as a duplicate of this bug. ***
Comment 16 Ilia 2011-08-05 06:53:49 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2011-09-29 14:56:05 PDT
The infrastructure for this has landed in bug 10209.
Comment 18 XtC4UaLL [:xtc4uall] 2011-09-30 21:59:05 PDT
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) 2011-10-03 16:44:13 PDT
(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 :Ehsan Akhgari (busy, don't ask for review please) 2011-10-03 21:36:19 PDT
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) 2011-10-04 02:21:24 PDT
(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 :Ehsan Akhgari (busy, don't ask for review please) 2011-10-06 14:57:11 PDT
Created attachment 565367 [details] [diff] [review]
Reftest
Comment 23 :Ehsan Akhgari (busy, don't ask for review please) 2011-10-07 06:59:17 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/135f05446edc
Comment 25 Will 2014-12-08 08:11:12 PST
This error think it is solved, Now the URL http://riojaweb.es its Ok!!

Thanks
Comment 26 emarblanc 2015-12-17 00:31:35 PST
Really a hard work to resolve this bug, but now the web http://marioblancov.es/posicionamiento-web-la-rioja/ run perfectly.

Note You need to log in before you can comment on or make changes to this bug.