505706 - display:inline-block;position:absolute hypothetical box calculation doesn't account for inline-ness

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect, P4)

Description

[Teun van Eijsden]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

When styling an element with  { display:inline-block;position:absolute; }
The first element in a block is rendered ok but the following elements are treated like display:block; so the are rendered at the beginning of the next line.


Reproducible: Always

Steps to Reproduce:
1. Open attachment
2 [review]. Observe location of second span
Actual Results:  
Span is rendered on the beginning of the next line

Expected Results:  
Span is rendered on the left of the second input

Comment 1

[Teun van Eijsden]

Attachment: This html file displays the problem. Observe the position of "Ccc"

Comment 2

[Ria Klaassen (not reading all bugmail)]

Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-01-27+08%3A00&maxdate=2007-01-27+12%3A00

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Ria, I don't think calling all tests that use inline block regressions from when we started supporting inline-block is particularly useful.  Of course the tests behaved differently before we supported inline-block... but that's just telling you what our behavior is when you use display:inline instead, not that there's a problem with the patch that implemented inline-block.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

To be clear:  the regression range is useful; I'm just saying you shouldn't mark it as a dependency in cases like that.

Comment 5

[Ria Klaassen (not reading all bugmail)]

Ok, I thought this was the meaning of dependencies, keeping bugs or imperfections together that start from a certain point, even if it is a new feature.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

If it's a bug in the new feature, or a bug in something else caused by implementation of the new feature, yes, absolutely.  However, in this case, it's probably an unrelated bug whose testcase just happens to use the new feature.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That said, when in doubt, add the dependency.  Maybe we should even keep them in this case.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I changed my mind and added those dependencies back, so ignore my previous comments about that.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Basically, we need to fix the code in nsHTMLReflowState::CalculateHypotheticalBox to account for inline-block, inline-table, and -moz-inline-box.  Or maybe we don't, and should just leave it as-is.  We should probably get the spec to say something first, though...

Comment 10

[Boris Zbarsky [:bzbarsky]]

I'm all in favor of getting the spec clarified before thrashing here.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: possible patch

Actually, I think the obvious patch is probably the correct one, and it's pretty simple.  Thoughts on this approach?

Comment 12

[Boris Zbarsky [:bzbarsky]]

That makes sense to me, though I do have a question.  Where is the baseline for inline-blocks?  If it's the first line, this looks good.  If it's the last one, then setting the hypothetical box bottom to the bottom of the line instead might make more sense....

Comment 13

[Ria Klaassen (not reading all bugmail)]

Mr Baron:
 
In most cases I only add dependencies to get the bug listed somewhere and because of the flood of notifications. There is a high likeliness that even if the dependency is not the real cause (but only made a bug visible for instance), relevant people are e-mailed.
When I can' t find an obvious culprit (because there are too many in the range), I do a guess and hopefully I remember the bug if no-one replied so I can try to CC another possibly interested person.
When I have no time or there is no testcase I just try the most likely component but I' m aware that I may be wrong. And the amount of response is lower then generally.
My aim is to notify possibly interested people that the bug exists. In a lot of cases I only vaguely understand what the bug is about.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 390100 [details] [diff] [review]
possible patch

I just independently wrote this exact patch, modulo some naming differences, when looking at bug 674435.  It fixes the bug for inline-block, but not inline-table because the mOriginalDisplay for the table-outer is "table" (since the display for it inherits, and inheritance happens after clamping).

I think we should go ahead and take this patch, except for that baseline business, then file a followup for inline-table.

Comment 16

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: patch

You got me to get around to writing this reftest.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And yeah, you want to file the followup on inline-table?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 548679 [details] [diff] [review]
patch

I filed bug 674449.

What about the baseline issue?  For single-line inline-blocks there's no difference, but for a multiline one we're not quite putting it in the static position.

On the other hand, this patch gives us compat with WebKit for multiline positioned inline-block, so I guess this is fine.  r=me

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/74a4b995cfe9

(Feel free to add more testcases... it could use a few more.)

Comment 20

[Marco Bonardo [:mak]]

http://hg.mozilla.org/mozilla-central/rev/74a4b995cfe9