mozilla

Revision 615857 of Site Compatibility for Firefox 30

  • Revision slug: Mozilla/Firefox/Releases/30/Site_Compatibility
  • Revision title: Site Compatibility for Firefox 30
  • Revision id: 615857
  • Created:
  • Creator: Manishearth
  • Is current revision? No
  • Comment

Revision Content

Firefox 30 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:

Follow @FxSiteCompat on Twitter for further updates.

CSS

line-height is now applied to <input>

Until now, Firefox has ignored the {{ cssxref("line-height") }} property specified on the {{ HTMLElement("input") }} element, and always applied {{ cssxref("normal") }}, while Internet Explorer and WebKit-based browsers allow authors to increase (but not decrease) the value. To improve interoperability, this behavior has been changed to accept author-defined values. For backward compatibility, single-line text <input> elements still cannot have a line-height smaller than 1.

A regression from this change has been found on IKEA.com where the line-height is 1px, though this is considered intentional.

Incorrect padding implementation on <select> has been fixed

Firefox's incorrect implementation of {{ cssxref("padding") }} on the {{ HTMLElement("select") }} element has been fixed. Now padding spaces are added inside the dropdown list, instead of outside, to match with the CSS spec and other browsers' behavior. This issue was found while developers were working on the same issue on the {{ HTMLElement("textarea") }} element fixed with Firefox 29. <select> elements with the multiple attribute won't be affected by this change.

A hack using -moz-appearance:none to hide the drop-down arrow no longer works, though there are requests to allow styling of the arrow. Page authors should create a custom element instead if you'd like to totally control the design of dropdown lists on all browsers.

position:relative on table elements is no longer ignored

Previously, position:relative specified on table elements was ignored on Firefox because the effect was "undefined" in the CSS2 spec, while it worked as "expected" on other browsers. If you'd like to have an absolutely-positoned element in the table cell, a common workaround was putting an extra, relatively-positioned {{ HTMLElement("div") }} element beneath {{ HTMLElement("td") }}.

The Firefox implementation has been changed to accept position:relative as the effect has been defined in the CSS3 spec. You may want to keep the workaround above for the backward compatibility at least until Firefox 24 ESR reaches the end of support in .

This change may potentially break pages that apply position:relative to table elements other than {{ HTMLElement("td") }} while the author expects nothing to happen. The Web Console will warn such a case to make tracking down the issue easy.

DOM

Synchronous XMLHttpRequest has been deprecated

The async argument of the {{ domxref("XMLHttpRequest") }} constructor is true by default, and false makes the request synchronous. Developers now get an warning in the Web Console if a synchronous request is used on the main thread, or the outside of workers, since it's now considered deprecated due to the negative effects to the user experience.

DOM object constructors can no longer be called as functions

Previously, WebIDL constructors could be called without the new operator. Starting with Firefox 30, such code will raise a TypeError like Chrome and Safari. For example, var req = XMLHttpRequest(); should be var req = new XMLHttpRequest();.

Support for Blob.mozSlice has been dropped

The support for the mozSlice method of the {{ domxref("Blob") }} object, has been deprecated since Firefox 15 and removed with Firefox 30. Use the unprefied slice method instead.

Firefox OS apps should always specify a viewport <meta> tag

Firefox OS 1.3, based on Firefox 28, added the support for a viewport <meta> tag in applications. The default viewport "width=device-width, height=device-height, user-scalable=no" will be applied to apps that don't specify one. This implementation is only for backward compatibility and will eventually be removed. Open Web App developers are encouraged to always declare a viewport <meta> tag to avoid a possible breakage in the future.

Archive API has been disabled

The Archive API, experimentally implemented since Firefox 17 as {{ domxref("ArchiveReader") }} and {{ domxref("ArchiveRequest") }}, has been disabled behind a preference. If you'd like to test the API, change the value of dom.archivereader.enabled to true.

The {{ domxref("Navigator.requestWakeLock") }} method and the {{ domxref("MozWakeLock") }} object, a part of the Power Management API, are useful only on Firefox OS but have been exposed to all platforms. Those are no longer available except on Firefox OS.

MozConnection interface is no longer a global object

The {{ domxref("Connection") }} interface, currently prefixed as MozConnection, is no longer available on {{ domxref("window") }} as a global object. Use {{ domxref("navigator.mozConnection") }} to utilize the Network Information API.

KeyboardEvent.DOM_VK_ENTER has been removed

The DOM_VK_ENTER constant has been removed from the {{ domxref("KeyboardEvent") }} interface and it now returns null instead of 14. This should not break any existing code since it has never used in key events like {{ event("keydown") }} or {{ event("keypress") }}, but you may want to remove it if you have. The DOM_VK_RETURN constant represents both Enter and Return keys.

JavaScript

Use of the Object.__proto__ setter should be avoided

Mutating the prototype of an object, using either Object.__proto__ or Object.setPrototypeOf, is strongly discouraged because the operation is very slow. While Internet Explorer 11 added the support of Object.__proto__ for interoperability, this property has been deprecated and should not be used. Firefox 30 and later warns the usage of the Object.__proto__ setter when the JavaScript strict warning is enabled. As described in the documents, the Object.create method should be used instead to create an object with a desired prototype.

Code in eval doesn't work when the Debugger is activated

Due to a regression in the JavaScript engine, a part of script inside an eval may not work properly and throw a ReferenceError while the Debugger or the Firebug extension is activated on Firefox. Use Firefox Aurora or Beta to workaround this issue affecting ExtJS and Google Maps API in particular.

Events

The delay between touch and mouse events has been removed on responsive pages

Both Firefox for Android and Firefox OS support double-tap-to-zoom, and there is a 300-millisecond delay between the touch event (touchend) and the mouse event (click) to detect and enable this gesture. In order to improve the responsiveness of applications, this delay has been removed on non-zoomable, responsive designed pages that specify width=device-width (or some value less than device-width) and/or user-scalable=no in the viewport <meta> tag. Google Chrome 32 also removed the delay. Read an article on HTML5 Rocks for details.

Security

NTLMv1 auth has been disabled, NTLM support on non-Windows platforms is now deprecated

The support for the NT LAN Manager version 1 (NTLMv1) network authentication has been disabled because it's known as insecure. Companies and organizations still deploying the older protocol should upgrade to NTLMv2. See Honza Bambas' blog post and Jason Duell's post to the dev-planning list for details.

This is affecting SharePoint-based or IIS-backed intranet applications. If you encounter any problems on Firefox 30 or later, you can manually enable NTLMv1 using a preference. Note that NTLMv2 is not supported on non-Windows platforms, so OS X and Linux users have to toggle the preference to continue using NTLMv1 as below, though the NTLM auth support on non-Windows platforms is considered deprecated.

How to enable NTLMv1: type about:config in the location bar, click the "I'll be careful" button, find network.negotiate-auth.allow-insecure-ntlm-v1, double-click on it to change the value to true.

Another workaroud here is using Firefox 24 ESR that still enables the NTLMv1 auth.

<form autocomplete="off"> no longer prevents passwords from being saved

Firefox has offered page authors an ability to turn off the form autocompletion by setting the autocomplete="off" attribute to a {{ HTMLElement("form") }} or {{ HTMLElement("input") }} element. This feature now works the way it should be: the Password Manager always prompts if the user wants to save the password, while the autofill can be disabled as usual. Internet Explorer and Chrome have also made similar changes.

Plugins

Plugin whitelist has been implemented

Mozilla has defined the plugin whitelist policy since the Click-to-Activate functionality was added to Firefox 26. The whitelist has been implemented in Firefox 30 and plugins are now defaulted to click-to-activate except the registered ones. The complete list of whitelisted plugins is available in this spreadsheet.

Video/Audio

VideoPlaybackQuality.totalFrameDelay has been removed

The {{ domxref("VideoPlaybackQuality.totalFrameDelay") }} property has been removed since it has been marked "at risk" in the spec due to the lack of implementations.

Revision Source

<p>Firefox&nbsp;30 was released on <time datetime="2014-06-10">June&nbsp;10, 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/30.0/releasenotes/">Firefox&nbsp;30 Release Notes</a></li>
 <li><a href="/en-US/docs/Mozilla/Firefox/Releases/30">Firefox&nbsp;30 for developers</a></li>
</ul>
<p>Follow <a href="https://twitter.com/FxSiteCompat">@FxSiteCompat</a> on Twitter for further updates.</p>
<section id="sect15">
 <h2 id="CSS">CSS</h2>
 <section id="sect16">
  <h3 id="line-height_is_now_applied_to_&lt;input&gt;"><code>line-height</code> is now applied to <code>&lt;input&gt;</code></h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=349259">Bug&nbsp;349259 – CSS Property 'line-height' has no effects on input text fields</a></li>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=697451">Bug&nbsp;697451 – Allow use of line-height for &lt;input type="reset|button|submit"&gt;</a></li>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1007454">Bug&nbsp;1007454 – Regression: Text on buttons on Ikea website are cut off</a></li>
  </ul>
  <p>Until now, Firefox has ignored the {{ cssxref("line-height") }} property specified on the {{ HTMLElement("input") }} element, and always applied {{ cssxref("normal") }}, while Internet Explorer and WebKit-based browsers allow authors to increase (but not decrease) the value. To improve interoperability, this behavior has been changed to accept author-defined values. For backward compatibility, single-line text <code>&lt;input&gt;</code> elements still cannot have a <code>line-height</code> smaller than <code>1</code>.</p>
  <p>A regression from this change has been found on IKEA.com where the <code>line-height</code> is <code>1px</code>, though this is considered intentional.</p>
 </section>
 <section id="sect19">
  <h3 id="Incorrect_padding_implementation_on_&lt;select&gt;_has_been_fixed">Incorrect <code>padding</code> implementation on <code>&lt;select&gt;</code> has been fixed</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=963970">Bug&nbsp;963970 – Arrow of drop-down list should not be affected by padding</a></li>
  </ul>
  <p>Firefox's incorrect implementation of {{ cssxref("padding") }} on the {{ HTMLElement("select") }} element has been fixed. Now <code>padding</code> spaces are added inside the dropdown list, instead of outside, to match with the CSS spec and other browsers' behavior. This issue was found while developers were working on the <a href="/en-US/Firefox/Releases/29/Site_Compatibility#Incorrect_padding_implementation_on_%3Ctextarea%3E_has_been_fixed">same issue</a> on the {{ HTMLElement("textarea") }} element fixed with Firefox&nbsp;29. <code>&lt;select&gt;</code> elements with the <code>multiple</code> attribute won't be affected by this change.</p>
  <p>A hack using <code>-moz-appearance:none</code> to hide the drop-down arrow no longer works, though there are <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=649849">requests to allow styling of the arrow</a>. Page authors should create a custom element instead if you'd like to totally control the design of dropdown lists on all browsers.</p>
 </section>
 <section id="sect20">
  <h3 id="position.3Arelative_on_table_elements_is_no_longer_ignored"><code>position:relative</code> on table elements is no longer ignored</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=63895">Bug&nbsp;63895 – positioned internal table elements not abs pos containing block</a></li>
  </ul>
  <p>Previously, <code>position:relative</code> specified on table elements was ignored on Firefox because the effect was "undefined" in the CSS2 spec, while it worked as "expected" on other browsers. If you'd like to have an absolutely-positoned element in the table cell, a common workaround was putting an extra, relatively-positioned {{ HTMLElement("div") }} element beneath {{ HTMLElement("td") }}.</p>
  <p>The Firefox implementation has been changed to accept <code>position:relative</code> as the effect has been defined in the CSS3 spec. You may want to keep the workaround above for the backward compatibility at least until Firefox&nbsp;24 <a href="http://www.mozilla.org/en-US/firefox/organizations/"><abbr title="Extended Support Release">ESR</abbr></a> reaches the end of support in <time datetime="2014-10">October 2014</time>.</p>
  <p>This change may potentially break pages that apply <code>position:relative</code> to table elements other than {{ HTMLElement("td") }} while the author expects nothing to happen. The <a href="/en-US/docs/Tools/Web_Console">Web Console</a> will warn such a case to make tracking down the issue easy.</p>
 </section>
</section>
<section id="sect1">
 <h2 id="DOM">DOM</h2>
 <section id="sect2">
  <h3 id="Synchronous_XMLHttpRequest_has_been_deprecated">Synchronous <code>XMLHttpRequest</code> has been deprecated</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=969671">Bug 969671 – Warn about use of sync XHR in the main thread</a></li>
  </ul>
  <p>The <code>async</code> argument of the {{ domxref("XMLHttpRequest") }} constructor is <code>true</code> by default, and <code>false</code> makes the request synchronous. Developers now get an warning in the <a href="/en-US/docs/Tools/Web_Console">Web Console</a> if a <a href="/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request">synchronous request</a> is used on the main thread, or the outside of <a href="/en-US/docs/Web/Guide/Performance/Using_web_workers">workers</a>, since it's now considered deprecated due to the negative effects to the user experience.</p>
 </section>
 <section id="sect3">
  <h3 id="DOM_object_constructors_can_no_longer_be_called_as_functions">DOM object constructors can no longer be called as functions</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=916644">Bug 916644 – Disallow calling WebIDL constructors as functions on the web</a></li>
  </ul>
  <p>Previously, <a href="http://dxr.mozilla.org/mozilla-central/source/dom/webidl/">WebIDL</a> constructors could be called without the <a href="/en-US/docs/Web/JavaScript/Reference/Operators/new"><code>new</code></a> operator. Starting with Firefox&nbsp;30, such code will raise a <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypeError"><code>TypeError</code></a> like Chrome and Safari. For example, <code>var req = XMLHttpRequest();</code> should be <code>var req = new XMLHttpRequest();</code>.</p>
 </section>
 <section id="sect4">
  <h3 id="Support_for_Blob.mozSlice_has_been_dropped">Support for <code>Blob.mozSlice</code> has been dropped</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=961804">Bug 961804 – Drop support for Blob.mozSlice</a></li>
  </ul>
  <p>The support for the <code>mozSlice</code> method of the {{ domxref("Blob") }} object, has been deprecated since Firefox&nbsp;15 and removed with Firefox&nbsp;30. Use the unprefied <code>slice</code> method instead.</p>
 </section>
 <section id="sect5">
  <h3 id="Firefox.C2.A0OS_apps_should_always_specify_a_viewport_&lt;meta&gt;_tag">Firefox&nbsp;OS apps should always specify a viewport <code>&lt;meta&gt;</code> tag</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=845690">Bug 845690 – Support meta viewport in Firefox&nbsp;OS apps</a></li>
  </ul>
  <p><a href="/en-US/Firefox_OS/Releases/1.3">Firefox&nbsp;OS&nbsp;1.3</a>, based on Firefox&nbsp;28, added the support for a <a href="/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport <code>&lt;meta&gt;</code> tag</a> in applications. The default viewport <code>"width=device-width, height=device-height, user-scalable=no"</code> will be applied to apps that don't specify one. This implementation is only for backward compatibility and will eventually be removed. <a href="/en-US/Apps/Quickstart/Build/Intro_to_open_web_apps">Open Web App</a> developers are encouraged to always declare a viewport <code>&lt;meta&gt;</code> tag to avoid a possible breakage in the future.</p>
 </section>
 <section id="sect6">
  <h3 id="Archive_API_has_been_disabled">Archive API has been disabled</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=968883">Bug 968883 – ArchiveReader and ArchiveRequest should not be exposed interfaces</a></li>
  </ul>
  <p>The <a href="https://hacks.mozilla.org/2012/10/archiveapi-read-out-archive-file-contents-introducing-bleeding-edge/">Archive API</a>, experimentally implemented since Firefox&nbsp;17 as {{ domxref("ArchiveReader") }} and {{ domxref("ArchiveRequest") }}, has been disabled behind a preference. If you'd like to test the API, change the value of <code>dom.archivereader.enabled</code> to <code>true</code>.</p>
 </section>
 <section id="sect7">
  <h3 id="Navigator.requestWakeLock_has_been_disabled_except_on_Firefox.C2.A0OS"><code>Navigator.requestWakeLock</code> has been disabled except on Firefox&nbsp;OS</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=963366">Bug 963366 – Hide navigator.requestWakeLock and MozWakeLock from the web except on Firefox&nbsp;OS</a></li>
  </ul>
  <p>The {{ domxref("Navigator.requestWakeLock") }} method and the {{ domxref("MozWakeLock") }} object, a part of the <a href="/en-US/docs/WebAPI/Power_Management">Power Management API</a>, are useful only on Firefox&nbsp;OS but have been exposed to all platforms. Those are no longer available except on Firefox&nbsp;OS.</p>
 </section>
 <section id="sect10">
  <h3 id="MozConnection_interface_is_no_longer_a_global_object"><code>MozConnection</code> interface is no longer a global object</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=960945">Bug 960945 – MozConnection should be NoInterfaceObject</a></li>
  </ul>
  <p>The {{ domxref("Connection") }} interface, currently prefixed as <code>MozConnection</code>, is no longer available on {{ domxref("window") }} as a global object. Use {{ domxref("navigator.mozConnection") }} to utilize the <a href="/en-US/docs/Web/API/Network_Information_API">Network Information API</a>.</p>
 </section>
 <section id="sect21">
  <h3 id="KeyboardEvent.DOM_VK_ENTER_has_been_removed"><code>KeyboardEvent.DOM_VK_ENTER</code> has been removed</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=969247">Bug 969247 – Get rid of related code of NS_VK_ENTER and nsIDOMKeyEvent::DOM_VK_ENTER</a></li>
  </ul>
  <p>The <code>DOM_VK_ENTER</code> constant has been removed from the {{ domxref("KeyboardEvent") }} interface and it now returns <code>null</code> instead of <code>14</code>. This should not break any existing code since it has never used in key events like {{ event("keydown") }} or {{ event("keypress") }}, but you may want to remove it if you have. The <code>DOM_VK_RETURN</code> constant represents both <kbd>Enter</kbd> and <kbd>Return</kbd> keys.</p>
 </section>
</section>
<section id="sect13">
 <h2 id="JavaScript">JavaScript</h2>
 <section id="sect14">
  <h3 id="Use_of_the_Object.__proto___setter_should_be_avoided">Use of the <code>Object.__proto__</code> setter should be avoided</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=948227">Bug 948227 – Make the Object.prototype.__proto__ setter warn about perf impact when used, and suggest alternatives</a></li>
  </ul>
  <p>Mutating the prototype of an object, using either <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto"><code>Object.__proto__</code></a> or <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf"><code>Object.setPrototypeOf</code></a>, is strongly discouraged because the operation is very slow. While Internet Explorer 11 added the support of <code>Object.__proto__</code> for interoperability, this property has been deprecated and should not be used. Firefox&nbsp;30 and later warns the usage of the <code>Object.__proto__</code> setter when the JavaScript strict warning is enabled. As described in the documents, the <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create"><code>Object.create</code></a> method should be used instead to create an object with a desired prototype.</p>
 </section>
 <section id="sect24">
  <h3 id="Code_in_eval_doesn't_work_when_the_Debugger_is_activated">Code in <code>eval</code> doesn't work when the Debugger is activated</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=998908">Bug 998908 – [jsdbg2] Calling Debugger.Script.prototype.getChildScripts causes errors to be thrown that otherwise wouldn't be</a></li>
  </ul>
  <p>Due to a regression in the JavaScript engine, a part of script inside an <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval"><code>eval</code></a> may not work properly and throw a <code>ReferenceError</code> while the <a href="/en-US/docs/Tools/Debugger">Debugger</a> or the <a href="https://getfirebug.com/">Firebug</a> extension is activated on Firefox. Use <a href="http://www.mozilla.org/en-US/firefox/channel/">Firefox Aurora or Beta</a> to workaround this issue affecting ExtJS and Google Maps API in particular.</p>
 </section>
</section>
<section id="sect8">
 <h2 id="Events">Events</h2>
 <section id="sect9">
  <h3 id="The_delay_between_touch_and_mouse_events_has_been_removed_on_responsive_pages">The delay between touch and mouse events has been removed on responsive pages</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=941995">Bug 941995 – Remove 300ms touch &gt; mouse events delay for double-tap zoom on "responsive" pages</a></li>
  </ul>
  <p>Both <a href="/en-US/Firefox_for_Android">Firefox for Android</a> and <a href="/en-US/Firefox_OS">Firefox&nbsp;OS</a> support double-tap-to-zoom, and there is a 300-millisecond delay between the touch event (<a href="/en-US/docs/Web/Reference/Events/touchend"><code>touchend</code></a>) and the mouse event (<a href="/en-US/docs/Web/Reference/Events/click"><code>click</code></a>) to detect and enable this gesture. In order to improve the responsiveness of applications, this delay has been removed on non-zoomable, <a href="/en-US/docs/Web_Development/Mobile/Responsive_design">responsive designed</a> pages that specify <code>width=device-width</code> (or some value less than <code>device-width</code>) and/or <code>user-scalable=no</code> in the <a href="/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">viewport <code>&lt;meta&gt;</code> tag</a>. Google Chrome&nbsp;32 also removed the delay. Read an <a href="http://updates.html5rocks.com/2013/12/300ms-tap-delay-gone-away">article on HTML5 Rocks</a> for details.</p>
 </section>
</section>
<section id="sect17">
 <h2 id="Security">Security</h2>
 <section id="sect18">
  <h3 id="NTLMv1_auth_has_been_disabled.2C_NTLM_support_on_non-Windows_platforms_is_now_deprecated">NTLMv1 auth has been disabled, NTLM support on non-Windows platforms is now deprecated</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=828183">Bug 828183 – Firefox enables insecure NTLM (pre-NTLMv2) authentication</a></li>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=999306">Bug 999306 – Allow generic NTLM v1 if pref set</a></li>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1023748">Bug 1023748 – Allow NTLMv1 over SSL/TLS, or intranet access is broken on Firefox 30 for non-Windows platforms</a></li>
  </ul>
  <p>The support for the NT LAN Manager version&nbsp;1 (NTLMv1) network authentication has been disabled because it's known as insecure. Companies and organizations still deploying the older protocol should upgrade to NTLMv2. See <a href="http://www.janbambas.cz/ntlm-v1-and-firefox/">Honza Bambas' blog post</a> and <a href="https://groups.google.com/d/topic/mozilla.dev.planning/JbrpDmqDLXI">Jason Duell's post to the dev-planning list</a> for details.</p>
  <p>This is affecting SharePoint-based or IIS-backed intranet applications. If you encounter any problems on Firefox&nbsp;30 or later, you can manually enable NTLMv1 using a preference. Note that NTLMv2 is not supported on non-Windows platforms, so OS&nbsp;X and Linux users have to toggle the preference to continue using NTLMv1 as below, though the NTLM auth support on non-Windows platforms is considered deprecated.</p>
  <p>How to enable NTLMv1: type <code>about:config</code> in the location bar, click the "I'll be careful" button, find <code>network.negotiate-auth.allow-insecure-ntlm-v1</code>, double-click on it to change the value to <code>true</code>.</p>
  <p>Another workaroud here is using <a href="https://www.mozilla.org/en-US/firefox/organizations/">Firefox 24 <abbr title="Extended Support Release">ESR</abbr></a> that still enables the NTLMv1 auth.</p>
 </section>
 <section id="sect25">
  <h3 id="&lt;form_autocomplete.3D.22off.22&gt;_no_longer_prevents_password_from_being_saved"><code>&lt;form autocomplete="off"&gt;</code> no longer prevents passwords from being saved</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=956906">Bug 956906 – ignore autocomplete="off" when offering to save passwords via the password manager</a></li>
  </ul>
  <p>Firefox has offered page authors an ability to <a href="/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion">turn off the form autocompletion</a> by setting the <code>autocomplete="off"</code> attribute to a {{ HTMLElement("form") }} or {{ HTMLElement("input") }} element. This feature now works the way it should be: the <a href="https://support.mozilla.org/en-US/kb/password-manager-remember-delete-change-passwords">Password Manager</a> always prompts if the user wants to save the password, while the autofill can be disabled as usual. Internet Explorer and Chrome have also made similar changes.</p>
 </section>
</section>
<section id="sect11">
 <h2 id="Plugins">Plugins</h2>
 <section id="sect12">
  <h3 id="Plugin_whitelist_has_been_implemented">Plugin whitelist has been implemented</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=992995">Bug 992995 – Implement plugin whitelist</a></li>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1007389">Bug 1007389 – Implement plugin whitelist, round 2</a></li>
  </ul>
  <p>Mozilla has defined the <a href="https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/">plugin whitelist policy</a> since the Click-to-Activate functionality was added to <a href="/en-US/Firefox/Releases/26/Site_Compatibility">Firefox&nbsp;26</a>. The whitelist has been implemented in Firefox&nbsp;30 and plugins are now defaulted to click-to-activate except the registered ones. The complete list of whitelisted plugins is available in <a href="https://docs.google.com/spreadsheets/d/19JIQiaS9mJgkKQ07ax2KH7syRCgxt2dCCxcBD56PiQc/edit?usp=sharing">this spreadsheet</a>.</p>
 </section>
</section>
<section id="sect22">
 <h2 id="Video.2FAudio">Video/Audio</h2>
 <section id="sect23">
  <h3 id="VideoPlaybackQuality.totalFrameDelay_has_been_removed"><code>VideoPlaybackQuality.totalFrameDelay</code> has been removed</h3>
  <ul>
   <li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=962353">Bug 962353 – Remove totalFrameDelay from VideoPlaybackQuality</a></li>
  </ul>
  <p>The {{ domxref("VideoPlaybackQuality.totalFrameDelay") }} property has been removed since it has been marked "at risk" in the spec due to the lack of implementations.</p>
 </section>
</section>
Revert to this revision