Closed Bug 814530 Opened 10 years ago Closed 10 years ago

make @supports automatically be disabled by default on Release and Beta

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox19 + fixed

People

(Reporter: heycam, Assigned: heycam)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch patch (obsolete) — Splinter Review
I think it would be good for the pref controlling whether @supports is enabled to have a third state (the default) which means "false in Release, Beta or ESR, true otherwise".  Here's a patch that does that.  WDYT?  If it's a good approach maybe we can apply it to the other experimental features behind prefs.

I check both boolean and int values because some people may have already explicitly set the pref to true in their profiles.
Attachment #684532 - Flags: review?(dbaron)
Attachment #684532 - Flags: feedback?(bzbarsky)
Comment on attachment 684532 [details] [diff] [review]
patch

I'd rather do this sort of thing at build-time rather than run-time.

I'm also not sure it'll do the right thing for things like Linux-distro builds.
Attachment #684532 - Flags: review?(dbaron) → review-
OK, we can do it with some preprocessing on all.js then.
Attachment #684532 - Flags: feedback?(bzbarsky)
Depends on: 820148
Attached patch patch v2Splinter Review
This uses the new macro available from bug 820148.
Assignee: nobody → cam
Status: NEW → ASSIGNED
Attachment #693645 - Flags: review?(dbaron)
Attachment #684532 - Attachment is obsolete: true
tracking? to make sure we do this in time for the next uplift.
(In reply to Cameron McCormack (:heycam) from comment #4)
> tracking? to make sure we do this in time for the next uplift.

We just approved bug 820148. Please make sure to put a reminder on your calendar as opposed to waiting for a ping from us :)
Comment on attachment 693645 [details] [diff] [review]
patch v2

r=dbaron

Though I admit to not understanding how the addition to PREF_PPFLAGS in build/Makefile.in in https://hg.mozilla.org/mozilla-central/rev/7286dac15291 affects the preprocessing of all.js...
Attachment #693645 - Flags: review?(dbaron) → review+
Comment on attachment 693645 [details] [diff] [review]
patch v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A
User impact if declined: feature will be enabled on Beta too soon
Testing completed (on m-c, etc.): none, just a pref change that we've done before
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch: N/A
Attachment #693645 - Flags: approval-mozilla-aurora?
(In reply to Cameron McCormack (:heycam) from comment #7)
> PREF_PPFLAGS is used here:
> https://hg.mozilla.org/mozilla-central/file/tip/modules/libpref/src/Makefile.
> in#l54

Yeah, but I don't see why setting something in build/Makefile.in would have any effects beyond build/Makefile.in (as opposed to doing something in config.mk or rules.mk, which gets included in every makefile).
(If you've tested that it works, I'll believe you, but I'm suspicious.)
I had tested this, but I am double checking now.
You are right, it doesn't work.  I must have switched makefile and not re-tested properly.
ok, probably best to continue this discussion in bug 820148.
Bug 820148 landed again.
Attachment #693645 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/4a251b94509f
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
You need to log in before you can comment on or make changes to this bug.