Revision Content

Firefox 28 was released on March 18, 2014. 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:

Make sure the deep argument is specified for cloneNode and importNode

The {{ domxref("Node.cloneNode") }} and {{ domxref("document.importNode") }} methods take the boolean deep argument. It's optional in the DOM4 specification, and if omitted, these methods acted as if the value of deep was true. But this behavior has been changed in the latest spec, and if omitted, the methods will act as if the value was false. The implementation has been changed in Firefox 29. Though the argument is still optional, Firefox now warns developers in console not to omit the argument for the backward and forward compatibility.

History objects now throw if the document is inactive

The spec of the {{ domxref("History") }} interface has been updated, and the properties and methods now throw a SecurityError exception when those are called on an inactive {{ domxref("document") }}. It would be a problem if you are manipulating {{ domxref("window.history") }} in an {{ HTMLElement("iframe") }}.

Plug-in MIME types are now written in lower-case

Starting with Firefox 28, MIME types exposed in the {{ domxref("document.plugins") }}, {{ domxref("window.navigator.plugins") }} and {{ domxref("window.navigator.mimeTypes") }} properties are designated by lower-case letters, instead of the original mixed-case or upper-case type. Be sure to use the String.toLowerCase method when you try to find a specific MIME type.

Video/Audio

canPlayType('video/webm') now returns 'maybe'

The canPlayType method of the {{ domxref("HTMLMediaElement") }} interface has been updated to comply with the spec. canPlayType('video/webm') and canPlayType('audio/webm') now return 'maybe' instead of 'probably', because media can be encoded with a codec that Firefox doesn't support. If a codec is specified in the type argument, the method returns 'probably' or '' (empty string) depending on the codec. For example, canPlayType('video/webm; codecs=vp8') returns 'probably'.

Revision Source

<p>Firefox&nbsp;28 was released on <time datetime="2014-03-18">March&nbsp;18, 2014</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/28.0/releasenotes/">Firefox&nbsp;28 Release Notes</a></li>
<li><a href="/en-US/docs/Mozilla/Firefox/Releases/28">Firefox&nbsp;28 for developers</a></li>
</ul>
<p>Follow <a href="https://twitter.com/MozWebCompat">@MozWebCompat</a> on Twitter for further updates.</p>
<section id="sect5">
<h2 id="DOM">DOM</h2>
<section id="sect2">
<h3 id="showModalDialog_has_been_deprecated"><code>showModalDialog</code> has been deprecated</h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=933040">Bug&nbsp;933040 – Warn for showModalDialog uses</a></li>
</ul>
<p>The {{ domxref("window.showModalDialog") }} method, originally from Internet Explorer, is now considered deprecated. The {{ domxref("window.open") }} method should be used instead.</p>
</section>
<section id="sect3">
<h3 id="Make_sure_the_deep_argument_is_specified_for_cloneNode_and_importNode">Make sure the <code>deep</code> argument is specified for <code>cloneNode</code> and <code>importNode</code></h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=937465">Bug&nbsp;937465 – Add a warning when cloneNode/importNode is used without a boolean argument on a node with children</a></li>
</ul>
<p>The {{ domxref("Node.cloneNode") }} and {{ domxref("document.importNode") }} methods take the boolean <code>deep</code> argument. It's optional in the DOM4 specification, and if omitted, these methods acted as if the value of <code>deep</code> was <code>true</code>. But this behavior has been changed in the latest spec, and if omitted, the methods will act as if the value was <code>false</code>. The implementation has been changed in <a href="/en-US/Firefox/Releases/29/Site_Compatibility">Firefox&nbsp;29</a>. Though the argument is still optional, Firefox now warns developers in console not to omit the argument for the backward and forward compatibility.</p>
</section>
<section id="sect4">
<h3 id="History_objects_now_throw_if_the_document_is_inactive"><code>History</code> objects now throw if the <code>document</code> is inactive</h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=940783">Bug&nbsp;940783 – History objects should unconditionally throw if their inner is not current</a></li>
</ul>
<p>The spec of the {{ domxref("History") }} interface has been updated, and the properties and methods now throw a <code>SecurityError</code> exception when those are called on an inactive {{ domxref("document") }}. It would be a problem if you are manipulating {{ domxref("window.history") }} in an {{ HTMLElement("iframe") }}.</p>
</section>
<section id="sect1">
<h3 id="The_MozBeforeResize_event_has_been_removed">The <code>MozBeforeResize</code> event has been removed</h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=946449">Bug&nbsp;946449 – Remove unused MozBeforeResize event</a></li>
</ul>
<p>The support for the non-standard, obscure <a href="/en-US/docs/Web/Reference/Events/MozBeforeResize"><code>MozBeforeResize</code></a> event has been removed.</p>
</section>
<section id="sect10">
<h3 id="Plug-in_MIME_types_are_now_in_lower-case">Plug-in MIME types are now written in lower-case</h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=206659">Bug&nbsp;206659 - Plugin not found, because MIME type has upper-case letters</a></li>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=985859">Bug&nbsp;985859 - navigator.mimeTypes has lower-cased MIME types since Firefox 28 while preserving case on earlier versions</a></li>
</ul>
<p>Starting with Firefox&nbsp;28, MIME types exposed in the {{ domxref("document.plugins") }}, {{ domxref("window.navigator.plugins") }} and {{ domxref("window.navigator.mimeTypes") }} properties are designated by lower-case letters, instead of the original mixed-case or upper-case type. Be sure to use the <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/toLowerCase"><code>String.toLowerCase</code></a> method when you try to find a specific MIME type.</p>
</section>
</section>
<section id="sect6">
<h2 id="Networking">Networking</h2>
<section id="sect7">
<h3 id="SPDY.2F2_support_has_been_dropped">SPDY/2 support has been dropped</h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=912550">Bug&nbsp;912550 – remove spdy/2 support</a></li>
</ul>
<p>The support of SPDY Protocol Draft&nbsp;2 has been removed. Web sites should upgrade to SPDY/3 or later.</p>
</section>
</section>
<section id="sect8">
<h2 id="Video.2FAudio">Video/Audio</h2>
<section id="sect9">
<h3 id="canPlayType('video.2Fwebm')_now_returns_'maybe'"><code>canPlayType('video/webm')</code> now returns <code>'maybe'</code></h3>
<ul>
<li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=884275">Bug&nbsp;884275 – canPlayType('video/webm') should report 'maybe' instead of 'probably'</a></li>
</ul>
<p>The <code>canPlayType</code> method of the {{ domxref("HTMLMediaElement") }} interface has been updated to comply with the spec. <code>canPlayType('video/webm')</code> and <code>canPlayType('audio/webm')</code> now return <code>'maybe'</code> instead of <code>'probably'</code>, because media can be encoded with a codec that Firefox doesn't support. If a codec is specified in the <code>type</code> argument, the method returns <code>'probably'</code> or <code>''</code> (empty string) depending on the codec. For example, <code>canPlayType('video/webm; codecs=vp8')</code> returns <code>'probably'</code>.</p>
</section>
</section>