Open Bug 668627 Opened 9 years ago Updated 8 years ago

No comply little man doesn't display possibly due to JSON not well formed error


(Core :: Canvas: 2D, defect)

Not set




(Reporter: joe, Unassigned)




I went to watch No Comply in tonight's nightly, and noticed that apparently the JSON isn't well-formed. This seems unlikely!

Error: not well-formed
Source File:
Line: 1, Column: 1
Source Code: [entire file elided]

Not sure what's going on, but I'm also getting similar "not well-formed" errors on other webpages, on things that look equally innocuous.

Filing on JavaScript engine for want of a better place.
We've always been getting this error for json files; not sure why.

JSONLint ( takes about 9 years to say so, but it reports it as valid.
Hm. Wonder why the little man isn't showing up!
For anyone else looking at this: the failure condition is that you do *not* see cartoon/lego people running around in the city. (It looked like it was working at first because I wasn't sure what was supposed to happen.)

Bisected to:

Hope I got that right: nothing obviously JSON-related in there (although I don't get the JSON error AFAICT). I'll bisect builds now.
Bisected to:

changeset:   69713:41f93610ff0c
user:        Benjamin Peterson <>
date:        Thu May 19 12:49:18 2011 +0200
summary:     Bug 421865 - Handle zero dimensions correctly in canvas GetWidthHeight(). r=joe sr=roc
Assignee: general → nobody
Component: JavaScript Engine → Canvas: 2D
QA Contact: general → canvas.2d
It would be nice if someone could produce an example that wasn't as huge as no comply. (I, for one, don't have the correct video drivers to test it.) Joe reports it happens on other sites. Do these other sites involve canvas?
The "not well formed" message happens on other sites; I don't know whether this not-drawing problem is.

humph/bobby/anyone else - how is the man drawn in No Comply?
The only real difference between how the characters are drawn and the rest of the scene is that the characters come from base64-encoded image dataurl strings and are managed separately for texture uploads.  

I believe Al MacDonald had some standalone tests for it, I'll see if I can dig them up -- if not we can pull it out for testing as it's mostly external except for the rendering itself which could easily be a regular canvas instead.
Now that bug 670442 has been fixed, someone should try again.
Still broken in Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110712 Firefox/8.0a1
Does that build include 5dd671d71bb2?
Doesn't look like it (8753de11b181), I'll try with tomorrow's nightly.
Tested again on 931f06b80727 (which does include 5dd671d71bb2), and it still doesn't work.
It appears that something (perhaps a bug fixed) was ignoring an erroneous undefined width/height that had been supplied to the canvas due to a search&replace typo that possibly left us with a default sized one before.  I created a patch that supplied the appropriate image dimensions to the canvas init and it's now working again.  

The 'not well formed' error was related to not providing a forced-override type for the json -- as well there was another problem in the worker as the xhr overrideMimeType function appears to no longer exist in the worker context?

fixes made are in the last few commits:
Can you get this fix into the copy at
I don't think I have access to the repository, I believe bobby does though so I'll check with him.  Just need to update:


From: and all should be good.
So, is this fixed on your side?
Paul Rouget kindly helped us push the latest version of No comply to the demo network, so the sprite problem is fixed/worked-around.  Unfortunately, that regressed the seizure warning, which we need to put back, but CJ has backups to plumb for those commits.

Whether or not there's an actual browser bug here, depends on whether the overrideMimeType in worker thread context (see comment 13) is expected behavior or a bug.
Excitingly, while doing this, I discovered a nasty 50% regression in framerate on my machine between Firefox 9 and Firefox 10.  Tracking that over in bug 7033981.
So I assume we can close this bug then?
It depends on the answer to the question first posted in comment 13 and reiterated in comment 17.
What MIME type was being sent for the JSON data by the server?
You need to log in before you can comment on or make changes to this bug.