Closed Bug 778044 Opened 7 years ago Closed 7 years ago

Add a way to pref off interface objects

Categories

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

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

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: nobody → bzbarsky
Putting the actual pref in the IDL would make things more readable, IMO.
How so?  The IDL would be quite readable with:

  [PrefControlled]
  interface Foo {
  };

which would call FooNativeType::PrefEnabled() on the C++ side.
I was talking about the name of the pref...  Of course I may not quite know what this bug was filed for... :-)
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...
(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?
At least in the websocket case the implementation methods actually check the pref in various places.
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
Blocks: 788310
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
https://hg.mozilla.org/mozilla-central/rev/8d5589b88c8b
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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.
(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?
(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.
(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!
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.