834697 - Enable XBL Scopes

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Bobby Holley (:bholley)]

In bug 821850 I'm landing machinery to run content XBL in a separate scope, but I'm going to land it prefed off. This bug is for flipping that pref.

Comment 1

[Bobby Holley (:bholley)]

To be clear: These deps were inherited from bug 821850. I moved them here because that more accurately reflects the reality in a pref-oriented world.

Comment 2

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a0928943de65

\o/

Comment 3

[Ed Morley [:emorley]]

Unfortunately I had to back this out for win debug mochitest-chrome crashes, eg:
https://tbpl.mozilla.org/php/getParsedLog.php?id=19733797&tree=Mozilla-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=19733802&tree=Mozilla-Inbound

https://hg.mozilla.org/integration/mozilla-inbound/rev/38cb19898d73

Comment 4

[Bobby Holley (:bholley)]

Oh yeah, that's a known bug, actually (bug 834732), but more or less orthogonal to this patch. I'm going to reland with that assertion disabled and re-enable it in bug 834732.

Comment 5

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c7d8ac7fbe29

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/c7d8ac7fbe29

Comment 7

[Jim Jeffery not reading bug-mail 1/2/11]

Probably expected perhaps, but this broke the FlashBlock Addon.  I've filed a bug with the addon dev and flipped the pref back off manually for now.

Comment 8

[Philip Chee]

> Probably expected perhaps, but this broke the FlashBlock Addon.  I've filed a bug with
> the addon dev and flipped the pref back off manually for now.
I'm already CCed to this bug and to bug 821850. 821850 was intended not to break Flashblock. Are you testing with the latest nightly?

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

(In reply to Philip Chee from comment #8)
> > Probably expected perhaps, but this broke the FlashBlock Addon.  I've filed a bug with
> > the addon dev and flipped the pref back off manually for now.
> I'm already CCed to this bug and to bug 821850. 821850 was intended not to
> break Flashblock. Are you testing with the latest nightly?

Yes, well latest m-c hourly based on cset:
https://hg.mozilla.org/mozilla-central/rev/7bd555e2acfa
win7 x64

Comment 10

[Philip Chee]

I see it now:
Sat Feb 16 2013 20:40:32
Error: Error: Permission denied to access property 'length'
Source file: chrome://flashblock/content/flashblock.xml
Line: 21

//From Jesse's XPCNativeWrapper: http://mavra.perilith.com/~luser/content/native.js
function nativeMethod(untrustedObject, methodName)
{
  // happier stack traces and faster multiple calls
  var fun = Components.lookupMethod(untrustedObject, methodName);
  
  return function()
  {
    return fun.apply(untrustedObject, arguments); <---- line 21
  }
}

But I don't see this error in my local SeaMonkey trunk build. I have:
dom.xbl_scopes = true
In both Firefox nightly and my self-build comm-central SeaMonkey.

Firefox:
Vendor=Mozilla
Name=Firefox
Version=21.0a1
BuildID=20130215031040
SourceRepository=http://hg.mozilla.org/mozilla-central
SourceStamp=953b1db7a246 

SeaMonkey:
Vendor=Mozilla
Name=SeaMonkey
Version=2.18a1
BuildID=20130216181125
SourceRepository=read config from: c:\DEV\mozilla-build\hg\mercurial.ini
SourceStamp=31927ec3e589

Comment 11

[Bobby Holley (:bholley)]

(In reply to Philip Chee from comment #10)
> I see it now:
> Sat Feb 16 2013 20:40:32
> Error: Error: Permission denied to access property 'length'
> Source file: chrome://flashblock/content/flashblock.xml
> Line: 21
> 
> //From Jesse's XPCNativeWrapper:
> http://mavra.perilith.com/~luser/content/native.js
> function nativeMethod(untrustedObject, methodName)

As a matter of fact, with xbl scopes enabled, you don't need nativeMethod / lookupMethod at all anymore, because XBL-in-content now runs in a separate compartment and gets Xray vision when accessing content objects (much like chrome code gets). So you can probably just detect whether your XBL is running in a separate compartment, and if so, skip the nativeMethod stuff.

The easiest way to check whether you're running with Xray vision is probably to check XPCNativeWrapper.unwrap(window) != window. Give that a try?

Comment 12

[Philip Chee]

> The easiest way to check whether you're running with Xray vision is probably to check
> XPCNativeWrapper.unwrap(window) != window. Give that a try?
Will do. Thanks.

Comment 13

[bhavana bajaj [:bajaj]]

Not release noting in Fx 21 release notes as this impacts addon-compat & will be covered in an addon blog by :jorgev per https://bugzilla.mozilla.org/show_bug.cgi?id=844783#c6

Please let me know if this needs to be in both the with reasoning on the impact & feel free to renominate it with relnote : ?

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Away: -9/28)]

I have a question, there are some bugs which are blocked by this bug such as bug 208864. Why are they still open? At least, looks like bug 208864 has been fixed.

Comment 15

[Bobby Holley (:bholley)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #14)
> I have a question, there are some bugs which are blocked by this bug such as
> bug 208864. Why are they still open? At least, looks like bug 208864 has
> been fixed.

Many of them could probably be closed, either due to this bug or bug 840488. People just need to go through them and verify that there's nothing more to do.