Last Comment Bug 682780 - jig.com looks different in aurora vs. firefox
: jig.com looks different in aurora vs. firefox
Status: RESOLVED INVALID
: dev-doc-needed
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: unspecified
: All All
: -- normal (vote)
: mozilla8
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
https://www.jig.com/
Depends on: 671491
Blocks: 505706
  Show dependency treegraph
 
Reported: 2011-08-28 22:28 PDT by Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)
Modified: 2013-12-27 14:29 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
+
unaffected


Attachments
Screenshot of jig.com (29.38 KB, image/jpeg)
2011-08-28 22:28 PDT, Dave Dash [:davedash, :dd] (assign all bugs to mbrandt)
no flags Details
Testcase (698 bytes, text/html)
2011-08-29 09:08 PDT, Boris Zbarsky [:bz]
no flags Details
the look of abject terror. (77.78 KB, image/png)
2011-09-01 15:21 PDT, Nick Nguyen
no flags Details

Description Dave Dash [:davedash, :dd] (assign all bugs to mbrandt) 2011-08-28 22:28:00 PDT
Created attachment 556475 [details]
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.
Comment 1 Thomas Ahlblom 2011-08-29 06:17:14 PDT
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
Comment 2 Thomas Ahlblom 2011-08-29 08:01:53 PDT
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
Comment 3 Boris Zbarsky [:bz] 2011-08-29 09:07:06 PDT
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
Comment 4 Boris Zbarsky [:bz] 2011-08-29 09:08:10 PDT
Created attachment 556570 [details]
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.
Comment 5 philippe (part-time) 2011-08-29 18:37:29 PDT
(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
Comment 6 Boris Zbarsky [:bz] 2011-08-29 19:08:54 PDT
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.  :(
Comment 7 philippe (part-time) 2011-08-29 22:16:36 PDT
(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.
Comment 8 Boris Zbarsky [:bz] 2011-08-29 22:54:10 PDT
How does IE8 render the site in question?
Comment 9 Asa Dotzler [:asa] 2011-09-01 14:54:13 PDT
Boris, the testcase here looks good on the trunk nightly mac and windows as well as on Aurora. Is the testcase possibly broken?
Comment 10 Drew Olbrich 2011-09-01 15:13:58 PDT
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
Comment 11 Nick Nguyen 2011-09-01 15:16:54 PDT
The beatings continue until morale improves.  And morale is very, very bad.  Like you, Drew.
Comment 12 Nick Nguyen 2011-09-01 15:21:09 PDT
Created attachment 557670 [details]
the look of abject terror.
Comment 13 Boris Zbarsky [:bz] 2011-09-01 15:32:25 PDT
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.
Comment 14 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-09-01 15:45:39 PDT
(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).
Comment 15 Boris Zbarsky [:bz] 2011-09-01 16:57:42 PDT
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.
Comment 16 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-09-01 17:05:50 PDT
Seems right to me, though I certainly can't claim to have implemented the whole spec in my head.
Comment 17 Boris Zbarsky [:bz] 2011-09-01 18:01:40 PDT
Seems like we should get this into the spec test suite, then, along with the testcase for bug 671491 ..
Comment 18 Boris Zbarsky [:bz] 2011-09-01 18:02:05 PDT
And probably report it to WebKit too.  Do you want to do that, or should I?
Comment 19 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2011-09-02 08:58:55 PDT
Could you?
Comment 20 Boris Zbarsky [:bz] 2011-09-02 09:48:34 PDT
Filed https://bugs.webkit.org/show_bug.cgi?id=67491
Comment 21 christian 2011-10-25 21:38:28 PDT
---------------------------------[ 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.
Comment 22 Eric Shepherd [:sheppy] 2011-11-02 10:25:18 PDT
Anyone have a good way to explain this change in English? I'm so far failing to come up with something.
Comment 23 Boris Zbarsky [:bz] 2011-11-02 10:44:18 PDT
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.  :(
Comment 24 Boris Zbarsky [:bz] 2011-11-02 10:44:52 PDT
Oh, one more thing.  Should we not have made this a tech evang bug?  Or did jig.com fix their code already?
Comment 25 Dave Dash [:davedash, :dd] (assign all bugs to mbrandt) 2011-11-02 10:50:16 PDT
Boris,

Yup they fixed it, see #c10.

-d
Comment 26 Eric Shepherd [:sheppy] 2011-11-02 10:51:50 PDT
(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. :)

Note You need to log in before you can comment on or make changes to this bug.