841876 - Re-enable flexbox pref (by default) in release builds

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

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]]

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]

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]]

We'll relnote once resolved. Please renominate at that time.

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: fix v1

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 730590 [details] [diff] [review]
fix v1

r=dbaron

Comment 6

[Daniel Holbert [:dholbert]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/845d28ab458e

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/845d28ab458e

Comment 8

[Florian Bender]

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]]

(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]]

(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]]

(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]

(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)]

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]]

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 [e-mail] 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]

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]]

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]

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]]

(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]]

This has been documented long ago.