Closed Bug 682780 Opened 13 years ago Closed 13 years ago

jig.com looks different in aurora vs. firefox

Categories

(Core :: Layout: Positioned, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID
mozilla8
Tracking Status
firefox8 + unaffected

People

(Reporter: davedash, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: dev-doc-needed)

Attachments

(3 files)

Attached image Screenshot of jig.com
I noticed some odd rendering issue in Aurora that I don't see in Firefox (same profile) or Chrome.

See attached.
WFM:
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.20) Gecko/20110803 Firefox/3.6.20
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20100101 Firefox/6.0
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20100101 Firefox/7.0
Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.9.168 Version/11.50
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1

Reproduced:
Mozilla/5.0 (X11; Linux x86_64; rv:8.0a2) Gecko/20110828 Firefox/8.0a2
Mozilla/5.0 (X11; Linux x86_64; rv:9.0a1) Gecko/20110829 Firefox/9.0a1


Last good nightly: 2011-07-29
First bad nightly: 2011-07-30

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cef1817c3b13&tochange=e9be8677a7ae
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
Local track down using Linux x86_64:

The first bad revision is:
changeset:   73525:74a4b995cfe9
user:        L. David Baron <dbaron@dbaron.org>
date:        Thu Jul 28 18:11:51 2011 -0700
summary:     Make hypothetical box calculation consider types that are inline-outside rather than just inline.  (Bug 505706)  r=bzbarsky

http://hg.mozilla.org/mozilla-central/rev/74a4b995cfe9
Blocks: 505706
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
So that <div class="tabs"> has the following styles:

  float: left;
  display: inline-block;
  position: absolute;
  top: -26px;

Note that its 'left' position is auto.  The very next thing is a <div class="padded-main-content"> which is a large left float.

So in our case we treat its hypothetical display as "inline-block", which makes the hypothetical horizontal position be to the right of the left-float, since that's where the placeholder fits.

I'll attach a minimal-ish testcase showing that WebKit is inconsistent here just like in the setting of bug 671491.  But Presto is consistent here... and consistently wrong per spec, as far as I can see.  The testcase uses display:inline to avoid worrying about the inline-block aspect of things; the behavior should be identical, and is in WebKit and Presto.

Requesting tracking for
Component: Layout → Layout: R & A Pos
QA Contact: layout → layout.r-and-a-pos
Attached file Testcase
One other note: one could argue that the "float: left" should make the non-positioned display be considered block instead of inline.... I can't recall what the WG decided on that, if anything.
(In reply to Boris Zbarsky (:bz) from comment #4) 
> One other note: one could argue that the "float: left" should make the
> non-positioned display be considered block instead of inline.... I can't
> recall what the WG decided on that, if anything.

Both the floated and the AP span should be considered block - even if 'inline-block' is specified:
http://www.w3.org/TR/CSS21/visuren.html#dis-pos-flo
Yes, for purposes of their actual layout once the position is determined.

But what I'm talking about is determining position for an absolutely positioned element with an auto offset.  In this case, both 'left' and 'right' are auto (as is the width).  The relevant spec section is http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width which says:

  The static-position containing block is the containing block of a hypothetical box that
  would have been the first box of the element if its specified 'position' value had been
  'static' and its specified 'float' had been 'none'. (Note that due to the rules in
  section 9.7 this hypothetical calculation might require also assuming a different
  computed value for 'display'.) 

  The static position for 'left' is the distance from the left edge of the containing
  block to the left margin edge of a hypothetical box that would have been the first box
  of the element if its 'position' property had been 'static' and 'float' had been
  'none'.

which I guess actually answers my question from comment 4: Gecko's behavior here is correct, and WebKit and Presto are buggy.  I wonder what Trident (IE9) does...  Maybe the spec needs yet another change.  :(
(In reply to Boris Zbarsky (:bz) from comment #6)

> which I guess actually answers my question from comment 4: Gecko's behavior
> here is correct, and WebKit and Presto are buggy.  I wonder what Trident
> (IE9) does...  Maybe the spec needs yet another change.  :(

Can't test IE9, but IE 8 -in standards mode- renders your testcase (attachment 556570 [details]) the same as Gecko.
Presto is known to be wrong, I'm puzzled by WebKit's inconsistent behaviour, though.
How does IE8 render the site in question?
Boris, the testcase here looks good on the trunk nightly mac and windows as well as on Aurora. Is the testcase possibly broken?
Hi, I wrote the HTML/CSS that is being discussed here.

My original CSS that caused this problem was:

.tabs {
    position: absolute;
    top: -26px;
}

This looked fine in Safari and Chrome and various older versions of Firefox I tested against.

Since this bug (682780) was filed, I noticed that the layout was broken under IE8. In particular, the tabs all appeared to the right of the page, although in a row, and not vertically stacked as in https://bug682780.bugzilla.mozilla.org/attachment.cgi?id=556475

To fix the IE8 layout issues, I changed this to:

.tabs {
    position: absolute;
    left: 0px;  /* Breaks without this in IE8. */
    top: -26px;
}

This is the CSS that is now up at http://jig.com

This appears to have fixed the layout problem in the the browsers I have checked it with (recent vanilla Firefox, Chrome, and Safari).

Please let me know if there is anything specifically you'd like me to do to assist with this issue.

Sorry if my hastily written CSS is offensive. I am a long time C++ programmer and I'm quite the noob at this web stuff. Please don't do anything that would make Nick Nguyen beat me again.

Drew
The beatings continue until morale improves.  And morale is very, very bad.  Like you, Drew.
Asa, the testcase is correct.  It's just failed by WebKit and Presto, and those failures are why they didn't have a rendering problem on jig.com.  jig.com was relying on the two tests in the testcase rendering differently, and in particular on the "Where do I appear?" text appearing at the top left of the yellow block in the first test.

drew, adding "left:0px" is exactly what you want here; as far as I can tell the IE8 behavior as well as our new behavior is correct per the CSS2.1 specification.  Thank you for adding that; I recommend changing the comment to reflect the fact that needing the style is not really an IE8 quirk.  And the CSS wasn't offensive by any means.  I just wish browsers were not so buggy, so testing against them actually found CSS bugs.  ;)

I'm leaving this bug open for now until dbaron confirms that my reading of the spec here is correct, on the off chance that I misread it somehow.
Depends on: 671491
(In reply to Boris Zbarsky (:bz) from comment #13)
> I'm leaving this bug open for now until dbaron confirms that my reading of
> the spec here is correct, on the off chance that I misread it somehow.

I presume your question about 'float:left' in comment 4 was about a 'float:left' that's *not* in the testcase -- i.e., float:left on the abs-pos spans.

Assuming then that you're talking about comment 6 -- seems entirely correct, though it's only the second of the two paragraphs you quote that's relevant (the first is only relevant in that it defines a term used for 'direction' property checks).
The question about float:left was in fact about a float:left that's not in the testcase but is present in the site's CSS.

But the real question is whether the assertion in the testcase that the two parts should render identically is correct, and if so whether the correct rendering is the one we have.
Seems right to me, though I certainly can't claim to have implemented the whole spec in my head.
Seems like we should get this into the spec test suite, then, along with the testcase for bug 671491 ..
And probably report it to WebKit too.  Do you want to do that, or should I?
---------------------------------[ Triage Comment ]---------------------------------

Even though we are now more spec compliant I'm going to track this for Firefox 8 in case bug 505706 "breaks" a large portion of the web. We're tracking this bug rather than bug 505706 because it reads cleaner, has a screenshot of possible fallout, and has a pointer to the webkit bug.

Adding dev-doc-needed so we can tell web developers about the change.

Also not sure what to mark this so setting as INVALID, please feel free to change.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Target Milestone: --- → mozilla8
Anyone have a good way to explain this change in English? I'm so far failing to come up with something.
Eric, the change that needs documenting is that the horizontal position of an element that has the following CSS specified:

  display: inline-block or inline-table
  position: absolute or fixed
  left: auto (this is the default value!)
  right: auto (again, the default value)

is now determined the same way as the horizontal position of an element with those position/left/right settings and display:inline.  This changes he horizontal position in various cases, but in most of those we end up compatible with other browsers.  The cases where we end up incompatible are when the inline-block or inline-table has no in-flow content before it in its containing block, because some other browsers handle that case incorrectly.  They always set the horizontal position to 0 in that case, whereas the correct value may be nonzero if there are floats or text-align involved.

Not quite English, but at least a start.  The problem is that the setup here is pretty complicated.  :(
Oh, one more thing.  Should we not have made this a tech evang bug?  Or did jig.com fix their code already?
Boris,

Yup they fixed it, see #c10.

-d
(In reply to Boris Zbarsky (:bz) from comment #23)
> Eric, the change that needs documenting is that the horizontal position of
> an element that has the following CSS specified

Thanks for that explanation. It helps, although yeah, still pretty complicated. I no longer feel foolish for not being able to come up with it myself. :)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: