Closed
Bug 841876
Opened 12 years ago
Closed 12 years ago
Re-enable flexbox pref (by default) in release builds
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla22
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 22+ |
People
(Reporter: dholbert, Assigned: dholbert)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [DocArea=CSS])
Attachments
(1 file)
1.02 KB,
patch
|
dbaron
:
review+
|
Details | Diff | Splinter Review |
Filing this bug on reverting the changes in bug 841873, once flexbox is sufficiently stable to ship preffed-on by default in release builds. (Any bugs that should block flexbox from being shipped in release builds should be marked as blocking this bug.)
Assignee | ||
Comment 1•12 years ago
|
||
Some other bugs that we may or may not want to block on: - bug 782441 - bug 783470 - bug 811024 - bug 812687
Comment 2•12 years ago
|
||
For RelMan - I bumped the note that was in 20 back to 22 for now, marking relnote-firefox? so we keep this note on our radar and get it back into the right notes.
relnote-firefox:
--- → ?
Assignee | ||
Updated•12 years ago
|
Comment 3•12 years ago
|
||
We'll relnote once resolved. Please renominate at that time.
relnote-firefox:
? → ---
Assignee | ||
Comment 4•12 years ago
|
||
Assignee: nobody → dholbert
Attachment #730590 -
Flags: review?(dbaron)
Comment on attachment 730590 [details] [diff] [review] fix v1 r=dbaron
Attachment #730590 -
Flags: review?(dbaron) → review+
Assignee | ||
Comment 6•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/845d28ab458e
Flags: in-testsuite-
Comment 7•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/845d28ab458e
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Updated•12 years ago
|
Keywords: dev-doc-needed
Comment 8•12 years ago
|
||
Is flexbox impl stable now? There are still a couple of open bugs left (excluding multi-line flexbox – I guess support for multi-line support can be checked via @supports?) … maybe wait one more release before pushing this through?
Assignee | ||
Comment 9•12 years ago
|
||
(In reply to Florian Bender from comment #8) > Is flexbox impl stable now? I believe so, though testing on nightly/aurora/beta will verify that. > There are still a couple of open bugs left > (excluding multi-line flexbox – I guess support for multi-line support can > be checked via @supports?) … maybe wait one more release before pushing this > through? Do you have any specific bugs that you think should block this? All the bugs that I marked as blocking this one have been resolved, except for bug 851379 which was a very late-breaking spec-change. (which we wouldn't block our release on, & which we can likely backport, per bug 851379 comment 5) There are a several remaining fuzzer bugs that Jesse has filed, which I intend to look into, but their fixes are likely to be minimal and backportable.
Assignee | ||
Comment 10•12 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #9) > (In reply to Florian Bender from comment #8) > > Is flexbox impl stable now? > > I believe so, though testing on nightly/aurora/beta will verify that. (To clarify that: note that flexbox is already on by default in Nightly/Aurora builds, and has been on there for months. This bug's patch only affects behavior in beta & release builds.)
Assignee | ||
Comment 11•12 years ago
|
||
(and yeah, @supports is a good way to test for multi-line support -- or, in script, checking for the presence of someElement.style.flexWrap)
Comment 12•12 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #10) > This bug's patch only affects behavior in beta & release builds.) Just edited Fx 20 for Devs the 2nd time, now that I know that I didn't mess with the prefs and wasn't the only Beta user without flexbox ;). (In reply to Daniel Holbert [:dholbert] from comment #9) > Do you have any specific bugs that you think should block this? Not really, but what about some of the depending and dependant bugs linked in bug 666041? E. g. Bug 799699, Bug 783470 (indicates this is not necessary before shipping, but it's not testable from web code), Bug 811024 (also not testable, but probably not easy to implement), and Bug 734525 (the discussion is hopefully resolved by now).
relnote-firefox:
--- → ?
Comment 13•12 years ago
|
||
Verified as fixed on the 04/03 Aurora (20130403004013), on Windows 7 64bit, Ubuntu 12.10 32bit and Mac OSX 10.7.5 64bit. The pref is true by default, there are no error messages about flex not being known or supported, and pages with flex elements load and render fine.
Status: RESOLVED → VERIFIED
Updated•12 years ago
|
Comment 14•12 years ago
|
||
This bug has been listed as part of the Aurora 22 release notes in either [1], [2], or both. If you find any of the information or wording incorrect in the notes, please email release-mgmt@mozilla.com asap. Thanks! [1] https://www.mozilla.org/en-US/firefox/22.0a2/auroranotes/ [2] https://www.mozilla.org/en-US/mobile/22.0a2/auroranotes/
Comment 15•11 years ago
|
||
I am new to bug reporting on Firefox so please forgive my ignorance - I have Firefox stable version 23 and the `layout.css.flexbox.enabled` option still defaults to false, though I expected it to be true since this bug is marked as fixed for v22. What am I missing?
Assignee | ||
Comment 16•11 years ago
|
||
I just downloaded a fresh Firefox 23.01 build from [1] and I started it up with a fresh profile, and I verified that the pref defaults to "true" for me. So I think all is well. JZ, could you create a new Firefox profile as described at [2], and see if you still see the problem in the fresh profile? [1] https://www.mozilla.org/en-US/products/download.html [2] https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Comment 17•11 years ago
|
||
As you suggested, when I started Firefox using a fresh profile the value was `true`. I don't mind manually adjusting the value in my default profile but I am wondering under what circumstances it would have been stuck on `false` - and for how many other users this is the case - is it possible that I manually toggled it back and forth earlier and for that reason the default value was not changed when I last updated Firefox?
Assignee | ||
Comment 18•11 years ago
|
||
(In reply to JZ from comment #17) > As you suggested, when I started Firefox using a fresh profile the value was > `true`. Good, thanks for trying that -- that's great to hear. > I don't mind manually adjusting the value in my default profile but > I am wondering under what circumstances it would have been stuck on `false` > [...] is it possible that I > manually toggled it back and forth earlier and for that reason the default > value was not changed when I last updated Firefox? It doesn't seem like that would have done it, no. I tried various ways of toggling a boolean pref away from its default and then flipping it back again (either with a double-click, right-click "Toggle", or right-click & "Reset"), sometimes quitting & relaunching between the togglings. In each case, after I'd restored the pref to the default value, the pref was no longer present in my profile's "prefs.js" file. So that tells me that simply turning the pref on and off wouldn't have caused your problem. The only way I know of to get the pref persistently set to "false" would be to manually set it to false, in a browser that has it defaulting to "true". Maybe you did that at some point while running an Aurora or Nightly prerelease build? (perhaps you did so, thinking that you were switching it back to the default value, since that was the default in release builds, but it was *not* the default in Aurora/Nightly builds, which meant the "false" was persistently stored in your prefs.js file) Anyway; given that this is the first I've heard of this, and given that this seems to be fine for profiles that haven't been tweaked, I think we're OK here, and we probably shouldn't clutter up this bug with more discussion. If you figure out more about what happened in your case, and it seems to be a bug, then it'd probably be worth filing a Prefs bug[1] and following up there. though. [1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Preferences
Updated•11 years ago
|
Whiteboard: [DocArea=CSS]
Comment 19•10 years ago
|
||
This has been documented long ago.
Keywords: dev-doc-needed → dev-doc-complete
You need to log in
before you can comment on or make changes to this bug.
Description
•