Q: What does this mean for me?

A: It means that Mozilla breaks its promise of defending web standards and opts for bowing down to webkit. It’s a sad day for you, as Firefox will no longer uphold the mission it had and which made you donate money to Mozilla.

It means you should no longer feel compelled to call Mozilla “champions of the internet, helping to keep it healthy and open”. It means Firefox has given up.

1. mitaylor@mozilla.com

   > It means that Mozilla breaks its promise of defending web standards

   No, quite the opposite. We took the APIs and properties that Apple never specced and turn them into a standard, like it or not.

   > opts for bowing down to webkit

   This doesn’t make sense to me. We’re enabling previously broken content for Firefox users. If you go re-read the Mozilla Manifesto I think you’ll see how that fits. Users > Theoretical Purity.

   September 21st, 2016 at 10:26
   1. Maxime Thiers

      Like it or not, a -webkit- prefixed CSS feature is not and will not turned into an open standard. With Mozilla’s move, it will become a standard de facto in place of the existing equivalent one.
      The web just made an 18 years leap back, thank you Mozilla :(

      The “Users > Theoretical Purity” b****** once lead to “best viewed with 1024×768” websites, just s/1024×768/webkit/

      Sometimes history repeats itself, now it falters…

      [edited for language]

      September 21st, 2016 at 12:53
      1. mitaylor@mozilla.com

         Yep, this is the de-facto standard: https://compat.spec.whatwg.org/

         September 22nd, 2016 at 09:24
         1. nevermind

            In the days when IE was so prominent did we just take their broken web engine implementation and make it a standard?

            If the new way of making standards is to capsize on non-standards and stamp them with a ‘standard’ etiquette I think we may as well call defeat.

            Don’t get me wrong, I still appreciate Mozilla’s effort for the web, but these kind of news feel more like a step backwards than forward.

            September 22nd, 2016 at 15:09

         2. mitaylor@mozilla.com

            > In the days when IE was so prominent did we just take their broken web engine implementation and make it a standard?

            That happened in ways we forget about today. XMLHttpRequest was invented by Microsoft and Mozilla, Opera and Apple implemented it before the W3C’s spec existed. Obviously that’s not the ideal way for standards to come about, but the web is a frequently a pile of technologies that aren’t always implemented in the way we’d all like after the fact.

            I’m not sure we need to call defeat. The web is alive and progress is being made by all major vendors in standards bodies. You might consider this just declaring bankruptcy on vendor prefixes (which most would agree were a bad idea?) — that’s how I see it.

            September 22nd, 2016 at 15:38

         3. Karl Dubost

            About: “In the days when IE was so prominent did we just take their broken web engine implementation and make it a standard?”

            Yes (Not only IE btw). None of the browsers have been perfect. It’s why we are able to read invalid HTML. So let’s see. Mike already cited XMLHttpRequest

            * XMLHttpRequest
            * innerText (then implemented by Safari (WebKit), then imported by Chrome (Blink) and we had to do it after resisting and contacting for years and having some sites breaking for users). innerText came in Firefox last year. Thanks to Robert O’Callahan work. The standard property is textContent.
            * zoom property. Created by IE, implemented in WebKit and Blink. Still not in Gecko (Firefox). Breaking some sites.
            * insertAdjacentHTML() supported by all browsers and created by IE.
            * the list goes on.

            September 22nd, 2016 at 16:35

      2. JakoD

         Like it or not, a -webkit- prefixed CSS feature is not and will not turned into an open standard. With Mozilla’s move, it will become a standard de facto in place of the existing equivalent one.
         The web just made an 18 years leap back, thank you Mozilla :(

         The “Users > Theoretical Purity” b****** once lead to “best viewed with 1024×768” websites, just s/1024×768/webkit/

         Sometimes history repeats itself, now it falters…

         Sorry, but I can’t agree here. From time to time I stumble across a site simply not working correctly in Firefox. That ranges from things like single sections of the site not being usable due to various issues up to the whole site being a mess, making it impossible for the average user to even find contact information to complain about that bug (more on that later). All just because a site was “developed only with/for Chrome”.
         So the average user will do one of two things:
         – either leave the site, moving on to a competitor’s site
         – or leave Firefox, moving on to Chrome (or other browsers based on it) – not what we want, is it?

         What will rarely happen is, that the bug gets fixed, because really … who reports it? Even if it’s a small one, it costs time to report, maybe there are further questions, because the average user isn’t trained to report bugs properly (a problem I often encounter with new customers or with new employes of larger existing customers of our company). People simply leave a site without comment for less, e.g. too long load times.
         And finally if the bug was reported it sometimes still costs money to fix it, which some site owners don’t want to pay. Fixing a site to work with another browser can sound like a huge task to business people, even if in reality it’s just unprefixing some properties and putting autoprefixer in the build chain (aka takes less than 5 minutes).
         Considering all that and that finally even Apple agreed on putting experimental features behind prefixes is a bad thing to do and announced they won’t do that anymore (https://webkit.org/blog/6131/updating-our-prefixing-policy/), I think the move to support existing, commonly (mis)used webkit prefixes in Firefox is ok – maybe some form of notification in the console (or if really necessary somewhere in Firefox dev edition) would be find, so that the lonely newbie dev, being the first to use Firefox for development on that code, can stumble across it, apply the less than 5 minute fix, while the site still (and up until that time) works all the time for average people.

         September 25th, 2016 at 01:58

I think this is wrong. This is turning Firefox into IE.
So, it doesn’t matter if the developer/designer doesn’t test and write websites for all browsers, Firefox will render it properly anyway.

Hi,

Is there a way to tell Firefox to ignore the -webkit-* properties ?
One of our app, which was working in Firefox 48 is now unusable because `display: -webkit-box` is interpreted, even if we have the standard `display: flex` rule declared in the same selector :

“`
.x-layout-box {
display: flex;
display: -webkit-box;
}
“`

The devtools is indeed showing me that the `display: flex` is ignored ( it is crossed ).

I know -webkit-box is pretty old, but we have to keep them for old iPad our user uses.

I would be very grateful if there were some meta tag I can use to prevent firefox to use those -webkit-* prefixes ( and even more if this bug could be fixed )

1. Justin Crawford

   > The devtools is indeed showing me that the `display: flex` is ignored ( it is crossed ).

   If you put the -webkit-box declaration above the flex declaration, does the issue still appear?

   There is a setting to toggle this behavior in Firefox. Put this in your URL bar, and change the setting to false: about:config?filter=layout.css.prefixes.webkit

   September 26th, 2016 at 09:27
   1. Daniel Holbert

      Nicolas: As Justin suggested, you should swap the ordering of those “display” declarations — you want to put the modern display value *last* (so that it’s the one that “wins”, instead of the old/crufty/emulated-but-maybe-imperfect “-webkit-box” display mode).

      Hopefully that will fix things on your site.

      Still — ideally this Firefox change should’ve made things strictly better. If you have an example public URL of a broken page, please submit it at http://webcompat.com/ or paste a URL here so we can take a look and see why things aren’t Just Working.

      September 26th, 2016 at 14:59

September 24, 2016 an automatic update was done to Firefox version 49.0.1 on my PC. I use Windows Vista Home Premium. After the update the Windows Toolbar and Taskbar disappeared in Firefox and in all the rest Windows applications except in the desktop. I did everything possible to figure out the problem but had to give up. I did a system restore to a previous date and then could not get Firefox to work. I had to undo the system restore and then uninstall Firefox 49. I now made a new system restore and then installed Firefox 48. The Toolbar and Taskbar are back but I have some inaccuracies with the Swedish language. When I right-click I get text in English. The update in Firefox I had to mark; “Never check for updates”. This is not good
J-P Holmström in Sweden

1. mitaylor@mozilla.com

   Hey Jan-Peter!

   This sounds like a bug, but unrelated to the changes in this blog post. Can you file a but at https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Untriaged — Thanks!

   September 26th, 2016 at 14:42