Closed
Bug 505706
Opened 15 years ago
Closed 13 years ago
display:inline-block;position:absolute hypothetical box calculation doesn't account for inline-ness
Categories
(Core :: Layout: Positioned, defect, P4)
Core
Layout: Positioned
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: teun, Assigned: dbaron)
References
(Blocks 1 open bug)
Details
(Keywords: regression, testcase)
Attachments
(3 files)
383 bytes,
text/html
|
Details | |
4.42 KB,
patch
|
Details | Diff | Splinter Review | |
6.07 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Updated•15 years ago
|
Attachment #389917 -
Attachment description: This html file displays the problem → This html file displays the problem.
Observe the position of "Ccc"
Comment 2•15 years ago
|
||
Regression range: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2007-01-27+08%3A00&maxdate=2007-01-27+12%3A00
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
Assignee | ||
Comment 3•15 years ago
|
||
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
Assignee | ||
Comment 4•15 years ago
|
||
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•15 years ago
|
||
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.
Assignee | ||
Comment 6•15 years ago
|
||
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.
Assignee | ||
Comment 7•15 years ago
|
||
That said, when in doubt, add the dependency. Maybe we should even keep them in this case.
Assignee | ||
Updated•15 years ago
|
Blocks: inline-block
Assignee | ||
Comment 8•15 years ago
|
||
I changed my mind and added those dependencies back, so ignore my previous comments about that.
Assignee | ||
Updated•15 years ago
|
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
Assignee | ||
Comment 9•15 years ago
|
||
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...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•15 years ago
|
||
I'm all in favor of getting the spec clarified before thrashing here.
Assignee | ||
Comment 11•15 years ago
|
||
Actually, I think the obvious patch is probably the correct one, and it's pretty simple. Thoughts on this approach?
Comment 12•15 years ago
|
||
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•15 years ago
|
||
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•13 years ago
|
||
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.
Assignee | ||
Comment 16•13 years ago
|
||
You got me to get around to writing this reftest.
Attachment #548679 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 17•13 years ago
|
||
And yeah, you want to file the followup on inline-table?
Comment 18•13 years ago
|
||
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
Attachment #548679 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 19•13 years ago
|
||
http://hg.mozilla.org/integration/mozilla-inbound/rev/74a4b995cfe9 (Feel free to add more testcases... it could use a few more.)
Assignee: nobody → dbaron
Flags: in-testsuite?
Priority: -- → P4
Target Milestone: --- → mozilla8
Comment 20•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/74a4b995cfe9
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•