Firefox 49 fixes sites designed with WebKit in mind, and more

Several recent articles on the Hacks blog explain why web developers should care about cross-browser compatibility and how great web developers achieve it. Web developers have a critical role in making the web work for everyone. And so do browser makers. As of today we’re introducing a number of compatibility features to the Gecko rendering engine, bringing us up to date with the WHATWG Compatibility Standard.

Some notable changes in this release include support for several -webkit- prefixes and WebKit-specific interfaces. These platform features are non-standard, vendor-specific, and quite prevalent.

Non-standard, incompatible CSS breaks websites for user agents designed around standards. When a browser that doesn’t support -webkit- prefixes (such as Firefox 48 and below) visits one of these sites, the web looks broken. This will be the case until those sites update their CSS. That’s why Firefox 49 includes the following changes to accommodate WebKit-specific content:

WebKitCSSMatrix() interface support
-webkit-gradient() support
-webkit- prefix property mappings to their standard equivalents.
Mappings from some -webkit-prefixed (old) flexbox props to -moz-prefixed flexbox props.
Support for the following CSS properties that don’t yet have an unprefixed equivalent:
-webkit-text-fill-color
-webkit-text-stroke-color
-webkit-text-stroke-width
-webkit-text-stroke

(in)Frequently Asked Questions (iFAQ):

Q. So, what does this mean for me?

A. As a user, improved compatibility with sites that were designed for WebKit browsers only, especially on mobile.
okcupid

As a developer, you might want to go back and add unprefixed equivalents to your -webkit-only CSS so we can remove these from the web platform one day in the future (theoretically). Pro Tip: Unprefixed properties always come last.

Q. Did you just break my site?

A. We hope not! But you can toggle this for testing with the following preference:

about:config?filter=layout.css.prefixes.webkit

If there’s a difference (for the worse!), please report bugs to bugzilla.mozilla.org and cc mitaylor@mozilla.com, or report them on webcompat.com.

Q. Should I only use -webkit- prefixes from now on?

A. No, that’s unnecessary and inadvisable. Keep using web standards and keep testing in multiple browsers. If you must use -webkit- prefixes (and there are fewer reasons to do so than ever before), make sure they’re above the unprefixed property in your CSS.

Full disclosure: Mike edits the Compatibility Standard, but there’s work to be done if you’d like to contribute!

Mike works at Mozilla as a Web Compatibility Engineer from Austin, TX.

32 comments

anon

Why not just use the existing moz flag?

September 20th, 2016 at 14:58
1. mitaylor
  
  Unfortunately lots of sites were designed for mobile WebKit browsers only and didn’t include moz prefixes, or even unprefixed variants.
  
  September 20th, 2016 at 16:57
  1. Luke
    
    There are enough sites specifically/accidentally written to only work in Webkit, that it is really necessary to tweak the browser like that? Is that really solving the problem?
    
    September 20th, 2016 at 20:38
    1. mitaylor
      
      It solves the problem for Firefox users, such that they can use those websites now. The only other option is for site developers to go back and update their sites to use standards, and well, that’s a bit like boiling the ocean (unfortunately).
      
      September 21st, 2016 at 10:20
Anand Kumria

Why not put up a hanging banner on nightly / alpha / beta versions of Firefox when it find a document where it has to enable this kind of compatibility mode?

There might be sites which compose together various CSS and it might not be immediately obvious that these (mis)features are being used.

September 20th, 2016 at 17:25
1. Karl Dubost
  
  Because most of the time these sites are made by web developers who are not testing in Firefox anyway, so the banner will be visible only to Firefox users (nightly, alpha and beta as you mentioned). And also because time to time, it’s just a conscious decision from the company to make a business decision on developing only for a specific browser.
  
  September 22nd, 2016 at 13:50
undefined

From the perspective of web developers, this is a bad decision as it encourages the *direct* use of non-standard features and thus leaves even more space for compatibility issues. Here is why:

If firefox doesn’t support -webkit prefix, the developers are forced to consider the compatibility issues and use something like “autoprefixer” to help. All of the experimental features will work as well as they could on different browsers (IE, Chrome, Firefox…)

But if firefox support -webkit prefix and the developers buy it, they will write something like ‘-webkit-feature’ directly and assume it will work on the *major browsers*. The problem is, *major browsers* only includes *webkit based browsers*, what about IE ?

If a developer uses a non-standard feature directly, forcing he/she to consider the potential problems is better than leaving him/her a fragile solution.

September 20th, 2016 at 22:09
1. mitaylor
  
  Edge supports everything that this update supports (and is described by the Compat Standard). IE supports some of it. So that’s all major current browsers.
  
  You have to stop thinking of these as non-standard at this point, just APIs and properties with terrible names (and for the most part, they just map to unprefixed standard CSS). The point isn’t that you should be authoring code with prefixes anymore — this makes it so *old* sites work (or sites where authors are using outdated, or uniformed techniques).
  
  September 21st, 2016 at 10:29
2. Karl Dubost
  
  About “If a developer uses a non-standard feature directly, forcing he/she to consider the potential problems is better than leaving him/her a fragile solution.”
  
  Fair point, but the issue is that in most of these cases, the developer doesn’t want to initially to make the effort for the product to support the specific property. So the end users (who know nothing about why the Web site is broken) are having a bad user experience. There are more users than Web developers. Also for the developer to consider the problem, it means that they have to 1. test in Firefox. 2. Care about the result in Firefox. Not everyone has the same business priority. So we are back on improving the user experience.
  
  September 22nd, 2016 at 13:58
gnz

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.

September 20th, 2016 at 23:56
1. mitaylor
  
  > 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
      
      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
        
        > 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
Šime Vidas

My advice for web developers:
1. start using Autoprefixer;
2. forget about vendor prefixes;
3. let web browsers sort out the remaining web compatibility issues.

September 21st, 2016 at 00:31
Brian Leany

It means that I will no longer use firefox. Two releases in a row, and now everyday sites refuse to load, only on firefox. I need a reliable, stable and most importantly usable browser, and not one that is pushing an agenda.

September 22nd, 2016 at 06:49
1. mitaylor
  
  Respectfully, I think you’re missing the point of this blog post.
  
  September 22nd, 2016 at 07:19
walt

We run a sports message board and most of our members are old firefox users. A few days ago I upgraded to version 49.0. All the rest of our sites work fine, except for the message board. It won’t load text and tool bar menu items. It renders our message board useless. I have done everything possible to figure out the problem. Anyone else that has upgraded has the same experience along with those who use iphones or tablets.

I go back to 48 and I am fine. Plus every other browser such as chrome, opera, IE etc still load our site great with no issues.

I don’t want to use another browser, but may not have to abandon firefox.

September 24th, 2016 at 16:35
1. Dan Callahan
  
  Can you provide a URL so that we can investigate?
  
  September 26th, 2016 at 09:17
2. Justin Crawford
  
  Sounds like a job for https://webcompat.com/ ! Go there, file a bug report, someone will dig in and try to help.
  
  September 26th, 2016 at 09:29
Andy Gongea

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.

September 25th, 2016 at 01:17
Firefox user

Well, at least Mozilla is investing on actually moving the browser forward (even if it means stopping trying to get lazy developers put their act together), instead of spending resources in developing ridiculous Pocket/Hello extension crap.

September 25th, 2016 at 17:19
Nicolas Chevobbe

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 )

September 26th, 2016 at 03:19
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
JB

A lot of hate in the comments here, and I don’t see why.
Of course we should all be pure, and yes we shouldn’t enable slack practices, but reality check people – the majority of developers are not as standards conscious as those who may take umbrage with Mozilla’s decision here.

Mozilla are a company after all, with a vested interest in their market share. If that market share is being damaged by broken web sites, they’ve got the right to make a move on the matter.

September 26th, 2016 at 08:58
Jan-Peter Holmström

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

September 26th, 2016 at 13:30
1. mitaylor
  
  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
John

Well I realized long ago many web developers tend to focus on whatever browser is most popular and that’s what they develop for. Chrome obviously wins out almost everywhere in the world so that’s going to be the browser to use if you want the most web site compatibility. Every other browser must really work to that compatibility. It becomes the standard even if it really isn’t.

October 6th, 2016 at 04:19

Comments are closed for this article.

Hacks

By Mike Taylor, Justin Crawford

About Mike Taylor

About Justin Crawford

32 comments

Firefox 49 fixes sites designed with WebKit in mind, and more

By Mike Taylor, Justin Crawford

About Mike Taylor

About Justin Crawford

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.