22.86 KB, text/html; charset=UTF-8
1.67 KB, text/html
1.67 KB, text/html
885 bytes, text/html
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 ***
(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: 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...
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 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 that interval.
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: 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.
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 and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051228 MultiZilla/220.127.116.11u SeaMonkey/1.5a
Fixed on trunk by reflow branch landing.