Relatively positioned buttons should be abs pos containing block

RESOLVED FIXED in mozilla10

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
9 years ago
2 years ago

People

(Reporter: negora, Assigned: Ehsan)

Tracking

({testcase})

Trunk
mozilla10
testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 10209], URL)

Attachments

(3 attachments)

(Reporter)

Description

9 years ago
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", ""));
(Reporter)

Updated

9 years ago
Component: Build Config → Layout: Form Controls
Product: Firefox → Core
(Reporter)

Comment 1

9 years ago
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.
QA Contact: build.config → layout.form-controls
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...
Status: UNCONFIRMED → NEW
Depends on: 63895
Ever confirmed: true
Summary: Absolute CSS coordinates inside of BUTTON which has a relative position fail → Relatively positioned buttons should be abs pos containing block
(Reporter)

Comment 3

9 years ago
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.
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.
Version: unspecified → Trunk
(Reporter)

Comment 5

9 years ago
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.
Depends on: 455338
Blocks: 503289
Duplicate of this bug: 544212

Updated

8 years ago
Keywords: testcase
OS: Windows XP → All
Hardware: x86 → All
Duplicate of this bug: 551923
Duplicate of this bug: 582196

Comment 9

7 years ago
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.
(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

7 years ago
Created attachment 487381 [details]
testcase

testcase from comment 0

Comment 12

7 years ago
Created attachment 487382 [details]
testcase2

testcase with text inside the button
Duplicate of this bug: 632368

Comment 14

6 years ago
(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.
Duplicate of this bug: 655591

Comment 16

6 years ago
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.
The infrastructure for this has landed in bug 10209.
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?
(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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Depends on: 10209
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [fixed by bug 10209]
Even though that this fixed, I really want to get some tests for this in the tree.  Maybe tomorrow though...
Assignee: nobody → ehsan
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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 :)
Created attachment 565367 [details] [diff] [review]
Reftest
Attachment #565367 - Flags: review?(roc)
Attachment #565367 - Flags: review?(roc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/135f05446edc
Status: REOPENED → ASSIGNED
Flags: in-testsuite? → in-testsuite+
Target Milestone: --- → mozilla10
https://hg.mozilla.org/mozilla-central/rev/135f05446edc
https://hg.mozilla.org/mozilla-central/rev/d6ea8647d990
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED

Comment 25

3 years ago
This error think it is solved, Now the URL http://riojaweb.es its Ok!!

Thanks

Comment 26

2 years ago
Really a hard work to resolve this bug, but now the web http://marioblancov.es/posicionamiento-web-la-rioja/ run perfectly.
You need to log in before you can comment on or make changes to this bug.