Closed Bug 505706 Opened 13 years ago Closed 11 years ago

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


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






(Reporter: teun, Assigned: dbaron)


(Blocks 1 open bug)


(Keywords: regression, testcase)


(3 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 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
Attachment #389917 - Attachment description: This html file displays the problem → This html file displays the problem. Observe the position of "Ccc"
Regression range:
Blocks: inline-block
Component: General → Layout: Block and Inline
Keywords: regression, testcase
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Hardware: x86 → All
Version: unspecified → Trunk
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.
No longer blocks: inline-block
To be clear:  the regression range is useful; I'm just saying you shouldn't mark it as a dependency in cases like that.
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.
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.
That said, when in doubt, add the dependency.  Maybe we should even keep them in this case.
Blocks: inline-block
I changed my mind and added those dependencies back, so ignore my previous comments about that.
Component: Layout: Block and Inline → Layout: R & A Pos
QA Contact: layout.block-and-inline → layout.r-and-a-pos
Summary: display:inline-block;position:absolute goes to next line for all except 1st item → display:inline-block;position:absolute hypothetical box calculation doesn't account for inline-ness
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...
Ever confirmed: true
I'm all in favor of getting the spec clarified before thrashing here.
Attached patch possible patchSplinter Review
Actually, I think the obvious patch is probably the correct one, and it's pretty simple.  Thoughts on this approach?
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....
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.
Duplicate of this bug: 674435
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.
Attached patch patchSplinter Review
You got me to get around to writing this reftest.
Attachment #548679 - Flags: review?(bzbarsky)
And yeah, you want to file the followup on inline-table?
Blocks: 674449
Comment on attachment 548679 [details] [diff] [review]

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
Attachment #548679 - Flags: review?(bzbarsky) → review+

(Feel free to add more testcases... it could use a few more.)
Assignee: nobody → dbaron
Flags: in-testsuite?
Priority: -- → P4
Target Milestone: --- → mozilla8
Closed: 11 years ago
Resolution: --- → FIXED
Depends on: 678536
Depends on: 682780
You need to log in before you can comment on or make changes to this bug.