Last Comment Bug 505706 - display:inline-block;position:absolute hypothetical box calculation doesn't account for inline-ness
: display:inline-block;position:absolute hypothetical box calculation doesn't a...
Status: RESOLVED FIXED
: regression, testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: All All
: P4 normal with 1 vote (vote)
: mozilla8
Assigned To: David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
:
Mentors:
: 674435 (view as bug list)
Depends on: 678536 682780
Blocks: 674449 inline-block
  Show dependency treegraph
 
Reported: 2009-07-22 04:08 PDT by Teun van Eijsden
Modified: 2011-08-29 08:01 PDT (History)
10 users (show)
dbaron: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
This html file displays the problem. Observe the position of "Ccc" (383 bytes, text/html)
2009-07-22 04:10 PDT, Teun van Eijsden
no flags Details
possible patch (4.42 KB, patch)
2009-07-22 15:55 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
no flags Details | Diff | Splinter Review
patch (6.07 KB, patch)
2011-07-26 20:43 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review

Description Teun van Eijsden 2009-07-22 04:08:52 PDT
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 2009-07-22 04:10:06 PDT
Created attachment 389917 [details]
This html file displays the problem.
Observe the position of "Ccc"
Comment 3 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 11:56:47 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 11:57:30 PDT
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) 2009-07-22 13:03:33 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 15:33:25 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 15:35:53 PDT
That said, when in doubt, add the dependency.  Maybe we should even keep them in this case.
Comment 8 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 15:38:22 PDT
I changed my mind and added those dependencies back, so ignore my previous comments about that.
Comment 9 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 15:44:25 PDT
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 [:bz] 2009-07-22 15:48:03 PDT
I'm all in favor of getting the spec clarified before thrashing here.
Comment 11 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2009-07-22 15:55:18 PDT
Created attachment 390100 [details] [diff] [review]
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 [:bz] 2009-07-22 20:18:17 PDT
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) 2009-07-23 04:26:04 PDT
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 14 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2011-07-26 20:35:16 PDT
*** Bug 674435 has been marked as a duplicate of this bug. ***
Comment 15 Boris Zbarsky [:bz] 2011-07-26 20:42:11 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2011-07-26 20:43:45 PDT
Created attachment 548679 [details] [diff] [review]
patch

You got me to get around to writing this reftest.
Comment 17 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2011-07-26 20:46:26 PDT
And yeah, you want to file the followup on inline-table?
Comment 18 Boris Zbarsky [:bz] 2011-07-26 21:00:04 PDT
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+2 (mostly busy through August 4; review requests must explain patch) 2011-07-28 18:13:21 PDT
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] (Away 6-20 Aug) 2011-07-29 03:12:07 PDT
http://hg.mozilla.org/mozilla-central/rev/74a4b995cfe9

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