Allow use of [Exposed] to control interface member visibility

RESOLVED FIXED in Firefox 45

Status

()

Core
DOM
RESOLVED FIXED
4 years ago
3 years ago

People

(Reporter: bz, Assigned: bz)

Tracking

(Blocks: 1 bug)

unspecified
mozilla45
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Right now we have cases in which we use [Exposed] to completely suppress codegen of some members, but we'd like to be able to use it to control visibility too.

I'd like to first fix bug 1011826, while keeping this bug in mind.
Created attachment 8689732 [details] [diff] [review]
part 1.  Pass the set of globals where a member should NOT be exposed to MemberCondition
Attachment #8689732 - Flags: review?(peterv)
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Created attachment 8689733 [details] [diff] [review]
part 2.  Make interface members not be exposed based on their nonExposedGlobals
Attachment #8689733 - Flags: review?(peterv)

Updated

3 years ago
Blocks: 801176
Created attachment 8693600 [details] [diff] [review]
part 2.  Make interface members not be exposed based on their nonExposedGlobals
Attachment #8693600 - Flags: review?(peterv)
Attachment #8689733 - Attachment is obsolete: true
Attachment #8689733 - Flags: review?(peterv)
Comment on attachment 8689732 [details] [diff] [review]
part 1.  Pass the set of globals where a member should NOT be exposed to MemberCondition

Review of attachment 8689732 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bindings/Codegen.py
@@ +2040,5 @@
> +            if workerDesc.workers:
> +                # Just drop all the worker interface names from the
> +                # nonExposureSet, since we know we'll have a mainthread global
> +                # of some sort.
> +                nonExposureSet.difference_update(interface.getWorkerExposureSet())

Could this make nonExposureSet be empty? Might be a good idea to make MemberCondition's __init__ assert None or non-zero length set anyway?
Attachment #8689732 - Flags: review?(peterv) → review+
Comment on attachment 8693600 [details] [diff] [review]
part 2.  Make interface members not be exposed based on their nonExposedGlobals

Review of attachment 8693600 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bindings/BindingUtils.h
@@ +3182,5 @@
> +// Returns true if the given global is of a type whose bit is set in
> +// aNonExposedGlobals.
> +bool
> +IsNonExposedGlobal(JSContext* aCx, JSObject* aGlobal,
> +                   uint32_t aNonExposedGlobals);

Could we just use the declaration in DOMJSClass instead of having it twice?
Attachment #8693600 - Flags: review?(peterv) → review+
> Could this make nonExposureSet be empty?

I could.  In fact, it's supposed to.  The idea is that we shouldn't add any extra checks in this case.

That's why the check in MemberCondition.__init__ is whether nonExposedGlobals is truthy, not whether it's None.  An empty set is falsy, so will lead to self.nonExposedGlobals being set to 0.

I will adjust the MemberCondition documentation to make it clear that empty set is explicitly OK there.

> Could we just use the declaration in DOMJSClass instead of having it twice?

Good catch.  We can.  And the same for CheckAnyPermissions/CheckAllPermissions.  I'll move the docs there.

Comment 8

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/60d26cef51f1
https://hg.mozilla.org/mozilla-central/rev/cfd1e40e0248
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.