301072 - -moz-inline-block broken in Deer Park Alpha 2?

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect)

Description

[lightsolphoenix]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

Back when I was surfing with Firefox 1.0.4, I wrote a page that relied on the
behaviour of inline-block (using both -moz-inline-block and inline-block to
assure forwards compatibility, and feeding certain browsers that don't
understand inline-block other values).  However, when I went back and checked
this page in Deer Park Alpha, I noticed that DP is not handling inline-block
correctly.  Instead of using my defined width value, DP is making the first
object take up 100% of the width, and the rest of the objects are crushed in the
corner.  Is this a bug with Deer Park?  I rechecked it in 1.0.4, and it's still
fine.  Ditto in Opera (7.5 and 8).

Reproducible: Always

Comment 1

[Martijn Wargers (dead)]

Inline-block isn't supported in Mozilla.

*** This bug has been marked as a duplicate of 9458 ***

Comment 2

[lightsolphoenix]

(In reply to comment #1)
> Inline-block isn't supported in Mozilla.
> 
> *** This bug has been marked as a duplicate of 9458 ***

-moz-inline-block doesn't do anything?  Funny, I thought it did...Firefox 1.0.4
sure works with it well.

Comment 3

[Majken Connor [:Kensie]]

I have no comment on a fix to inline-block, but after a google search I found
that -moz-inline-box will do what you want it to.

Comment 4

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

-moz-inline-box is very very different from inline-block -- it's a XUL box,
inline, not a CSS block, inline.

Comment 5

[Majken Connor [:Kensie]]

I saw a few instances of people using -moz-inline-box as a work-around, the way
i understood is that if they put -inline-block and -moz-inline-box in the css
then non-moz browsers would use -inline-block correctly and ff would use
-moz-inline-box to create the same appearance.  Obviously not a fix for the bug,
but perhaps something some people can use in the meantime?

I can confirm what the reporter found, but we were waiting for you to decide if
this was a dupe of 9458, or a new problem.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

if this is asking for inline-block to be implemented, it's a duplicate of that
bug; if it's asking about -moz-inline-box issues, it's not a duplicate.

Comment 7

[Majken Connor [:Kensie]]

well he's reporting -moz-inline-block as being broken where it once worked, not
asking for it to be added, which is why we haven't been sure (I've been
discussing this with gavin).

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

oh yeah, there's both -moz-inline-box and -moz-inline-block...

Comment 9

[lightsolphoenix]

(In reply to comment #6)
> if this is asking for inline-block to be implemented, it's a duplicate of that
> bug; if it's asking about -moz-inline-box issues, it's not a duplicate.

Yeah, I'm not asking for either.  I know inline-block isn't implemented in
Firefox (though IMO it should be, seeing as inline-block is in CSS 2.1).  The
problem isn't with inline-block, it's with -moz-inline-block, which it appears
Deer Park is treating similar to (but not exactly like) block or something
similar (I can't say, I've never seen behaviour like that in CSS before).

Comment 10

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

Since this is a regression since Mozilla 1.7, it seems worth looking into.  If
people are using -moz-inline-block (despite its bugs, and hopefully not
depending on them), I'd rather they use that than -moz-inline-box (which is much
more likely to break in the future).

Any chance you could attach a testcase showing the problem?  Additionaly, a date
as to between which builds this regressed would be even more useful.

Comment 11

[Majken Connor [:Kensie]]

I used the url provided above the summary, looked at it in 1.0.4 and Deer Park
Alpha 2.  In 1.0.4 across the top you can see home, rules, etc. in Dear Park you
only see home, and then the rest are overlapped at the end.

Although https://bugzilla.mozilla.org/attachment.cgi?id=135898 doesn't look any
different between 1.0.4 and Deer Park.

Here is the discussion about this I found elsewhere that I mentioned
http://archivist.incutio.com/viewlist/css-discuss/45982 it has lots of specific
info about versions etc. Hope it helps!

Comment 12

[lightsolphoenix]

Oh, BTW, I just realized I didn't know whether the Firefox 1.0.4 behavior or the
Deer Park behaviour was the right one; but according to this:

http://www.w3.org/TR/CSS21/visudet.html#q12

Firefox 1.0.4's behaviour is correct.

BTW, checking the Internet for information on inline-block in Firefox, I found
that this particular error has happened before; actually, between Firefox 0.9
and Firefox 1.0.  That seems kind of odd...

Comment 13

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

Attachment: partly simplified testcase

I had trouble simplifying the markup further.  A more simplified testcase is
likely to be needed to figure out what the problem is.

Comment 14

[lightsolphoenix]

Attachment: Extremely simplified testcase.

Comment 15

[lightsolphoenix]

Attachment: Extremely simplified testcase.

Okay, I attached an extremely simplified testcase of this bug.	I tore out all
the HTML and CSS I could that kept the bug present, and removed all that had no
efffect on the bug...but it appears the trigger may be part of the default CSS,
because I could remove almost all the CSS I wrote.  It appears to be effected
more by the prescence/absense of certain elements.

Comment 16

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

The behavior on those last two testcases seems to be the same on the trunk and
in Firefox 1.0.x, whereas the behavior on the testcase I attached changed in
that interval.

Comment 17

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

Actually, never mind, I think the whole thing is dependent on font sizes or
window sizes in a way I wasn't accounting for.

Comment 18

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

If somebody who can reproduce the bug reliably could figure out a regression
date, that would probably be helpful.

Comment 19

[Martijn Wargers (dead)]

Ok, I get two regression periods, tested with the "partly simplified testcase":
Between 2004-12-05 and 2004-12-06:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-12-05+08%3A00%3A00&maxdate=2004-12-06+10%3A00%3A00&cvsroot=%2Fcvsroot
In that period the list-items get a large width.

Between 2005-05-16 2005-05-18:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-05-16+06%3A00%3A00&maxdate=2005-05-18+08%3A00%3A00&cvsroot=%2Fcvsroot
With/after the 2005-05-18 build, I get current behavior, a horizontal page
scrollbar, only the "home" list-item very wide and the rest packed at the right
of the page.

Comment 20

[lightsolphoenix]

I tried to figure out exactly what's causing this bug, but I can't seem to minimize it down.  It's kind of an odd bug; it's effected more by the HTML tags and the order they appear in than the CSS itself.  When I was trying to build a simple test case, I found that removing CSS did nothing to the bug, but removing certain tags (like most of the header tags, some of the divs), would cause the bug to disappear.  Could it be some kind of HTML inheritance bug related to -moz-inline-block?

BTW, this bug still shows up, even in the latest beta versions.

Comment 21

[thomthom1969]

Attachment: Bare-bones test case, with variations

Stripped down <header> in response to Comment #20.  Note Span2 material appears outside containing block in Paras 1 and 3; may need to maximize window to see it in latter case, as max-width is removed from <p>.

Problem appears on both

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 Firefox/1.6a1

and

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 MultiZilla/1.8.1.0u SeaMonkey/1.5a

Comment 22

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

Fixed on trunk by reflow branch landing.