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

RESOLVED FIXED in mozilla8

Status

()

Core
Layout: R & A Pos
P4
normal
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Teun van Eijsden, Assigned: dbaron)

Tracking

(Blocks: 1 bug, {regression, testcase})

Trunk
mozilla8
regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
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

8 years ago
Created attachment 389917 [details]
This html file displays the problem.
Observe the position of "Ccc"
(Reporter)

Updated

8 years ago
Attachment #389917 - Attachment description: This html file displays the problem → This html file displays the problem. Observe the position of "Ccc"
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: 9458
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

8 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: 9458
(Assignee)

Comment 4

8 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.
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

8 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

8 years ago
That said, when in doubt, add the dependency.  Maybe we should even keep them in this case.
(Assignee)

Updated

8 years ago
Blocks: 9458
(Assignee)

Comment 8

8 years ago
I changed my mind and added those dependencies back, so ignore my previous comments about that.
(Assignee)

Updated

8 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

8 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
I'm all in favor of getting the spec clarified before thrashing here.
(Assignee)

Comment 11

8 years ago
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?
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.
(Assignee)

Updated

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

Comment 16

6 years ago
Created attachment 548679 [details] [diff] [review]
patch

You got me to get around to writing this reftest.
Attachment #548679 - Flags: review?(bzbarsky)
(Assignee)

Comment 17

6 years ago
And yeah, you want to file the followup on inline-table?
Blocks: 674449
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

6 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
http://hg.mozilla.org/mozilla-central/rev/74a4b995cfe9
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 678536

Updated

6 years ago
Depends on: 682780
You need to log in before you can comment on or make changes to this bug.