Closed
Bug 1102374
Opened 9 years ago
Closed 9 years ago
Enable display:contents by default in non-RELEASE builds
Categories
(Core :: Layout, defect, P5)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla37
People
(Reporter: MatsPalmgren_bugz, Assigned: MatsPalmgren_bugz)
References
Details
(Keywords: dev-doc-complete)
Attachments
(1 file)
3.09 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Updated•9 years ago
|
Priority: -- → P5
Assignee | ||
Comment 1•9 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=e208c85abbe4
Comment 3•9 years ago
|
||
I think this should probably wait until after merge day (this Friday, November 28), so that you have time to react to any fuzzing bugs that turn up. (Also, once it lands, please point Jesse at it.)
Comment 4•9 years ago
|
||
(Any particular reason for the RELEASE_BUILD ifdefs, though? It's certainly not what I expected from the summary of the bug.)
Assignee | ||
Comment 5•9 years ago
|
||
(In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #3) > I think this should probably wait until after merge day Sure. (In reply to David Baron [:dbaron] (UTC-8) (needinfo? for questions) from comment #4) > (Any particular reason for the RELEASE_BUILD ifdefs, though? It's certainly > not what I expected from the summary of the bug.) Re-summarized. I'll file a separate bug later to remove the #ifdef.
Summary: Enable display:contents by default → Enable display:contents by default in non-RELEASE builds
Comment 6•9 years ago
|
||
Comment on attachment 8527753 [details] [diff] [review] Enable display:contents by default in non-release builds. So what's the plan for keeping the tests passing when aurora merges to beta? (That said, why not just pref it on at the beginning of the cycle with the intent to actually ship it?)
Assignee | ||
Comment 7•9 years ago
|
||
> So what's the plan for keeping the tests passing when aurora merges to beta? The updated tests pass also with the pref value being false, if that's what you're asking. > (That said, why not just pref it on at the beginning of the cycle with the > intent to actually ship it?) It seems safer to remove the #ifdef when we think it's ready to ship. Like we have done for numerous other new features. http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#152 http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#420 http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#572 etc.
Comment 8•9 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #7) > It seems safer to remove the #ifdef when we think it's ready to ship. > Like we have done for numerous other new features. > http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#152 > http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#420 > http://mxr.mozilla.org/mozilla-central/source/modules/libpref/init/all.js#572 > etc. Why do you think it's not ready to ship?
Assignee | ||
Comment 9•9 years ago
|
||
I didn't imply it's not ready to ship. I have no opinion on that since there isn't any data to make such a decision. Getting that data is the purpose of this patch. The intent is to make a decision, based on data, near the end of the 37-cycle whether we want to enable it by default in v37. (Jet filed bug 1105369 on that.) "#ifdef RELEASE_BUILD" seems to be the established procedure to enable fuzz testing on new features while having a safety pin to avoid shipping something unintentionally. I don't see why we should treat this feature differently.
Comment 10•9 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #9) > "#ifdef RELEASE_BUILD" seems to be the established procedure to > enable fuzz testing on new features while having a safety pin to > avoid shipping something unintentionally. I don't see why we > should treat this feature differently. I think it's normally for features that we know aren't ready to ship. That said, given the desire to have this fuzzed, I'm ok with making an exception here, but we should actually make sure to come back and enable it.
Updated•9 years ago
|
Attachment #8527753 -
Flags: review?(dbaron) → review+
Updated•9 years ago
|
Keywords: dev-doc-needed
Assignee | ||
Comment 11•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/265e01c7ff55
Flags: in-testsuite-
Comment 12•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/265e01c7ff55
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Comment 13•9 years ago
|
||
Added a comment in the compat table of https://developer.mozilla.org/en-US/docs/Web/CSS/display#Browser_compatibility and in https://developer.mozilla.org/en-US/Firefox/Releases/37#CSS
Keywords: dev-doc-needed → dev-doc-complete
Updated•8 years ago
|
Flags: qe-verify-
You need to log in
before you can comment on or make changes to this bug.
Description
•