Closed Bug 834697 Opened 11 years ago Closed 11 years ago

Enable XBL Scopes

Categories

(Core :: XPConnect, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla21
Tracking Status
relnote-firefox --- -

People

(Reporter: bholley, Assigned: bholley)

References

(Blocks 1 open bug)

Details

(Keywords: addon-compat, dev-doc-needed)

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.
Blocks: 834699
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.
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.
https://hg.mozilla.org/mozilla-central/rev/c7d8ac7fbe29
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
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.
> 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?
(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
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
(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?
Blocks: 790732
> 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.
Blocks: 842372
Depends on: 846763
Blocks: 844783
No longer blocks: 844783
Depends on: 844783
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 : ?
Depends on: 844211
Blocks: 816071
Depends on: 865947
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.
(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.
You need to log in before you can comment on or make changes to this bug.