627494 - Torbutton Exception in sandbox evaluation., Date hooks not applied: TypeError: (void 0) is undefined

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Valdis Kletnieks]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110119 Firefox/4.0b10pre

Install Torbutton 1.3.1alpha from https://www.torproject.org/dist/torbutton/torbutton-current-alpha.xpi

You'll need to get a copy of tor running locally and point Firefox's SOCKS5 proxy support at it. Step 1 and 3 at https://www.torproject.org/docs/tor-doc-unix.html.en should get you started on that.

Enable it, try to visit https://check.torproject.org.  This will cause several popup windows to show up, all saying:

Torbutton Exception in sandbox evaluation., Date hooks not applied: 
TypeError: (void 0) is undefined

and a corresponding entry on the Javascript error console:

[01-20 19:16:36] Torbutton WARN: Hook exception at:  https://check.torproject.org/, TypeError?: (void 0) is undefined

This is a recent regression, as the Fedora Rawhide version:

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b9) Gecko/20110114 Firefox/4.0b9

functions correctly.

Reproducible: Always

Comment 1

[Valdis Kletnieks]

This is also https://trac.torproject.org/projects/tor/ticket/2421

Comment 2

[Matthias Versen [:Matti]]

It would help if you test mozilla.org binary builds to find the exact regression range. Post the build revision from about:buildconfig from the 2 builds (the last one working, the first broken).

use the comm-central builds from ftp://ftp.mozilla.org/pub/firefox/nightly/

Comment 3

[Valdis Kletnieks]

checked as good:

ftp://ftp.mozilla.org/pub/firefox/nightly/2011/01/2011-01-11-03-mozilla-central/
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110111 Firefox/4.0b10pre ID:20110111030357

Checked as bad:
ftp://ftp.mozilla.org/pub/firefox/nightly/2011/01/2011-01-12-03-mozilla-central/
Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre ID:20110112033217

firefox-4.0b10pre.en-US.linux-x86_64.tar.bz2 in both cases.

Comment 4

[Matthias Versen [:Matti]]

Can you please open about:buildconfig (enter as URL) and copy both build revisions (good and bad) here ?
An example: "Built from http://hg.mozilla.org/mozilla-central/rev/d66366f42efa"
I don't have a linux box and can't check the build IDs of those builds.

Comment 5

[Valdis Kletnieks]

For 20110111 (works):
Built from http://hg.mozilla.org/mozilla-central/rev/4413ed6ba5a5

For 20110112 (doesn't work):
Built from http://hg.mozilla.org/mozilla-central/rev/c0e05d518f57

Comment 6

[Matthias Versen [:Matti]]

Thanks !

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4413ed6ba5a5&tochange=c0e05d518f57

nothing obvious in that checkins for me.
Sorry that I steal your time bz but what could I do to find the change or the reason for this. is hg bisect the only way ?

Comment 7

[Boris Zbarsky [:bzbarsky]]

hg bisect is the only way, though I bet that mrbkap's changes in that range are likely the issue.

Valdis, if I create some builds for you (64-bit Linux, right), would you be willing to test them?

Comment 8

[Valdis Kletnieks]

Yes, x86_64 Linux. I'm certainly willing to test builds if you let me know where they are. (I'd bisect it myself, except I don't have a suitable build system handy at the moment).

Comment 9

[Boris Zbarsky [:bzbarsky]]

OK.  I'll try to spin up some tryserver builds (probably tomorrow) for you to test.  Thanks!

Comment 10

[Boris Zbarsky [:bzbarsky]]

Valdis, can you try the build in http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-446a7a1414e5/try-lnx64/ ?

Comment 11

[Valdis Kletnieks]

Sorry for the delay, I was otherwise busy Sunday...

The build from comment #10 functions correctly.  Hopefully that tells you something useful...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Yes, that narrows the range to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e72631d44b&tochange=c0e05d518f57

Can you try the build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-5c3e767693f6/try-lnx64/ ?

Comment 13

[Valdis Kletnieks]

That last build throws the torbutton errors.

Comment 14

[Boris Zbarsky [:bzbarsky]]

That narrows the range to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e72631d44b&tochange=7a3469118cf3

Try the build at http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-a3ac7b8dfaa0/try-lnx64/ ?

Comment 15

[Valdis Kletnieks]

This one is bad as well. 

Bug #612025 is looking like a prime suspect to me if I'm reading the fromchange, tochange, and about:buildconfig right.  torbutton *does* spend a lot of time worrying about current-window properties, and if it's being handed back a '(void 0)' where it used to be able to introspect a window property, that would explain what I'm seeing.  Of course, that's just a WAG, based on what little I know of torbutton's innards, the discussion on bug #612025, and the fact the other changesets don't look at all related to me. ;)

Comment 16

[Boris Zbarsky [:bzbarsky]]

Ok, so that gets us down to http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c8e72631d44b&tochange=01ea0a38827a

I pushed another changeset to try so we can keep bisecting, but I agree that bug 612025 is starting to sound suspicious.  Blake?

Comment 17

[Boris Zbarsky [:bzbarsky]]

This same Torbutton version works with 3.6, right?

Comment 18

[Valdis Kletnieks]

The publicly released torbutton .xpi apparently works all the way from Firefox 2.0 all the way to 3.7a1 or so.  The current alpha code worked right up till a few days ago. I personally don't have a Firefox older than 4.0b easily handy anymore, but I think with 4M+ downloads, somebody would be yelling if it didn't work on 3.6. ;)

(Following is rambling assuming that bug #612025 is the culprit).

Unfortunately, I can't say who is right or wrong here, only that "it doesn't work the same anymore" - I'm by profession a C hacker, not Javascript/XPI :)  All I know about the torbutton innards is what I read at https://www.torproject.org/torbutton/en/design/index.html.en
and it looks like torbutton intentionally does a lot of the sort of window introspection stuff that bug #612025 is trying to address. Obviously torbutton and Firefox used to be on the same page, they're not now - and it's fast approaching the point where I'll just have to say "Mozilla dudes, meet Mike Perry. Mike, meet the Mozilla dudes" to discuss the intricacies. ;)

Comment 19

[Boris Zbarsky [:bzbarsky]]

Aha!  Yes, that would be a good idea.  Mike, want to talk to Blake about what's going on here?  :)

Comment 20

[Boris Zbarsky [:bzbarsky]]

Assuming that I'm getting the right Mike here, of course...

Comment 21

[Valdis Kletnieks]

Yes, you added the right Mike Perry, as far as I know.  We probably should test a build at commit 51573b855c1b (bug #609287) just to confirm it's #612025, and then let Blake and Mike discuss the gory details.

Comment 22

[Boris Zbarsky [:bzbarsky]]

http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-8856d35b1031/try-lnx64/ is built from changeset 51573b855c1b

Also, http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-6c9738308533/try-lnx64/ is built from changeset 37d585cbcb75 in case the bug is already present in 51573b855c1b

Comment 23

[Valdis Kletnieks]

OK, it's official, 51573b855c1b (bug #609287) tests as "good", so bug #612025 is the culprit.

Boris, thanks for building all those tests, I couldn't have gotten this far without that help.

This is the point where I'd like to step back and let Blake and Mike run with it, as I probably don't have anything else useful to contribute at this point.

Comment 24

[Boris Zbarsky [:bzbarsky]]

Valdis, thanks for testing!  Building those wasn't much of a chore; it's an automated system.  I just had to tell it which changesets to build, and then wait.  ;)

Comment 25

[chris hofmann]

sounds like this should be a blocker [hard?], and be moved from "Extention Compatibility" until we know more.  Does that sound correct?

Comment 26

[Blake Kaplan (:mrbkap) (inactive)]

Well, it seems like what needs to happen is that the torbutton extension needs to pass { wantXrays: false } to the sandbox constructor (see https://developer.mozilla.org/en/Components.utils.Sandbox#Optional_parameter). From my brief browsing of the source code, it appears that it wants to waive Xrays in order to deal directly with the content code's Date object (I don't actually know why it does this though).

Comment 27

[Johnny Stenback (:jst)]

Not blocking on this unless proven that this is something other than the extension that needs updating to the new sandbox API.

Comment 28

[Valdis Kletnieks]

Blake @26:  Reading your link, it's unclear (at least to me) how an extension is supposed to determine whether the wantXrays optional parameter is supported or not.  Will it DTRT if it passes it to the Sandbox constructor on older Firefox builds that don't have it? (Oh, and it wants to deal with the Date because that can be used to determine the user's timezone and typing cadence for fingerprinting - see bug #575230 and http://arstechnica.com/tech-policy/news/2010/02/firm-uses-typing-cadence-to-finger-unauthorized-users.ars ).

Johnny @27, Chris @25: Unless Mike Perry feels otherwise (as the author of the extension), and it's a documented API change, it should probably be a non-blocker under "extension compatibility", unless you guys have a better place to park "this extension needs updating" place-holders?

Comment 29

[chris hofmann]

Product = Firefox  
Component = Extension Compatibility 

is used for "this extension needs updating"

Comment 30

[Boris Zbarsky [:bzbarsky]]

Chris, see comment 26?

Comment 31

[Mike Perry]

Hey guys, thanks for narrowing this down.

I tried the fix in comment #26, and it stops the exception from happening, but it seems to be doing some kind of weird damage to the properties of the actual unwrapped content window object during the sandbox execution. Any properties of window that I attempt to modify in that sandbox are just plain absent to content script.

I just tested an old Firefox 4.0b8 I had laying around and it seems as though this problem exists there too, even when not using the new 4.0b10 wantsXrays flag.

The easiest way to observe the hooks in action is to test:
http://browserspy.dk/screen.php

You don't need Tor for this test. You can set Torbutton to use a local ssh proxy, for instance.

In Firefox 3.x, all of the first 4 are rounded to 50px multiples. Firefox 4.0b8 has them absent, though. Firefox 4.0b10 with the wantXrays: false has them absent as well.

I suppose this is a separate bug, but it is also preventing me from determining if the wantXrays flag is really the fix for this bug... ugh.

Comment 32

[Mike Perry]

Attachment: Torbutton with wantXrays: false

This is torbutton 1.3.1 with the wantXrays: false fix. For some reason, content window properties modified from within the sandbox disappear.

Comment 33

[Mike Perry]

Attachment: This is the diff for the previous attachment.

This is the diff for the previous xpi.

Comment 34

[Jeff Walden [:Waldo]]

chrome/content/jshooks.js has these lines:

  // Gain access to the implict global object (which interestingly claims
  // to be a 'Window' but is not the same class as 'window'...) and 
  // hide XPCNativeWrapper there.
  // This seems no longer necessary in FF2.0.0.13+, and may break FF3?
  with(window.valueOf.call().__proto__) {
      XPCNativeWrapper = function(a) { return a; };
  }

You're relying on Object.prototype.valueOf, called with |undefined| as this by Function.prototype.call, to return the global object.  According to ECMAScript 5th edition, this call now throws a TypeError.  So wrapping the with-block in the try-block of a try-catch to swallow the error (if it happens) should (backwards-compatibly) fix things.

Although (as the comment says) it's not clear whether this bit here is currently necessary anyway, so quite possibly it could just be removed, but your call on that point.

Comment 35

[Teo]

there are 2 attachments. is one of them a fix?

Comment 36

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.