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).
Inline-block isn't supported in Mozilla.
*** This bug has been marked as a duplicate of 9458 ***
(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.
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.
-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...
(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).
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!
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:
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...
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.
Created attachment 189987 [details]
Extremely simplified testcase.
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.
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
Actually, never mind, I think the whole thing is dependent on font sizes or
window sizes in a way I wasn't accounting for.
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:
In that period the list-items get a large width.
Between 2005-05-16 2005-05-18:
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.
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.
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
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 MultiZilla/126.96.36.199u SeaMonkey/1.5a
Fixed on trunk by reflow branch landing.
*** Bug 401080 has been marked as a duplicate of this bug. ***