Closed Bug 1377587 Opened 7 years ago Closed 7 years ago

Remove __exposedProps__

Categories

(Core :: XPConnect, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox-esr52 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- fixed

People

(Reporter: jorendorff, Assigned: mccr8)

References

(Blocks 2 open bugs)

Details

(Keywords: addon-compat)

Attachments

(2 files)

No description provided.
Looks like the Addon SDK is the last thing using it.
No longer blocks: post-57-api-changes
The SDK is going to be removed in bug 1371065. We don't need to wait until after 57 for this one.
Depends on: 1371065
No longer depends on: post-57-api-changes
This is still used by a lot of extensions: https://dxr.mozilla.org/addons/search?q=__exposedProps__ I'm not opposed to removing it before 57, since it's been deprecated for a long time, but it will definitely break things.
Yeah OK we can wait then. Thanks for checking!
No longer blocks: post-57-api-changes
Priority: -- → P2
Outside of tests, I only see one occurrence of __exposedProps__, in the AddonSDK's PlainTextConsole.
(In reply to Andrew McCreight [:mccr8] from comment #5) > Outside of tests, I only see one occurrence of __exposedProps__, in the > AddonSDK's PlainTextConsole. We can ignore that. The only reason I haven't removed that module yet is I haven't had the time to make sure the sdk/system/globals module isn't tangled up with any of the stuff the devtools or the remaining loader tests use. (And since I'm giving better than even odds to the loader tests using it, the time to untangle it from that test harness.) But the SDK doesn't actually use XOWs, so that shouldn't actually matter at all, unless some SDK or add-on code is doing something obscenely stupid, like passing that console object to content code.
Just for fun, I hacked up a patch to disable exposedProps. It looks like the major work here will be figuring out what to do with the various test failures: https://treeherder.mozilla.org/#/jobs?repo=try&revision=84bc8191923a0902bbb2581febb7eb17d4cbde75&selectedJob=125001854 Tests use it in some places, but when I talked to bholley he said that some of the special powers stuff uses a separate mechanism involving a flag on a compartment, so presumably the uses of exposedProps could be replaced with SpecialPower somehow.
(In reply to Andrew McCreight [:mccr8] from comment #7) > Just for fun, I hacked up a patch to disable exposedProps. It looks like the > major work here will be figuring out what to do with the various test > failures: Hm. It looks like most of these test failures aren't actually related to __exposedProps__, but the fact that attempting to access properties on objects without __exposedProps__ now throws rather than warns. In some of those cases, I suspect we actually have bugs. For instance, here: http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/dom/base/test/test_blockParsing.html#58 we get a failure because attempting to access the "capture" property throws. Which means that the "once" property was probably silently ignored before.
(In reply to Kris Maglione [:kmag] from comment #8) > (In reply to Andrew McCreight [:mccr8] from comment #7) > > Just for fun, I hacked up a patch to disable exposedProps. It looks like the > > major work here will be figuring out what to do with the various test > > failures: > > Hm. It looks like most of these test failures aren't actually related to > __exposedProps__, but the fact that attempting to access properties on > objects without __exposedProps__ now throws rather than warns. Seems like a great first step would be to preserve the warn behavior and disable all the actual __exposedProps__ stuff.
(In reply to Kris Maglione [:kmag] from comment #8) > Hm. It looks like most of these test failures aren't actually related to > __exposedProps__, but the fact that attempting to access properties on > objects without __exposedProps__ now throws rather than warns. Good catch. I was doing that at first, but then I got greedy. Reverting that a bit fixes most of the errors, except for test_cpows.xul which may need to be fixed, and a number of tests that at a glance seem to be explicitly testing __exposedProps__: test_cows.xul, test_exposeInDerived.xul, test_bug1082450.js, test_bug813901.js, test_bug780370.js, test_bug854558.js, test_bug853709.js.
Assignee: nobody → continuation
I fixed some of the failures, but in some cases, the exception appears to be an error corresponding to an NS_ERROR thing. I don't remember exactly what that means or how to fix it. I haven't worked out yet how to fix test_cpows.xul, and I haven't looked at test_cows.xul or test_exposeInDerived.xul.
(In reply to Andrew McCreight [:mccr8] from comment #12) > I fixed some of the failures, but in some cases, the exception appears to be > an error corresponding to an NS_ERROR thing. I don't remember exactly what > that means or how to fix it. Oh right, I need to actually report an error when returning false, like the old code did.
Blocks: 1391954
(In reply to Andrew McCreight [:mccr8] from comment #12) > I haven't worked out yet how to fix test_cpows.xul, and I haven't looked at > test_cows.xul or test_exposeInDerived.xul. CPOW usage should be mostly going away outside of tests, so maybe we can just drop the parts of the tests that rely on __exposedProps__? Just looking at the test code, it's not really clear to me what the purpose of __exposedProps__ is there, anyway... They don't seem to be used in cross-origin contexts.s But either way, I think we probably want to stop allowing privileged CPOWs to be exposed to content scopes at this point.
In the latest iteration of the patch, I've left ExposedPropertiesOnly::deny() alone, and made ExposedPropertiesOnly::check() always act like there is no __exposedProperties__ on the object. This means that it returns false, but does not call into JS_ReportErrorASCII(). The rest of the changes are mostly adjusting tests to ensure that if you access something that has exposedProps on it, it fails instead of succeeds. I've done this by debugging failures, but I should really audit the tests to make sure there aren't any odd cases that we test where we succeed when we should fail. I haven't yet trying to figure out test_cpows.xul, but test_cows.xul is passing locally.
I've now audited every instance of __exposedProperties__ in the code base, to make sure there wasn't some random test that we should be failing that is passing. I actually found a minor bug in test_bug1065185.html, where we were skipping the first iteration of the test (this was actually an instance of a test that should have been failing with the __exposedProps__ removal, but was not). I also went through and cleaned up various comments. After my patch, the only place __exposedProps__ should appear in the code base is in the error message for ReportWrapperDenial which explains that __exposedProps__ is no longer supported. I just need to make sure that a try run is still green.
As Kris pointed out, this does not depend on removing the AddonSDK.
No longer depends on: post-57-api-changes, 1371065
(In reply to Andrew McCreight [:mccr8] from comment #17) > After my patch, the only place __exposedProps__ should appear in the code base is in > the error message for ReportWrapperDenial which explains that > __exposedProps__ is no longer supported. Well, plus various tests that check that __exposedProps__ doesn't do anything.
Blocks: 1397513
I won't land this until we figure out what to do with bug 1392026, but I have the patches finished, so I'll just put them up for review. One thing I'm not sure of is whether this comment still is accurate: "For extra security, we override the traps that allow content to pass an object to chrome, and perform extra security checks on them." For now, I've left it in place. try run: https://treeherder.mozilla.org/#/jobs?repo=try&revision=56020a7c1acf058a29b9e0a94f1ecd990fa31d07
Attachment #8900507 - Flags: review?(gkrizsanits)
Attachment #8905610 - Flags: review?(gkrizsanits)
Comment on attachment 8900507 [details] Bug 1377587, part 1 - Always act like __exposedProps__ is missing. https://reviewboard.mozilla.org/r/171890/#review183224 ::: commit-message-ab308:7 (Diff revision 3) > +The tests that I changed all involve testing the behavior with > +__exposedProps__. I adjusted them to expect it to fail, or to adjust > +the error message they get when they fail. That seemed better than > +deleting them entirely. I'm not quite sure why are you keeping some of these tests. To me it would make sense to just remove all instances of __exposedProps__ from the tree with this patch. Could you elaborate a bit on this why you prefer it this way? I've decided to r+ it anyway, because of the time zone difference I don't want to hold up this patch over something that can be done easily as a followup. One thing we should do before landing is to inform the add-on team about this, because last time I checked with some special flag legacy addons could still work on nightly because of some legacy addon porting work. ::: dom/base/test/chrome/cpows_child.js:108 (Diff revision 3) > + if (is_remote) { > + ok(obj.a == undefined, "__exposedProps__ should not work"); > + } else { > + // The same process test is not run as content, so the field can > + // be accessed even though __exposedProps__ has been removed. > - ok(obj.a == 1, "correct value from parent"); > + ok(obj.a == 1, "correct value from parent"); I wonder if we should just turn this test off for non-e10s... ::: dom/base/test/chrome/cpows_child.js:269 (Diff revision 3) > - ok(obj.wont_die.f == 2, "got reverse CPOW"); > + ok(obj.wont_die.f == undefined, "got reverse CPOW"); > obj.will_die = null; > Components.utils.schedulePreciseGC(function() { > addMessageListener("cpows:lifetime_test_3", (msg) => { > - ok(obj.wont_die.f == 2, "reverse CPOW still works"); > + ok(obj.wont_die.f == undefined, "reverse CPOW still works"); Would this line throw if the object wrapped by the CPOW on the parent side died? If so then it should be mentioned here birefly that we're relying on this fact, if not then maybe we should just remove the test. We should move away from CPOWs completly anyway... ::: js/xpconnect/tests/chrome/test_bug1065185.html:32 (Diff revision 3) > function loaded() { > - switch(++gLoadCount) { > + switch(gLoadCount++) { > case 0: > - doMonitor([]); > + doMonitor([/access to property "a"/i]); > window[0].wrappedJSObject.probe = { a: 2, __exposedProps__: { 'a': 'r' } }; > - is(window[0].eval('probe.a'), 2, "Accessed exposed prop"); > + is(window[0].eval('probe.a'), undefined, "Accessed exposed prop"); Why do we want to keep this test? ::: js/xpconnect/tests/chrome/test_cows.xul:138 (Diff revision 3) > + is(writable.foo, undefined, > + "reading from a write-only exposed prop should return undefined"); Shouldn't we just remove all the exposedProps tests from this file or the entire test file and just add some simple tests for OpaqueWithSilentFailing instead?
Attachment #8900507 - Flags: review?(gkrizsanits) → review+
Comment on attachment 8905610 [details] Bug 1377587, part 2 - Rename ExposedPropertiesOnly to OpaqueWithSilentFailing. https://reviewboard.mozilla.org/r/177406/#review183246 \o/
Attachment #8905610 - Flags: review?(gkrizsanits) → review+
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #23) > I'm not quite sure why are you keeping some of these tests. My basic reasoning was twofold. First, I wanted to make sure that I was actually removing all of the __exposedProps__ behavior that we're testing for, so I figured I'd just go ahead and update the tests to make sure the resulting behavior was reasonable. If I'm going to update the tests anyways, why not land the updated tests? Secondly, I am worried about, perhaps unreasonably, that some kind of bungled merge or whatever could restore the behavior of exposedProps and we wouldn't notice because there are no tests. It certainly doesn't make much sense to leave it in there long term. I can file a followup bug to remove these tests entirely, and then in a month or two somebody can go through and double check that things are really really removed and then delete the tests. Does that sound reasonable? > One thing we should do before landing is to inform the add-on team > about this, because last time I checked with some special flag legacy addons > could still work on nightly because of some legacy addon porting work. Alright, I can figure out who to contact, though at this point I expect a lot of legacy addons are broken anyways due to other changes. > I wonder if we should just turn this test off for non-e10s... I can talk to Bill about that. I also need to figure out if that behavior on non-e10s is expected or not. > Would this line throw if the object wrapped by the CPOW on the parent side > died? If so then it should be mentioned here birefly that we're relying on > this fact, if not then maybe we should just remove the test. That is a little strange. I think with bug 1397513 this will throw whether or not the object is alive, so maybe in the course of investigating that I can figure out if we depend on this returning undefined. > Why do we want to keep this test? See above. > Shouldn't we just remove all the exposedProps tests from this file or the > entire test file and just add some simple tests for OpaqueWithSilentFailing > instead? See above. I'm hoping it won't be too hard to replace OpaqueWithSilentFailing with Opaque and then we won't need any testing.
Keywords: addon-compat
Blocks: 1398938
Pushed by amccreight@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/0a058c19c235 part 1 - Always act like __exposedProps__ is missing. r=krizsa https://hg.mozilla.org/integration/autoland/rev/cdb4e0259eeb part 2 - Rename ExposedPropertiesOnly to OpaqueWithSilentFailing. r=krizsa
(In reply to Andrew McCreight [:mccr8] from comment #25) > (In reply to Gabor Krizsanits [:krizsa :gabor] from comment #23) > It certainly doesn't make much sense to leave it in there long term. I can > file a followup bug to remove these tests entirely, and then in a month or > two somebody can go through and double check that things are really really > removed and then delete the tests. Does that sound reasonable? Right, this makes perfect sense. > > > One thing we should do before landing is to inform the add-on team > > about this, because last time I checked with some special flag legacy addons > > could still work on nightly because of some legacy addon porting work. > > Alright, I can figure out who to contact, though at this point I expect a > lot of legacy addons are broken anyways due to other changes. I guess we should just give Andy a heads-up, just in case. Andy, by removing __exposedProps__ some legacy add-ons will surely break. That would not be an issue since this is 57, but a few weeks ago I heard that there was a special flag to reenable legacy add-ons on nightly for porting reasons. IF that is still the case I thought it's the best if you know about this change. (if that flag is already gone you can surely ignore this...) > > > I wonder if we should just turn this test off for non-e10s... > > I can talk to Bill about that. I also need to figure out if that behavior on > non-e10s is expected or not. Perfect.
Flags: needinfo?(amckay)
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #27) > I guess we should just give Andy a heads-up, just in case. Andy, by removing > __exposedProps__ some legacy add-ons will surely break. That would not be an > issue since this is 57, but a few weeks ago I heard that there was a special > flag to reenable legacy add-ons on nightly for porting reasons. IF that is > still the case I thought it's the best if you know about this change. > (if that flag is already gone you can surely ignore this...) There is no expectation for add-ons on Nightly to keep working. Please don't let that stop or distract you.
Flags: needinfo?(amckay)
Depends on: 1399093
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: