Add a way to pref off interface objects

RESOLVED FIXED in mozilla18

Status

()

RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

Trunk
mozilla18
dev-doc-complete
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

We need this for things like WebSocket.

We have two options here.  We can either make this call nsWebSocket::PrefEnabled(), and generally use that pattern, or put the actual pref in the IDL.

I'm leaning towards the former to not duplicate the pref name and whatnot.
(Assignee)

Updated

6 years ago
Assignee: nobody → bzbarsky

Comment 1

6 years ago
Putting the actual pref in the IDL would make things more readable, IMO.
(Assignee)

Comment 2

6 years ago
How so?  The IDL would be quite readable with:

  [PrefControlled]
  interface Foo {
  };

which would call FooNativeType::PrefEnabled() on the C++ side.

Comment 3

6 years ago
I was talking about the name of the pref...  Of course I may not quite know what this bug was filed for... :-)
(Assignee)

Comment 4

6 years ago
Well, the name of the pref in my proposed setup would be in just one place: the PrefEnabled() impl.

Note that we have such an impl already and would still have it, so putting the pref name in the IDL would mean having it in two places...

Comment 5

6 years ago
(In reply to comment #4)
> Well, the name of the pref in my proposed setup would be in just one place: the
> PrefEnabled() impl.
> 
> Note that we have such an impl already and would still have it, so putting the
> pref name in the IDL would mean having it in two places...

OK, what you're saying sounds good to me!
Could we autogenerate the pref check and have pref mentioned only in the webidl?
(Assignee)

Comment 7

6 years ago
At least in the websocket case the implementation methods actually check the pref in various places.
(Assignee)

Comment 8

6 years ago
Peter, would it make any sense to just store a bool* in the namestruct and if non-null to read what it's pointing to?  Then we could initially point it to some boolean that observes the pref (or null, if not preffed).
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
(Assignee)

Updated

6 years ago
Blocks: 788310
(Assignee)

Comment 9

6 years ago
Created attachment 658331 [details] [diff] [review]
Add a way to pref off Paris binding constructor objects.
Attachment #658331 - Flags: review?(peterv)
(Assignee)

Updated

6 years ago
Keywords: dev-doc-needed
Whiteboard: [need review]
Attachment #658331 - Flags: review?(peterv) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/8d5589b88c8b
Flags: in-testsuite?
Whiteboard: [need review]
Target Milestone: --- → mozilla18
Documented: https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#PrefControlled
Keywords: dev-doc-needed → dev-doc-complete
https://hg.mozilla.org/mozilla-central/rev/8d5589b88c8b
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Comment 13

6 years ago
Is PrefEnabled called every time the value is looked up?
If it keeps returning false, then yes.

If it returns true for a given window, it will normally not get called after that for that window.

Comment 15

6 years ago
(In reply to comment #14)
> If it keeps returning false, then yes.
> 
> If it returns true for a given window, it will normally not get called after
> that for that window.

That's not great, at least for the purpose of writing tests for a preffed-off feature.  Can we fix that easily?
Not without completely rewriting how prototypes are looked up on windows, unfortunately.

That said, the only problem arises if you have a test that takes a preffed-off feature, flips the pref, tests the feature, flips the pref back, and then tries to test things that depend on the feature being preffed off, right?

Comment 17

6 years ago
(In reply to comment #16)
> That said, the only problem arises if you have a test that takes a preffed-off
> feature, flips the pref, tests the feature, flips the pref back, and then tries
> to test things that depend on the feature being preffed off, right?

Oh wait.  Comment 14 was per window (as in, the global window object), right?  In that case, please ignore what I said!
Yes, per inner window.  So as soon as you work with a different window, or navigate to a different page, you will get the pref check again.

Comment 19

6 years ago
(In reply to comment #18)
> Yes, per inner window.  So as soon as you work with a different window, or
> navigate to a different page, you will get the pref check again.

Perfect!
You need to log in before you can comment on or make changes to this bug.