ae6c87e225d3820393a4b727be87a5a837205d72: Bug 1427221 - Do nsMathMLmfencedFrame cleanup in DestroyFrom, not in the dtor. r=mattwoodrow a=gchang
Mats Palmgren <mats@mozilla.com> - Tue, 09 Jan 2018 04:32:00 +0200 - rev 445671
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1427221 - Do nsMathMLmfencedFrame cleanup in DestroyFrom, not in the dtor. r=mattwoodrow a=gchang
e47207b8927fc7ae26a77e6a6bb57f258b516946: Bug 1426081 - Migrate legacy search engines to WebExtensions. r=florian a=gchang
Michael Kaply <mozilla@kaply.com> - Thu, 21 Dec 2017 12:58:56 -0600 - rev 445670
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1426081 - Migrate legacy search engines to WebExtensions. r=florian a=gchang MozReview-Commit-ID: JfSwJwMC46F
dd18bd878644487d20fc5358d2fd924e1dda0825: Bug 1416879 - Part 0d: Move browser_multie10s_update.js into its own directory. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 11 Jan 2018 10:31:17 -0500 - rev 445669
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 0d: Move browser_multie10s_update.js into its own directory. r=bkelly a=gchang This test is unfortunately a victim of a multi-e10s unregister() race from browser_force_refresh and given the imminent multi-e10s cleanup that's going to happen, the more complicated alternatives aren't worth the effort versus just moving this test to its own directory. ..and now it's disabled too. Bug 1429794 tracks re-enabling.
53c59a717ff04053ea958dd7a752281ec01b291b: Bug 1416879 - Part 0c: browser_multie10s_update.js should not use setTimeout. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Tue, 09 Jan 2018 17:31:01 -0500 - rev 445668
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 0c: browser_multie10s_update.js should not use setTimeout. r=bkelly a=gchang This test used a fixed setTimeout of 3secs for serving the SW. This lower-bounded the test runtime at 6 seconds, plus it was not safe in the event of a slow test runner. This set of changes, although a little ugly, improves the logic so that the SW's transmission is driven by a separate "release" fetch that is only triggered when both updates have been issued and the first update failure has been reported. This ensures we are observing the desired situation. There's also a sanity check on the number of times the SW script is fetched.
3196b9ada4f4a2581d6b68511d71f9067dc3117f: Bug 1416879 - Part 0b: browser_multie10s_update.js needs to protect its invariants, clean-up after itself. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Tue, 09 Jan 2018 16:16:24 -0500 - rev 445667
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 0b: browser_multie10s_update.js needs to protect its invariants, clean-up after itself. r=bkelly a=gchang
c77831e4963620a76663c9b23cc12c496fb4f651: Bug 1416879 - Part 0a: Make browser_force_refresh.js clean up after itself. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Wed, 10 Jan 2018 12:38:25 -0500 - rev 445666
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 0a: Make browser_force_refresh.js clean up after itself. r=bkelly a=gchang
7db765b809466c034cec79439f3c5f03ee0fc516: Bug 1416879 - Part 6: Test cancellation of diverted client-intercepted streams. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 18:38:43 -0500 - rev 445665
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 6: Test cancellation of diverted client-intercepted streams. r=bkelly a=gchang This adds a test where we have a ServiceWorker return 2 different types of streams that Firefox recognizes as downloads which are handled by diversion of the channel to the parent. The diverted downloads are then cancelled and we verify that cancellation actually results in the underlying connections being closed and/or the ServiceWorker notified. Our 2 types of streams are: 1. A pass-through stream that is incrementally delivered through use of an .sjs file that delivers data using setInterval. 2. A SW-authored ReadableStream (which is not enabled by default, so we set a pref.) Determining when the .sjs's stream is canceled is accomplished by opening a second "monitor" connection that only completes when the streaming connection is closed. In all cases we differentiate between cancelation and timeouts firing.
4e914143668dc37aea74225b3b2c3c1436a06f28: Bug 1416879 - Part 5: FetchStreamReader needs to cancel its reader when it encounters write errors. r=baku, f=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 18:09:32 -0500 - rev 445664
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 5: FetchStreamReader needs to cancel its reader when it encounters write errors. r=baku, f=bkelly a=gchang Currently, FetchStreamReader never signals to the JS stream code that the reader has been closed. This means that when a ServiceWorker passes a ReadableStream to respondWith and the HTTP Channel gets canceled, the JS code will keep generating the stream without ever realizing the data's not going anywhere. It's necessary to cancel the reader. Or do something like that, this seems to work!
8c317ab88b7661c41516747a0d6569c36706921b: Bug 1416879 - Part 4: FetchDriver needs to propagate write failures. r=baku a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 18:04:55 -0500 - rev 445663
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 4: FetchDriver needs to propagate write failures. r=baku a=gchang In the scenario where a ServiceWorker returns a pass-through fetch via `evt.respondWith(fetch("underlying"))`, in order for the "underlying" HTTP channel to be canceled when the outer HTTP channel is canceled, FetchDriver's OnDataAvailable method needs to return an error when the output pipe experiences an error. Unfortunately, the contract for ReadSegments is effectively that it returns NS_OK regardless of what the rv of the write handler returned, so relying on the returned rv is insufficient. And because various Write*() methods will all fast-path to returning NS_OK if a count of 0 is passed, it's necessary to infer a closed/broken pipe by noticing that we tried to write more than 0 bytes of data but 0 bytes were written. (This is safe because the pipe we write into was created by FetchDriver::OnStartRequest which explicitly creates an infinite pipe, so it's not possible for the write to fail due to lack of space in the pipe.)
0c95b7733c659823ab34ad34469fc9bbdad0d0e4: Bug 1416879 - Part 3: (Also Bug 1418795) SyntheticDiversionListener should handle !mIPCOpen. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 13:59:13 -0500 - rev 445662
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 3: (Also Bug 1418795) SyntheticDiversionListener should handle !mIPCOpen. r=bkelly a=gchang The SyntheticDiversionListener needs to handle the case where the IPC connection is gone. This patch avoids calling Send* methods which will crash the content process if the actor has already been destroyed. Additionally, OnDataAvailable will return an error in such a case so that the caller can properly handle the error rather than continuing to attempt to send data to a listener that doesn't care. This latter change is an artifact of a previous hack attempt to fix a related diversion issue that is probably not required for this stack, but makes sense as a fix, so I've left it in.
721cbc4debf789ebe92960e0c96615401125c2d7: Bug 1416879 - Part 2: Allow for diversion cancellation and trigger for intercepted channels. r=bkelly, r=mayhemer a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 18:38:07 -0500 - rev 445661
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 2: Allow for diversion cancellation and trigger for intercepted channels. r=bkelly, r=mayhemer a=gchang The diversion mechanism never expected to be dealing with data sourced from the content process, but that's exactly what happens with ServiceWorker-intercepted channels with the current child-intercept situation (which is being fixed). In order to allow timely cancellation of diverted intercepted channels, there needs to be a way to relay to the HttpChannelChild that it needs to be canceled so that the synthesized pump can be canceled and diversion can be marked as complete. This patch adds such a mechanism to ADivertableParentChannel and PHttpChannel for the exclusive use of InterceptedHttpChannel and then uses it.
b855bb9f21232d7291b2256e1a275259c4ee4577: Bug 1416879 - Part 1: DivertComplete should only be sent at OnStopRequest for synthesized responses. r=bkelly a=gchang
Andrew Sutherland <asutherland@asutherland.org> - Thu, 04 Jan 2018 18:56:46 -0500 - rev 445660
Push 1623 by archaeopteryx@coole-files.de at Mon, 15 Jan 2018 09:33:19 +0000
Bug 1416879 - Part 1: DivertComplete should only be sent at OnStopRequest for synthesized responses. r=bkelly a=gchang Diversion for intercepted channels with a synthesized response is a special case. It is not appropriate to send DivertComplete when mEventQ has been drained, because we are not dealing with the usual mEventQ-enqueued OnDataAvailable payloads that had been received over the network and sent down to the child. In this case, all the data originates in the child and does not go through mEventQ. As such, the correct place to send DivertComplete is at OnStopComplete for the synthesized response.
f3d0dfafa490db5c8b700ef8d16cc97dc28d7901: Bug 1424341 Add privacy.reduceTimerPrecision and privacy.reduceTimerPrecision.microseconds prefs and tests r=bkelly,timhuang,mrbkap a=gchang
Tom Ritter <tom@mozilla.com> - Wed, 10 Jan 2018 13:50:28 -0600 - rev 445659
Push 1622 by archaeopteryx@coole-files.de at Sat, 13 Jan 2018 00:08:59 +0000
Bug 1424341 Add privacy.reduceTimerPrecision and privacy.reduceTimerPrecision.microseconds prefs and tests r=bkelly,timhuang,mrbkap a=gchang This pref does not override privacy.resistFingerprinting, but when it is set (and privacy.resistFingerprinting is not) we will still adjust the precision of almost all timers. The adjustment amount is the second pref, which is defaulted to 20us but now dynamically adjustable (in the scale of microseconds.) We are landing this preffed off at the current value we clamp performance.now() at which is 20us. This commit is the combination of the multiple commits listed in Bug 1424341
848733c4f4dee8747d1f1d6b388e4dcf7099099f: Bug 1429133 - Some FontExplorer managed fonts are not rendered. r=Alex_Gaynor a=gchang
Haik Aftandilian <haftandilian@mozilla.com> - Wed, 10 Jan 2018 11:33:47 -0800 - rev 445658
Push 1622 by archaeopteryx@coole-files.de at Sat, 13 Jan 2018 00:08:59 +0000
Bug 1429133 - Some FontExplorer managed fonts are not rendered. r=Alex_Gaynor a=gchang MozReview-Commit-ID: L5x3GNb3HGU
1f97fc614f9ea844d2e9cc8dc5e869cffee86913: Bug 1426500 - Part 2: Update test_interfaces mochitest to expect WebVR interfaces to be disabled on release builds for macOS. r=smaug, a=gchang
Kearwood "Kip" Gilbert <kgilbert@mozilla.com> - Thu, 11 Jan 2018 15:13:58 -0800 - rev 445657
Push 1622 by archaeopteryx@coole-files.de at Sat, 13 Jan 2018 00:08:59 +0000
Bug 1426500 - Part 2: Update test_interfaces mochitest to expect WebVR interfaces to be disabled on release builds for macOS. r=smaug, a=gchang
ace563efaa9917538660c474ab5b261fd4f0132e: Bug 1426500 - Disable WebVR for macOS on Beta and Release r=daoshengmu a=gchang
Kearwood "Kip" Gilbert <kgilbert@mozilla.com> - Wed, 10 Jan 2018 16:14:21 -0800 - rev 445656
Push 1622 by archaeopteryx@coole-files.de at Sat, 13 Jan 2018 00:08:59 +0000
Bug 1426500 - Disable WebVR for macOS on Beta and Release r=daoshengmu a=gchang - WebVR will continue to be enabled on macOS for Nightly and Dev Edition MozReview-Commit-ID: LpEX13yZVbb
f2c70b72815832065e939a921adc1d6a3f557f51: Bug 1425509 - Initialize PerformanceService in RuntimeService, r=bkelly a=gchang
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 18 Dec 2017 17:49:54 +0100 - rev 445655
Push 1622 by archaeopteryx@coole-files.de at Sat, 13 Jan 2018 00:08:59 +0000
Bug 1425509 - Initialize PerformanceService in RuntimeService, r=bkelly a=gchang
f4256fe890db1e8d88f4bfea958e419f5ee88b75: Bug 1425612 - Better error messages for invalid structured clone data. r=sfink, a=gchang.
Jason Orendorff <jorendorff@mozilla.com> - Wed, 10 Jan 2018 20:45:39 -0600 - rev 445654
Push 1621 by jorendorff@mozilla.com at Fri, 12 Jan 2018 21:00:31 +0000
Bug 1425612 - Better error messages for invalid structured clone data. r=sfink, a=gchang.
d70260efa9014713bccb0f8a42b954ff352c7d45: Bug 1426783 - Fix error handling in deserialization of invalid typed arrays. r=sfink, a=gchang.
Jason Orendorff <jorendorff@mozilla.com> - Fri, 05 Jan 2018 15:17:35 -0600 - rev 445653
Push 1621 by jorendorff@mozilla.com at Fri, 12 Jan 2018 21:00:31 +0000
Bug 1426783 - Fix error handling in deserialization of invalid typed arrays. r=sfink, a=gchang.
3ebefc043ac67bc941f8e74182d3ba8fdc9419f4: Bug 1417741 Add support of Atomic<> for Preferences::Add*VarCache r=baku,njn a=gchang
Tom Ritter <tom@mozilla.com> - Wed, 20 Dec 2017 14:39:27 -0600 - rev 445652
Push 1620 by archaeopteryx@coole-files.de at Fri, 12 Jan 2018 20:17:17 +0000
Bug 1417741 Add support of Atomic<> for Preferences::Add*VarCache r=baku,njn a=gchang This is a partial backport of Bug 1417741 that only adds AddAtomicBoolVarCache because that is all we need.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip