Closed
Bug 814530
Opened 12 years ago
Closed 11 years ago
make @supports automatically be disabled by default on Release and Beta
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
People
(Reporter: heycam, Assigned: heycam)
References
Details
Attachments
(1 file, 1 obsolete file)
1.13 KB,
patch
|
dbaron
:
review+
bajaj
:
approval-mozilla-aurora+
|
Details | Diff | 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-
Assignee | ||
Comment 2•12 years ago
|
||
OK, we can do it with some preprocessing on all.js then.
Updated•12 years ago
|
Attachment #684532 -
Flags: feedback?(bzbarsky)
Assignee | ||
Comment 3•11 years ago
|
||
This uses the new macro available from bug 820148.
Assignee | ||
Updated•11 years ago
|
Attachment #684532 -
Attachment is obsolete: true
Assignee | ||
Comment 4•11 years ago
|
||
tracking? to make sure we do this in time for the next uplift.
tracking-firefox19:
--- → ?
Comment 5•11 years ago
|
||
(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+
Assignee | ||
Comment 7•11 years ago
|
||
PREF_PPFLAGS is used here: https://hg.mozilla.org/mozilla-central/file/tip/modules/libpref/src/Makefile.in#l54
Assignee | ||
Comment 8•11 years ago
|
||
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?
Assignee | ||
Comment 9•11 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/1c8ab97bf848
Whiteboard: [leave open]
(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.)
Assignee | ||
Comment 12•11 years ago
|
||
I had tested this, but I am double checking now.
Assignee | ||
Comment 13•11 years ago
|
||
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.
Assignee | ||
Comment 15•11 years ago
|
||
Bug 820148 landed again.
Updated•11 years ago
|
Attachment #693645 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 17•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/4a251b94509f
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
status-firefox19:
--- → fixed
Resolution: --- → FIXED
Whiteboard: [leave open]
You need to log in
before you can comment on or make changes to this bug.
Description
•