825473 - Doodle shows full sprite sheets instead of proper content

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Joe Drew (not getting mail)]

Filed optimistically in Style System, but let's wait for the regression window.

Recently in Nightly, Doodle has started misbehaving very badly - the sprite sheets render in their entirety, leading to incredibly garbled rendering <http://i.imgur.com/EKgAw.png>.

In Aurora, this continues to work fine.

See an example of such a broken doodle in the URL.

Comment 1

[Matthias Versen [:Matti]]

There are 2 regression:

1) The page doesn't display at all
Last good nightly: 2012-12-22
First bad nightly: 2012-12-23

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bf26f61a0748&tochan
ge=84320dffec6e

2) The page us rendered garbled (previous build renders empty)
Last good nightly: 2012-12-24
First bad nightly: 2012-12-25

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d348dbf1dab4&tochan
ge=dc2abccc2adb

Comment 2

[Daniel Holbert [:dholbert]]

It's sort of unclear whether (2) is truly a "regression", since it took us from "no display" to "some (albeit broken) display" :)  But, setting that aside, that second range includes some image-related changes from Seth --> CC'ing him.

Comment 3

[Daniel Holbert [:dholbert]]

(Also: For the record, I can reproduce the "page page doesn't display at all" rendering in a 12-23 build, and the garbled full-sprite-sheet rendering in the latest nightly build, on my 64-bit linux laptop. --> Updating platform fields)

Comment 4

[Daniel Holbert [:dholbert]]

From local |hg bisect| -- the cset that made us go from rendering 1 (blank) to rendering 2 (full sprite sheets) was https://hg.mozilla.org/mozilla-central/rev/5d900d13b2cf , for bug 811701.

Comment 5

[Daniel Holbert [:dholbert]]

As a shot in the dark, I'm going to suspect https://hg.mozilla.org/mozilla-central/rev/a6d996266cfe (for bug 821606) as the cset that caused behavior-change #1, due to its connection to the cset that caused behavior-change #2.

That bug is marked as having caused bug 825138, an incompatibility w/ optimizely.  Doodle also uses optimizely.  Perhaps that's what's going on here?

Comment 6

[Daniel Holbert [:dholbert]]

Yup, this is from optimizely scripts.

Workaround (which demonstrates that it's an optimizely-related issue):
  a) Install NoScript from http://noscript.net/getit#devel
  b) Click the NoScript toolbar button & pick "Allow Scripts Globally (dangerous)"
      (so as not to break the web)
  c) Visit the doodle URL given in this bug's URL field.
      (You should see the bug being reproduced -- full image sprites will be visible)
  d) Click the NoScript toolbar button and pick "Mark optimizely.com as untrusted"
      (page reloads automatically --> now the bug is fixed!)

Comment 7

[Daniel Holbert [:dholbert]]

So this is likely a duplicate of (or at least related to) bug 824301.  Marking as "depends-on" for now.

Comment 8

[Matthias Versen [:Matti]]

The first bad revision is:
changeset:   116805:a6d996266cfe
user:        Peter Van der Beken <[e-mail]>
date:        Thu Nov 22 12:09:57 2012 +0100
summary:     Fix for bug 821606 (Turn on WebIDL bindings for Element and HTMLEle
ment). r=bz.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Well, sort of.  That bug is an evangelism bug; so is this one.

Basically, the optimizely scripts are horribly broken and any site using both optimizely and any other scripts will be busted.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, and the optimizely folks are planning to look at this once their engineers get back from their vacations.  Whenever that is.

If we hear nothing by the 3rd, I plan to start contacting sites and telling them to stop using optimizely or something.

Comment 12

[Alex Keybl [:akeybl]]

(In reply to Boris Zbarsky (:bz) from comment #10)
> Oh, and the optimizely folks are planning to look at this once their
> engineers get back from their vacations.  Whenever that is.
> 
> If we hear nothing by the 3rd, I plan to start contacting sites and telling
> them to stop using optimizely or something.

I don't think TE is going to do the trick, given past experience. We either need to fix on the optimizely side, or figure out an in-product fix. A quick spotcheck of a few of their "3000 happy customers" shows that sites are loading from cdn.optimizely.com, whether or not they're currently A/B testing.

Thankfully if the optimizely folks fix on their end, I don't think anybody is using local copies.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Optimizely has fixed on their end, but apparently their customers have to make an effort to update.  Or something.  Trying to get more detail on that.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Doodle has been updated to the new optimizely code.