The default bug view has changed. See this FAQ.

Status

()

Core
XPConnect
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: bholley, Assigned: bholley)

Tracking

(Blocks: 2 bugs, {addon-compat, dev-doc-needed})

unspecified
mozilla21
x86
Mac OS X
addon-compat, dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox -)

Details

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.
https://hg.mozilla.org/integration/mozilla-inbound/rev/a0928943de65

\o/
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
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/integration/mozilla-inbound/rev/c7d8ac7fbe29
https://hg.mozilla.org/mozilla-central/rev/c7d8ac7fbe29
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Keywords: dev-doc-needed
relnote-firefox: --- → ?

Updated

4 years ago
relnote-firefox: ? → 21+
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

4 years ago
> 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

Comment 10

4 years ago
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?

Updated

4 years ago
Blocks: 790732

Comment 12

4 years ago
> 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
Keywords: addon-compat

Updated

4 years ago
Depends on: 846763
Blocks: 844783
No longer blocks: 844783
Depends on: 844783
Depends on: 845555
Depends on: 843470
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 : ?

Updated

4 years ago
relnote-firefox: 21+ → -
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.