946322 - Unexpected interfaceMap created in test_interfaces.html when |isXBLScope| is true

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Henry Chang [:hchang]]

http://dxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/general/test_interfaces.html#683

Given |isXBLScope| true and |entry| with no "xbl" property, the expression "entry.xbl === !isXBLScope" is false, which means a interface entry will be treated as "on xbl scope"  if no xbl property specified. Is it the desired behaviour?

Comment 1

[Boris Zbarsky [:bzbarsky]]

If "xbl" is not specified, that means the interface is exposed on all scopes including XBL ones. If it's specified as true, that means the interface is only exposed on XBL scopes.

Comment 2

[Henry Chang [:hchang]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> If "xbl" is not specified, that means the interface is exposed on all scopes
> including XBL ones. If it's specified as true, that means the interface is
> only exposed on XBL scopes.

Thanks for your fast reply! So

xbl: undefined ==> exposed on all scopes
xbl: true      ==> exposed only on xbl scopes
xbl: false     ==> exposed on all scopes but not xbl scope (is this right?)

Actually I am figuring out this mochitest error https://tbpl.mozilla.org/php/getParsedLog.php?id=31438881&tree=Try#error0 and the meaning of xbl scope. According to error log, |window| has no
MozWifiP2pManager but interfaceMap['MozWifiP2pManager'] is true. I suspect it's due to the permission issue (MoziWifiP2pManager requires 'wifi-manage' permission). If my understanding about "xbl: false" is correct, I probably need to add "xbl: false" to the 'MozWifiP2pManager' entry. I will try it out tomorrow. 

Thanks :)

Comment 3

[Bobby Holley (:bholley)]

I don't think there's supposed to be a semantic difference between xbl: false and xbl: undefined. If there is, it's probably a bug.

In general, everything that appears for content should also appear for XBL. But the converse is not true.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> xbl: false     ==> exposed on all scopes but not xbl scope (is this right?)

No, this should be the same as xbl: undefined.

Things that are only enabled in privileged apps should probably just not be added to this list, since they won't appear in web pages and this test is all about making sure we don't over-expose stuff to webpages?

Comment 5

[Henry Chang [:hchang]]

(In reply to Boris Zbarsky [:bz] from comment #4)
> > xbl: false     ==> exposed on all scopes but not xbl scope (is this right?)
> 
> No, this should be the same as xbl: undefined.
> 
> Things that are only enabled in privileged apps should probably just not be
> added to this list, since they won't appear in web pages and this test is
> all about making sure we don't over-expose stuff to webpages?

According to this test: https://tbpl.mozilla.org/php/getParsedLog.php?id=31477013&tree=Try
(the only change is https://hg.mozilla.org/try/rev/2c51bbaeb103 )
"xbl: udefined" did make difference from "xbl: false"

Do you think this is a bug?

Btw, the problems I met are:
0. I created new webidl MozWifiP2pManager which requires 'wifi-manage' permission.
1. manifest.webapp used by mochitest has 'wifi-manage' permission so |window| enumerates MozWifiP2pManager. I have to add 'MozWifiP2pManager' to |interfaceNamesInGlobalScope|
2. However, on the XBL scope, |window| didn't enumerate 'MozWifiP2pManager' (probably due to permission reason). I have to let interfaceMap['MozWifiP2pManager'] be false to get this test PASS.
3. The only way I can let interfaceMap['MozWifiP2pManager'] be false is to explicitly add "xbl: false". Leaving it undefined didn't work.

Could you give me some suggestions?

Thanks!

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ah, hmm.  We seem to use "xbl: false" to mean "not present in XBL scopes because we don't show it via Xrays", indeed.

Bobby, thoughts on comment 5?

Comment 7

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky [:bz] from comment #6)
> Ah, hmm.  We seem to use "xbl: false" to mean "not present in XBL scopes
> because we don't show it via Xrays", indeed.

Ugh, that is so broken. Anything that resolves onto the window for the content script should also resolve onto its XBL scope.

I'm pretty sure that the problem here is that the permission infrastructure doesn't handle XBL scopes. I'll file a bug and whip up a patch.

Comment 8

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.