The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

()

Core
Layout: Block and Inline
RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: lightsolphoenix, Assigned: dbaron)

Tracking

Trunk
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
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
Inline-block isn't supported in Mozilla.

*** This bug has been marked as a duplicate of 9458 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 2

12 years ago
(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.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Updated

12 years ago
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
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.
(Assignee)

Comment 4

12 years ago
-moz-inline-box is very very different from inline-block -- it's a XUL box,
inline, not a CSS block, inline.
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.
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.
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).
oh yeah, there's both -moz-inline-box and -moz-inline-block...
(Reporter)

Comment 9

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

Comment 10

12 years ago
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.
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!
(Reporter)

Comment 12

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

Comment 13

12 years ago
Created attachment 189982 [details]
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.
(Reporter)

Comment 14

12 years ago
Created attachment 189987 [details]
Extremely simplified testcase.
(Reporter)

Comment 15

12 years ago
Created attachment 189988 [details]
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.

Updated

12 years ago
Summary: Inline-block broken in Deer Park Alpha 2? → -moz-inline-block broken in Deer Park Alpha 2?
(Assignee)

Comment 16

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

Comment 17

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

Comment 18

12 years ago
If somebody who can reproduce the bug reliably could figure out a regression
date, that would probably be helpful.
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.
(Reporter)

Comment 20

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

11 years ago
Created attachment 207061 [details]
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
(Assignee)

Comment 22

10 years ago
Fixed on trunk by reflow branch landing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago10 years ago
Component: Style System (CSS) → Layout: Block and Inline
Depends on: 300030
Flags: in-testsuite?
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Duplicate of this bug: 401080
You need to log in before you can comment on or make changes to this bug.