mozilla

Revision 390215 of Site Compatibility for Firefox 18

  • Revision slug: Site_Compatibility_for_Firefox_18
  • Revision title: Site Compatibility for Firefox 18
  • Revision id: 390215
  • Created:
  • Creator: kohei.yoshino
  • Is current revision? No
  • Comment

Revision Content

Firefox 18 was released on . While it has been developed to maintain compatibility as much as possible, the new version includes some changes affecting backward compatibility aimed at improving interoperability with the other browsers or following the latest Web standards. Here's the list of such changes — Hope this helps whenever you test your sites or applications.

This article only explains the changes that may affect backward compatibility for Websites. For the other new features and changes, please read the following documents:

CSS

The initial value for min-width and min-height has been changed to auto

The min-width and min-height properties now take the auto keyword as their initial value. For the flexible boxes (flexbox), that has been introduced in Firefox 18 but disabled by default, this auto keyword indicates the minimum item (min-content) in a flexbox. For the other elements, it has no effect as it resolves to 0 as before.

DOM

The MozTouch events were removed in favor of the standard touch events

The experimental, deprecated MozTouch* API (the MozTouchDown, MozTouchMove, MozTouchUp events) has been removed. The W3C standard touch events should be used instead.

To maintain site compatibility, on Windows, Firefox detects whether touch input is supported and disables touch events on incompatible computers. According to a comment in the bug, compatible computers are only a few percent for now. On Android, touch events are enabled by default. On Mac and Linux, touch events are not implemented yet.

Compatibility issues with touch events have been found on many sites. If your site or application has supported touch events for mobile, please test with desktop browsers including Firefox to ensure it works as expected.

The Page Visibility API has been unprefixed

The prefixed mozvisibilitychange event and the mozHidden, mozVisibilityState properties of the Page Visibility API are now deprecated. The unprefixed visibilitychange event and the hidden, visibilityState properties should be used instead.

mozallowfullscreen has been unprefixed

The mozallowfullscreen attribute, that allows content in inline frames (iframe) to be fullscreen, has been unprefixed. The HTML5 allowfullscreen attribute is actually used for YouTube's embedded players.

BlobBuilder has been removed

The deprecated BlobBuilder (MozBlobBuilder) interface has been removed. From now on, use the Blob constructor to create a Blob object.

The localStorage quota has been limited to 5 MB

Previously Web pages with the offline storage enabled can save the own data up to 200 MB. Unfortunately localStorage causes performance issues as it requires synchronous IO. For that reason, the quota has been changed to 5 MB. Also, from now the data in a localStorage will be deleted at the same time user deletes Cookies. You're recommended to use the IndexedDB async API instead.

The value of XHR.getResponseHeader() has been changed to redundant UTF-8 byte characters

Following the latest XMLHttpRequest spec, the getResponseHeader method now returns value expressed in redundant encoding. For example, "" will be "\xE2\x80\xA6".

Event listener objects are no longer accepted as values of on* properties on XMLHttpRequest, FileReader, WebSocket, and EventSource objects (Added on )

With this change, handlers in the form of an object with a handleEvent property, e.g. xhr.onreadystatechange = { handleEvent: function() { ... } }, don't work anymore on XMLHttpRequest, WebSocket, FileReader and EventSource objects, just like the already didn't work on elements, documents, and Window objects. In Firefox (Gecko), such code will be treated as equivalent to xhr.onreadystatechange = null, thus it won't be executed while no error causes. This is a step to comply with standards and improve interoperability; it will be the same behavior as Internet Explorer and Opera. WebKit browsers like Google Chrome still accept such forms.

Note that xhr.onreadystatechange = function() { ... } continues to work, though using addEventListener instead is generally recommended.

JavaScript

The Proxy API has been updated for the new spec

The Direct Proxy of ECMAScript 6 (Harmony) has been implemented. You have to modify your code if you've used the old API.

Function.length no longer counts default parameters (Added on )

The Function.length property, indicating the number of arguments the function expects, has previously included parameters with default values. This was fixed not to include those parameters. So (function (a, b, c = false) {}).length will be 2 instead of 3.

When undefined is passed as an argument, the default parameter will be used if any (added on )

The default parameter is an ECMAScript 6 feature implemented Firefox 15. Previously, when undefined was passed as an argument, the value became undefined. The implementation has been changed to be the default value just like no argument was passed.

Mootools 1.2.x is not compatible with Firefox 18 and newer

Firefox 18 adds the ECMAScript 6 function String.prototype.contains. Unfortunately, old version of Mootools assume there is no such function, and fail to work when it exists. This problem is fixed in Mootools 1.3 and newer.

WebGL

MOZ_EXT_texture_filter_anisotropic has been unprefixed

The deprecated MOZ_EXT_texture_filter_anisotropic has been removed. Use the unprefixed EXT_texture_filter_anisotropic extension instead.

Network

The quality factor in request headers can now have 2 decimal places

Previously Firefox has been clamped the quality factors to one decimal place. The quality factors are numerical values following q=, specified in HTTP request headers like Accept-Language. With such implementation, multiple items may have the same value, thus it has been changed to reflect 2 decimal places to make those values explicit.

The Proxy-Connection header has gone

The Proxy-Connection request header, that has been sent when HTTP proxy is enabled, has been removed. This header was non-standard and hasn't worked properly.

Security

FYI: Preferences to prevent non-SSL contents on SSL pages from loading have been added

2 preferences have been added to block loading contents from non-SSL (http) sites on SSL (https) pages. Scripts, stylesheets, plug-in contents, inline frames, Web fonts and WebSockets can be blocked with security.mixed_content.block_active_content, and other static contents like images, audios and videos can be blocked with security.mixed_content.block_display_content.

Though both are disabled (false) by default for now, such contents won't be loaded if a user enables those preferences. Note that the former preference security.mixed_content.block_active_content will be enabled by default in a future version of Firefox. Webmasters should make sure not to mix non-SSL contents on SSL pages.

Revision Source

<p>Firefox 18 was released on <time datetime="2013-01-08">January 8, 2013</time>. While it has been developed to maintain compatibility as much as possible, the new version includes some changes affecting backward compatibility aimed at improving interoperability with the other browsers or following the latest Web standards. Here's the list of such changes — Hope this helps whenever you test your sites or applications.</p>
<p><strong>This article only explains the changes that may affect backward compatibility for Websites</strong>. For the other new features and changes, please read the following documents:</p>
<ul>
  <li><a href="http://www.mozilla.org/en-US/firefox/18.0/releasenotes/">Firefox 18 Release Notes</a></li>
  <li><a href="/en-US/docs/Mozilla/Firefox/Releases/18">Firefox 18 for developers</a></li>
  <li><a href="https://hacks.mozilla.org/2012/10/aurora-18-hidpi-touch-events/">Aurora 18: HiDPI &amp; Touch Events</a> (Mozilla Hacks)</li>
  <li><a href="https://blog.mozilla.org/addons/2012/12/28/compatibility-for-firefox-18/">Add-on Compatibility for Firefox 18</a> (Add-ons Blog)</li>
</ul>
<section id="sect1">
  <h2 id="CSS">CSS</h2>
  <section id="sect2">
    <h3 id="The_initial_value_for_min-width_and_min-height_has_been_changed_to_auto">The initial value for <code>min-width</code> and <code>min-height</code> has been changed to <code>auto</code></h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=763689">Bug 763689 – New initial value for "min-width" &amp; "min-height": auto</a></li>
    </ul>
    <p>The <a href="/en-US/docs/CSS/min-width"><code>min-width</code></a> and <a href="/en-US/docs/CSS/min-height"><code>min-height</code></a> properties now take the <a href="/en-US/docs/CSS/auto"><code>auto</code></a> keyword as their <a href="/en-US/docs/CSS/initial_value">initial value</a>. For the <a href="/en-US/docs/CSS/Using_CSS_flexible_boxes">flexible boxes (flexbox)</a>, that has been introduced in Firefox 18 but disabled by default, this <code>auto</code> keyword indicates the minimum item (<code>min-content</code>) in a flexbox. For the other elements, it has no effect as it resolves to <code>0</code> as before.</p>
  </section>
</section>
<section id="sect3">
  <h2 id="DOM">DOM</h2>
  <section id="sect4">
    <h3 id="The_MozTouch_events_were_removed_in_favor_of_the_standard_touch_events">The <code>MozTouch</code> events were removed in favor of the standard touch events</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=726615">Bug 726615 – Support W3C touch event instead of MozTouch event</a></li>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=798821">Bug 798821 – Disable touch events on Windows for devices that do not support touch input</a></li>
    </ul>
    <p>The experimental, deprecated <a href="/en-US/docs/DOM/Touch_events_%28Mozilla_experimental%29"><code>MozTouch*</code> API</a> (the <code>MozTouchDown</code>, <code>MozTouchMove</code>, <code>MozTouchUp</code> events) has been removed. The <a href="/en-US/docs/DOM/Touch_events">W3C standard touch events</a> should be used instead.</p>
    <p>To maintain site compatibility, on Windows, Firefox detects whether touch input is supported and disables touch events on incompatible computers. According to a comment in the bug, compatible computers are only a few percent for now. On Android, touch events are enabled by default. On Mac and Linux, touch events are not implemented yet.</p>
    <p><strong><a href="https://bugzilla.mozilla.org/showdependencytree.cgi?id=806805&amp;hide_resolved=1">Compatibility issues with touch events</a> have been found on many sites</strong>. If your site or application has supported touch events for mobile, please test with desktop browsers including Firefox to ensure it works as expected.</p>
  </section>
  <section id="sect5">
    <h3 id="The_Page_Visibility_API_has_been_unprefixed">The Page Visibility API has been unprefixed</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=812086">Bug 812086 – Unprefix Page Visibility API</a></li>
    </ul>
    <p>The prefixed <code>mozvisibilitychange</code> event and the <code>mozHidden</code>, <code>mozVisibilityState</code> properties of the <a href="/en-US/docs/DOM/Using_the_Page_Visibility_API">Page Visibility API</a> are now deprecated. The unprefixed <a href="/en-US/docs/Mozilla_Event_Reference/visibilitychange"><code>visibilitychange</code></a> event and the <a href="/en-US/docs/DOM/Using_the_Page_Visibility_API#document.hidden"><code>hidden</code></a>, <a href="/en-US/docs/DOM/Using_the_Page_Visibility_API#document.visibilityState"><code>visibilityState</code></a> properties should be used instead.</p>
  </section>
  <section id="sect6">
    <h3 id="mozallowfullscreen_has_been_unprefixed"><code>mozallowfullscreen</code> has been unprefixed</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=805301">Bug 805301 – Rename mozallowfullscreen to allowfullscreen</a></li>
    </ul>
    <p>The <code>mozallowfullscreen</code> attribute, that allows content in inline frames (<a href="/en-US/docs/HTML/Element/iframe"><code>iframe</code></a>) to be <a href="/en-US/docs/DOM/Using_fullscreen_mode">fullscreen</a>, has been unprefixed. The HTML5 <code>allowfullscreen</code> attribute is actually used for YouTube's embedded players.</p>
  </section>
  <section id="sect7">
    <h3 id="BlobBuilder_has_been_removed"><code>BlobBuilder</code> has been removed</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=744907">Bug 744907 – Remove BlobBuilder</a></li>
    </ul>
    <p>The deprecated <a href="/en-US/docs/DOM/BlobBuilder"><code>BlobBuilder</code></a> (<code>MozBlobBuilder</code>) interface has been removed. From now on, use the <a href="/en-US/docs/DOM/Blob"><code>Blob</code></a> constructor to create a <code>Blob</code> object.</p>
  </section>
  <section id="sect8">
    <h3 id="The_localStorage_quota_has_been_limited_to_5_MB">The <code>localStorage</code> quota has been limited to 5 MB</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=776416">Bug 776416 – Remove exceptions to 5MB quota rule in localStorage</a></li>
    </ul>
    <p>Previously Web pages with the offline storage enabled can save the own data up to 200 MB. Unfortunately <a href="/en-US/docs/DOM/Storage#localStorage"><code>localStorage</code></a> causes performance issues as it requires synchronous IO. For that reason, the quota has been changed to 5 MB. Also, from now the data in a <code>localStorage</code> will be deleted at the same time user deletes Cookies. You're recommended to use the <a href="/en-US/docs/IndexedDB"><code>IndexedDB</code></a> async API instead.</p>
  </section>
  <section id="sect9">
    <h3 id="The_value_of_XHR.getResponseHeader()_has_been_changed_to_redundant_UTF-8_byte_characters">The value of <code>XHR.getResponseHeader()</code> has been changed to redundant UTF-8 byte characters</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=795867">Bug 795867 – XHR getResponseHeader() should inflate the value</a></li>
    </ul>
    <p>Following the latest <a href="/en-US/docs/DOM/XMLHttpRequest"><code>XMLHttpRequest</code></a> spec, the <a href="/en-US/docs/DOM/XMLHttpRequest#getResponseHeader%28%29"><code>getResponseHeader</code></a> method now returns value expressed in redundant encoding. For example, "<code>…</code>" will be "<code>\xE2\x80\xA6</code>".</p>
  </section>
  <section id="sect10">
    <h3 id="Event_listener_objects_are_no_longer_accepted_as_values_of_on*_properties_on_XMLHttpRequest.2C_FileReader.2C_WebSocket.2C_and_EventSource_objects_(Added_on_Dec_29)">Event listener objects are no longer accepted as values of <code>on*</code> properties on <code>XMLHttpRequest</code>, <code>FileReader</code>, <code>WebSocket</code>, and <code>EventSource</code> objects (Added on <time datetime="2012-12-29">Dec 29</time>)</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=687332">Bug 687332 – Move various onfoo event listeners off of DOM objects and into event listener managers</a></li>
    </ul>
    <p>With this change, handlers in the form of an object with a <code>handleEvent</code> property, e.g. <code>xhr.onreadystatechange = { handleEvent: function() { ... } }</code>, don't work anymore on <code>XMLHttpRequest</code>, <code>WebSocket</code>, <code>FileReader</code> and <code>EventSource</code> objects, just like the already didn't work on elements, documents, and <code>Window</code> objects. In Firefox (Gecko), such code will be treated as equivalent to <code>xhr.onreadystatechange = null</code>, thus it won't be executed while no error causes. This is a step to comply with standards and improve interoperability; it will be the same behavior as Internet Explorer and Opera. WebKit browsers like Google Chrome still accept such forms.</p>
    <p>Note that <code>xhr.onreadystatechange = function() { ... }</code> continues to work, though using <a href="/en-US/docs/DOM/element.addEventListener"><code>addEventListener</code></a> instead is generally recommended.</p>
  </section>
</section>
<section id="sect11">
  <h2 id="JavaScript">JavaScript</h2>
  <section id="sect12">
    <h3 id="The_Proxy_API_has_been_updated_for_the_new_spec">The Proxy API has been updated for the new spec</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=703537">Bug 703537 – Implement Harmony direct proxies</a></li>
    </ul>
    <p>The <a href="/en-US/docs/JavaScript/Reference/Global_Objects/Proxy">Direct Proxy</a> of ECMAScript 6 (Harmony) has been implemented. You have to modify your code if you've used <a href="/en-US/docs/JavaScript/Old_Proxy_API">the old API</a>.</p>
  </section>
  <section id="sect13">
    <h3 id="Function.length_no_longer_counts_default_parameters_(Added_on_Jan_3)"><code>Function.length</code> no longer counts default parameters (Added on <time datetime="2012-01-03">Jan 3</time>)</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=777061">Bug 777061 – Function .length property should not count rest parameters or parameters with default values</a></li>
    </ul>
    <p>The <a href="/en-US/docs/JavaScript/Reference/Global_Objects/Function/length"><code>Function.length</code></a> property, indicating the number of arguments the function expects, has previously included <a href="/en-US/docs/JavaScript/Reference/default_parameters">parameters with default values</a>. This was fixed not to include those parameters. So <code>(function (a, b, c = false) {}).length</code> will be <code>2</code> instead of <code>3</code>.</p>
  </section>
  <section id="sect14">
    <h3 id="When_undefined_is_passed_as_an_argument.2C_the_default_parameter_will_be_used_if_any_(added_on_Jan_3)">When <code>undefined</code> is passed as an argument, the default parameter will be used if any (added on <time datetime="2013-01-03">Jan 3</time>)</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=781422">Bug 781422 – parameters should get defaults whenever they are undefined</a></li>
    </ul>
    <p>The <a href="/en-US/docs/JavaScript/Reference/default_parameters">default parameter</a> is an ECMAScript 6 feature implemented Firefox 15. Previously, when <code>undefined</code> was passed as an argument, the value became <code>undefined</code>. The implementation has been changed to be the default value just like no argument was passed.</p>
    <section id="sect15">
      <h3 id="Mootools_1.2.x_is_not_compatible_with_Firefox_18_and_newer">Mootools 1.2.x is not compatible with Firefox 18 and newer</h3>
      <ul>
        <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=789036">Bug 789036 – Mootools 1.2.x was broken by String.prototype.contains</a></li>
      </ul>
      <p>Firefox 18 adds the ECMAScript 6 function <a href="/en-US/docs/JavaScript/Reference/Global_Objects/String/contains"><code>String.prototype.contains</code></a>. Unfortunately, old version of Mootools assume there is no such function, and fail to work when it exists. This problem is fixed in Mootools 1.3 and newer.</p>
    </section>
  </section>
</section>
<section id="sect16">
  <h2 id="WebGL">WebGL</h2>
  <section id="sect17">
    <h3 id="MOZ_EXT_texture_filter_anisotropic_has_been_unprefixed"><code>MOZ_EXT_texture_filter_anisotropic</code> has been unprefixed</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=790946">Bug 790946 – Remove support for the MOZ_ prefixed EXT_texture_filter_anisotropic ext name</a></li>
    </ul>
    <p>The deprecated <code>MOZ_EXT_texture_filter_anisotropic</code> has been removed. Use the unprefixed <a href="/en-US/docs/WebGL/Using_Extensions#EXT_texture_filter_anisotropic"><code>EXT_texture_filter_anisotropic</code></a> extension instead.</p>
  </section>
</section>
<section id="sect18">
  <h2 id="Network">Network</h2>
  <section id="sect37">
    <h3 id="The_quality_factor_in_request_headers_can_now_have_2_decimal_places">The quality factor in request headers can now have 2 decimal places</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=672448">Bug 672448 – Clamp quality factor ('q') values to 2 decimal places</a></li>
    </ul>
    <p>Previously Firefox has been clamped the quality factors to one decimal place. The quality factors are numerical values following <code>q=</code>, specified in HTTP request headers like <a href="/en-US/docs/HTTP/Content_negotiation#The_Accept-Language.3A_header"><code>Accept-Language</code></a>. With such implementation, multiple items may have the same value, thus it has been changed to reflect 2 decimal places to make those values explicit.</p>
  </section>
  <section id="sect39">
    <h3 id="The_Proxy-Connection_header_has_gone">The <code>Proxy-Connection</code> header has gone</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=570283">Bug 570283 – Stop sending Proxy-Connection</a></li>
    </ul>
    <p>The <code>Proxy-Connection</code> request header, that has been sent when HTTP proxy is enabled, has been removed. This header was non-standard and hasn't worked properly.</p>
  </section>
</section>
<section id="sect42">
  <h2 id="Security">Security</h2>
  <section id="sect44">
    <h3 id="FYI.3A_Preferences_to_prevent_non-SSL_contents_on_SSL_pages_from_loading_have_been_added">FYI: Preferences to prevent non-SSL contents on SSL pages from loading have been added</h3>
    <ul>
      <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=62178">Bug 62178 – implement mechanism to prevent sending insecure requests from a secure context</a></li>
    </ul>
    <p>2 preferences have been added to block loading contents from non-SSL (<code>http</code>) sites on SSL (<code>https</code>) pages. Scripts, stylesheets, plug-in contents, inline frames, <a href="/en-US/docs/CSS/@font-face">Web fonts</a> and <a href="/en-US/docs/WebSockets">WebSockets</a> can be blocked with <code>security.mixed_content.block_active_content</code>, and other static contents like images, <a href="/en-US/docs/HTML/Element/audio">audios</a> and <a href="/en-US/docs/HTML/Element/video">videos</a> can be blocked with <code>security.mixed_content.block_display_content</code>.</p>
    <p>Though both are disabled (<code>false</code>) by default for now, such contents won't be loaded if a user enables those preferences. Note that the former preference <code>security.mixed_content.block_active_content</code> will be <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=834836">enabled by default</a> in a future version of Firefox. Webmasters should make sure not to mix non-SSL contents on SSL pages.</p>
  </section>
</section>
Revert to this revision