9373b4bc3dd7a187baf7da6f26cd8050e7c2e231: Backed out changeset 7151850b2933 (bug 1421345) - dependency bug 1406727 hasn't been uplifted yet. a=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Wed, 17 Jan 2018 13:54:44 +0200 - rev 754678
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Backed out changeset 7151850b2933 (bug 1421345) - dependency bug 1406727 hasn't been uplifted yet. a=backout
571ae115f2de6aedeb1de20a80a81b4067219921: bug 1429666 cubeb_resampler_speex: don't call data callback while draining r=padenot a=gchang
Karl Tomlinson <karlt+@karlt.net> - Thu, 11 Jan 2018 13:30:24 +1300 - rev 754677
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
bug 1429666 cubeb_resampler_speex: don't call data callback while draining r=padenot a=gchang MozReview-Commit-ID: 1XEzZjPGai9
7151850b2933e3ae6e41435461545db63b6591c9: Bug 1421345 - Check the canary during allocations. r=jet a=gchang
Matt Woodrow <mwoodrow@mozilla.com> - Wed, 17 Jan 2018 12:07:34 +1300 - rev 754676
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1421345 - Check the canary during allocations. r=jet a=gchang
aba167b6e63f27f9b10ce8805b4e02d8b0a79035: Bug 1401459 - always run HttpChannelChild::Release on main thread. r=mayhemer a=gchang
Shih-Chiang Chien <schien@mozilla.com> - Thu, 11 Jan 2018 10:40:29 +0800 - rev 754675
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1401459 - always run HttpChannelChild::Release on main thread. r=mayhemer a=gchang
5096a6c3aefd858af15facdd31b53d8f57baf061: Bug 1430522 - [Form Autofill] Enable address autofill by default on release build. r=seanlee a=gchang
Luke Chang <lchang@mozilla.com> - Mon, 15 Jan 2018 15:56:53 +0800 - rev 754674
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1430522 - [Form Autofill] Enable address autofill by default on release build. r=seanlee a=gchang MozReview-Commit-ID: 9Pf8l7PqSMi
fae7c41d40fd8ddb4d6d0ade34af7c75fef0e4d5: Backed out changeset 814254bd1eb7 (bug 1421345) for bustage at dist/include/mozilla/ArenaAllocator.h:180:7: 'canary' was not declared in this scope. a=backout
Sebastian Hengst <archaeopteryx@coole-files.de> - Mon, 15 Jan 2018 14:03:07 +0200 - rev 754673
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Backed out changeset 814254bd1eb7 (bug 1421345) for bustage at dist/include/mozilla/ArenaAllocator.h:180:7: 'canary' was not declared in this scope. a=backout
814254bd1eb76533621eea0700d0182aa3121350: Bug 1421345 - Check the canary during allocations. r=jet a=gchang
Matt Woodrow <mwoodrow@mozilla.com> - Mon, 15 Jan 2018 21:12:57 +1300 - rev 754672
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1421345 - Check the canary during allocations. r=jet a=gchang
4c230b89e05e6a4d87d3f26e2ca862dd59e617d0: Bug 1429885 Support a rounding value of 0 for reduceTimerPrecision r=bkelly,timhuang a=gchang
Tom Ritter <tom@mozilla.com> - Thu, 11 Jan 2018 14:25:14 -0600 - rev 754671
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1429885 Support a rounding value of 0 for reduceTimerPrecision r=bkelly,timhuang a=gchang MozReview-Commit-ID: F96EUfXgK9F
f99b1d9d900687eeb166ec6ddcb50fd005d85513: Bug 1429859 - Check mDoNotTryEarlyData in Do0RTT(). r=mcmanus a=gchang
Dragana Damjanovic dd.mozilla@gmail.com - Thu, 11 Jan 2018 10:17:00 +0200 - rev 754670
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +0000
Bug 1429859 - Check mDoNotTryEarlyData in Do0RTT(). r=mcmanus a=gchang
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 754669
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754668
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754667
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754666
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754665
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754664
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754663
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754662
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754661
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754660
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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 754659
Push 98954 by mozilla@kaply.com at Tue, 13 Feb 2018 23:01:04 +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.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip