Last Comment Bug 841876 - Re-enable flexbox pref (by default) in release builds
: Re-enable flexbox pref (by default) in release builds
Status: VERIFIED FIXED
[DocArea=CSS]
: dev-doc-complete
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla22
Assigned To: Daniel Holbert [:dholbert]
:
Mentors:
Depends on: 782441 812822 821775 841827 841847 841873 848539 851379 879540
Blocks: 798592 858305 936100
  Show dependency treegraph
 
Reported: 2013-02-15 12:45 PST by Daniel Holbert [:dholbert]
Modified: 2014-11-30 01:12 PST (History)
16 users (show)
dholbert: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
22+


Attachments
fix v1 (1.02 KB, patch)
2013-03-28 02:22 PDT, Daniel Holbert [:dholbert]
dbaron: review+
Details | Diff | Review

Description Daniel Holbert [:dholbert] 2013-02-15 12:45:44 PST
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.)
Comment 1 Daniel Holbert [:dholbert] 2013-02-15 13:25:11 PST
Some other bugs that we may or may not want to block on:
 - bug 782441
 - bug 783470
 - bug 811024
 - bug 812687
Comment 2 Lukas Blakk [:lsblakk] use ?needinfo 2013-02-21 11:16:53 PST
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.
Comment 3 Alex Keybl [:akeybl] 2013-03-20 12:52:21 PDT
We'll relnote once resolved. Please renominate at that time.
Comment 4 Daniel Holbert [:dholbert] 2013-03-28 02:22:51 PDT
Created attachment 730590 [details] [diff] [review]
fix v1
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2013-03-29 15:13:49 PDT
Comment on attachment 730590 [details] [diff] [review]
fix v1

r=dbaron
Comment 6 Daniel Holbert [:dholbert] 2013-03-29 18:37:54 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/845d28ab458e
Comment 7 Ryan VanderMeulen [:RyanVM] 2013-03-30 17:53:17 PDT
https://hg.mozilla.org/mozilla-central/rev/845d28ab458e
Comment 8 Florian Bender 2013-04-01 12:34:43 PDT
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?
Comment 9 Daniel Holbert [:dholbert] 2013-04-01 12:52:30 PDT
(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.
Comment 10 Daniel Holbert [:dholbert] 2013-04-01 12:54:28 PDT
(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.)
Comment 11 Daniel Holbert [:dholbert] 2013-04-01 12:56:51 PDT
(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 Florian Bender 2013-04-01 15:36:20 PDT

(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).
Comment 13 Ioana (away) 2013-04-04 04:51:56 PDT
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.
Comment 14 Alex Keybl [:akeybl] 2013-04-05 11:59:47 PDT
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 JZ 2013-09-16 09:37:32 PDT
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?
Comment 16 Daniel Holbert [:dholbert] 2013-09-16 10:09:50 PDT
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 JZ 2013-09-16 13:43:51 PDT
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?
Comment 18 Daniel Holbert [:dholbert] 2013-09-16 14:09:08 PDT
(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
Comment 19 Jean-Yves Perrier [:teoli] 2014-11-30 01:12:54 PST
This has been documented long ago.

Note You need to log in before you can comment on or make changes to this bug.