searching for reviewer(kmag)
77d2f80257d192d689db0e52061f129169b7fa53: Bug 1550422 - P13. Add Skip, Once and Live cached preference policy. r=njn,kmag
Jean-Yves Avenard <jyavenard@mozilla.com> - Sat, 25 May 2019 00:03:53 +0000 - rev 475542
Push 86362 by jyavenard@mozilla.com at Sat, 25 May 2019 01:48:12 +0000
Bug 1550422 - P13. Add Skip, Once and Live cached preference policy. r=njn,kmag This works identically to what gfxPrefs UpdatePolicy offers. Differential Revision: https://phabricator.services.mozilla.com/D31257
6dc82f88333d1c76be3a848afcec72d97e9bf289: Bug 1550422 - P8. Add shared pref serializer/deserializer to VR process. r=kmag,daoshengmu
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 23 May 2019 04:13:07 +0000 - rev 475537
Push 86362 by jyavenard@mozilla.com at Sat, 25 May 2019 01:48:12 +0000
Bug 1550422 - P8. Add shared pref serializer/deserializer to VR process. r=kmag,daoshengmu Differential Revision: https://phabricator.services.mozilla.com/D31016
7d3c2d48670620bf37673194755164e175f209d3: Bug 1550422 - P2. add shared pref serializer/deserializer to GPU process. r=kmag
Jean-Yves Avenard <jyavenard@mozilla.com> - Thu, 23 May 2019 04:13:05 +0000 - rev 475531
Push 86362 by jyavenard@mozilla.com at Sat, 25 May 2019 01:48:12 +0000
Bug 1550422 - P2. add shared pref serializer/deserializer to GPU process. r=kmag Differential Revision: https://phabricator.services.mozilla.com/D30587
9c779a0d65aeaacc948bb8c29dcc3c7e70f521f4: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Thu, 23 May 2019 18:49:08 +0000 - rev 475412
Push 86314 by brennie@mozilla.com at Fri, 24 May 2019 15:46:28 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
f104f127518e7a5265155186168c02e592cc9080: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Thu, 23 May 2019 18:48:48 +0000 - rev 475411
Push 86314 by brennie@mozilla.com at Fri, 24 May 2019 15:46:28 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
85f424c7b1f8e0fa584bec06bba5358f11a7722f: Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag
Barret Rennie <barret@brennie.ca> - Fri, 24 May 2019 15:45:05 +0000 - rev 475410
Push 86314 by brennie@mozilla.com at Fri, 24 May 2019 15:46:28 +0000
Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag The BrowserParent's IPC receive methods for nsIWebProgress events in the BrowserChild were all doing the same set up to ensure they had the correct state to process them. This has now been refactored out into a single method. Differential Revision: https://phabricator.services.mozilla.com/D30730
7718aebfcc5203dd29e5e7609aca8aa8ff1e446c: Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley
Barret Rennie <barret@brennie.ca> - Thu, 23 May 2019 18:48:18 +0000 - rev 475409
Push 86314 by brennie@mozilla.com at Fri, 24 May 2019 15:46:28 +0000
Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley Before the WebProgress event handlers started migrating to C++, the parent process would only receive WebProgress events after the child process had finished loading the WebProgressChild script. Now that listeners are registered much earlier (before the BrowserChild has finished setting up its frame scripts), the BrowserParent would receive WebProgress events that were heretofore not received unless the BrowserChild was *very* careful about when it sent the IPC messages. However, even while being very careful, the OnStateChange event handler would always fire events for initial about:blank loads that break a lot of unit tests. Before porting that event, we are now ensuring that the WebProgressChild has finished loading before the BrowserChild will send IPC messages for these events to the BrowserParent. Differential Revision: https://phabricator.services.mozilla.com/D30252
be1723043e976056d8cbb139912c9f2a325e190e: Bug 1543384 - Fix race in extension state setter r=kmag
Rob Wu <rob@robwu.nl> - Thu, 23 May 2019 20:39:13 +0000 - rev 475306
Push 86242 by rob@robwu.nl at Fri, 24 May 2019 00:42:16 +0000
Bug 1543384 - Fix race in extension state setter r=kmag As a side effect of this patch, the format of the "state" value of "async shutdown timeout" crash reports will change, as follows: "Run manifest: " has been replaced with "Run manifest, ": ``` - Startup: Run manifest: asyncEmitManifestEntry("background") + Startup: Run manifest, asyncEmitManifestEntry("background") ``` Multiple states are now separated by ", " instead of ",": ``` - Startup: Run manifest: manifest_name,manifest_version + Startup: Run manifest, manifest_name, manifest_version ``` "Run manifest" will always have a "Startup: " in front of it: ``` - Startup: Emit Startup,Run manifest + Startup: Emit Startup, Startup: Run manifest ``` And removed the `manifest_*` event dispatch since it has no listeners. Differential Revision: https://phabricator.services.mozilla.com/D26986
f781d415cef6c8fce8abeaf8d93cfb52ee4aa8cb: Bug 1550422 - P13. Add Skip, Once and Live cached preference policy. r=njn,kmag
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 22 May 2019 16:59:29 +0000 - rev 475061
Push 86144 by jyavenard@mozilla.com at Wed, 22 May 2019 23:38:30 +0000
Bug 1550422 - P13. Add Skip, Once and Live cached preference policy. r=njn,kmag This works identically to what gfxPrefs UpdatePolicy offers. Differential Revision: https://phabricator.services.mozilla.com/D31257
10c153ddbaea7474d33e781eab9996d589ac32ca: Bug 1550422 - P8. Add shared pref serializer/deserializer to VR process. r=kmag,daoshengmu
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 22 May 2019 13:23:07 +0000 - rev 475056
Push 86144 by jyavenard@mozilla.com at Wed, 22 May 2019 23:38:30 +0000
Bug 1550422 - P8. Add shared pref serializer/deserializer to VR process. r=kmag,daoshengmu Differential Revision: https://phabricator.services.mozilla.com/D31016
ca47ef6c59f7f25ee070e0bce5f459de6ae84c78: Bug 1550422 - P2. add shared pref serializer/deserializer to GPU process. r=kmag
Jean-Yves Avenard <jyavenard@mozilla.com> - Wed, 22 May 2019 13:05:09 +0000 - rev 475050
Push 86144 by jyavenard@mozilla.com at Wed, 22 May 2019 23:38:30 +0000
Bug 1550422 - P2. add shared pref serializer/deserializer to GPU process. r=kmag Differential Revision: https://phabricator.services.mozilla.com/D30587
fe4c28957f15f8f17707ff13866663b2321d5a12: Bug 1552537 - Include preferences option for plugins r=kmag
Mark Striemer <mstriemer@mozilla.com> - Wed, 22 May 2019 20:01:52 +0000 - rev 475032
Push 86129 by mstriemer@mozilla.com at Wed, 22 May 2019 21:56:03 +0000
Bug 1552537 - Include preferences option for plugins r=kmag Differential Revision: https://phabricator.services.mozilla.com/D31707
756519a7cf79069510c83d82f7616a5cf5aa741e: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 21:35:04 +0000 - rev 475021
Push 86118 by brennie@mozilla.com at Wed, 22 May 2019 21:46:38 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
39c6818fdb12675afb6f25cdb467b54e02f907d2: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 21:34:54 +0000 - rev 475020
Push 86118 by brennie@mozilla.com at Wed, 22 May 2019 21:46:38 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
3d9715a5ecd43cf7414133b5aae5e537f333231f: Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 21:34:40 +0000 - rev 475019
Push 86118 by brennie@mozilla.com at Wed, 22 May 2019 21:46:38 +0000
Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag The BrowserParent's IPC receive methods for nsIWebProgress events in the BrowserChild were all doing the same set up to ensure they had the correct state to process them. This has now been refactored out into a single method. Differential Revision: https://phabricator.services.mozilla.com/D30730
418a61f5f87bff0dfceae36f3bbde0a242076cad: Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley
Barret Rennie <barret@brennie.ca> - Wed, 22 May 2019 17:49:29 +0000 - rev 475018
Push 86118 by brennie@mozilla.com at Wed, 22 May 2019 21:46:38 +0000
Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley Before the WebProgress event handlers started migrating to C++, the parent process would only receive WebProgress events after the child process had finished loading the WebProgressChild script. Now that listeners are registered much earlier (before the BrowserChild has finished setting up its frame scripts), the BrowserParent would receive WebProgress events that were heretofore not received unless the BrowserChild was *very* careful about when it sent the IPC messages. However, even while being very careful, the OnStateChange event handler would always fire events for initial about:blank loads that break a lot of unit tests. Before porting that event, we are now ensuring that the WebProgressChild has finished loading before the BrowserChild will send IPC messages for these events to the BrowserParent. Differential Revision: https://phabricator.services.mozilla.com/D30252
b32c3d74d2ac5d34cb896783ebf5696474443c92: Bug 1456140 - Remove unnecessary size args for getChildList. r=kmag
Michael Kaply <mozilla@kaply.com> - Tue, 21 May 2019 06:20:40 +0000 - rev 474944
Push 86093 by mozilla@kaply.com at Wed, 22 May 2019 14:13:39 +0000
Bug 1456140 - Remove unnecessary size args for getChildList. r=kmag Differential Revision: https://phabricator.services.mozilla.com/D31631
fe795231a4afd00fda470d47fb35cf35937c9de3: Bug 1552998 make the telemetry permission privileged r=kmag
Shane Caraveo <scaraveo@mozilla.com> - Wed, 22 May 2019 01:28:27 +0000 - rev 474890
Push 86047 by scaraveo@mozilla.com at Wed, 22 May 2019 01:32:59 +0000
Bug 1552998 make the telemetry permission privileged r=kmag add telemetry to the privileged permissions list Differential Revision: https://phabricator.services.mozilla.com/D31935
52f04e977ce5e9b9a35b70539be3860c877edc5a: Bug 1552998 - Bug 1540565 make the telemetry permission privileged r=kmag
Shane Caraveo <scaraveo@mozilla.com> - Tue, 21 May 2019 20:11:12 +0000 - rev 474870
Push 86032 by scaraveo@mozilla.com at Tue, 21 May 2019 22:37:52 +0000
Bug 1552998 - Bug 1540565 make the telemetry permission privileged r=kmag add telemetry to the privileged permissions list Differential Revision: https://phabricator.services.mozilla.com/D31935
c5488e2770a6273fae9d9ae62ab9bca888354b95: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 19:28:52 +0000 - rev 474836
Push 86011 by brennie@mozilla.com at Tue, 21 May 2019 19:30:04 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
df98eef1f640b109944ec52da0932e62763bbac6: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 19:28:39 +0000 - rev 474835
Push 86011 by brennie@mozilla.com at Tue, 21 May 2019 19:30:04 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
db6da7f94a9239c903dbd25bdc142798e4bfa9b1: Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 19:28:19 +0000 - rev 474834
Push 86011 by brennie@mozilla.com at Tue, 21 May 2019 19:30:04 +0000
Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag The BrowserParent's IPC receive methods for nsIWebProgress events in the BrowserChild were all doing the same set up to ensure they had the correct state to process them. This has now been refactored out into a single method. Differential Revision: https://phabricator.services.mozilla.com/D30730
fb696b92c13dfcc10af3c528c013e3d513510c12: Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 19:28:04 +0000 - rev 474833
Push 86011 by brennie@mozilla.com at Tue, 21 May 2019 19:30:04 +0000
Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley Before the WebProgress event handlers started migrating to C++, the parent process would only receive WebProgress events after the child process had finished loading the WebProgressChild script. Now that listeners are registered much earlier (before the BrowserChild has finished setting up its frame scripts), the BrowserParent would receive WebProgress events that were heretofore not received unless the BrowserChild was *very* careful about when it sent the IPC messages. However, even while being very careful, the OnStateChange event handler would always fire events for initial about:blank loads that break a lot of unit tests. Before porting that event, we are now ensuring that the WebProgressChild has finished loading before the BrowserChild will send IPC messages for these events to the BrowserParent. Differential Revision: https://phabricator.services.mozilla.com/D30252
57f49df057be162a48618ed969f3859a087e0b77: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 17:09:14 +0000 - rev 474812
Push 85996 by brennie@mozilla.com at Tue, 21 May 2019 17:12:20 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
de97a258fcfdc7de3668acf70c2f6732335eac6c: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 17:08:57 +0000 - rev 474811
Push 85996 by brennie@mozilla.com at Tue, 21 May 2019 17:12:20 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
4b0ed20ab3bc1a15cc459a96a5be69d4ba9c35bc: Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 17:08:42 +0000 - rev 474810
Push 85996 by brennie@mozilla.com at Tue, 21 May 2019 17:12:20 +0000
Bug 1510569 - Refactor BrowserParent nsIWebProgress handlers r=kmag The BrowserParent's IPC receive methods for nsIWebProgress events in the BrowserChild were all doing the same set up to ensure they had the correct state to process them. This has now been refactored out into a single method. Differential Revision: https://phabricator.services.mozilla.com/D30730
1d8ab383d3e9643073e95ae257ffde377de3cfd9: Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley
Barret Rennie <barret@brennie.ca> - Tue, 21 May 2019 17:08:25 +0000 - rev 474809
Push 85996 by brennie@mozilla.com at Tue, 21 May 2019 17:12:20 +0000
Bug 1510569 - Only forward nsIWebProgress events to the BrowserParent after the WebProgressChild has loaded r=kmag,mconley Before the WebProgress event handlers started migrating to C++, the parent process would only receive WebProgress events after the child process had finished loading the WebProgressChild script. Now that listeners are registered much earlier (before the BrowserChild has finished setting up its frame scripts), the BrowserParent would receive WebProgress events that were heretofore not received unless the BrowserChild was *very* careful about when it sent the IPC messages. However, even while being very careful, the OnStateChange event handler would always fire events for initial about:blank loads that break a lot of unit tests. Before porting that event, we are now ensuring that the WebProgressChild has finished loading before the BrowserChild will send IPC messages for these events to the BrowserParent. Differential Revision: https://phabricator.services.mozilla.com/D30252
c50b4c90d56a76d96c138adfc3562cc5f135257a: Bug 1552248 support ftp channel in proxy api r=mayhemer,kmag
Shane Caraveo <scaraveo@mozilla.com> - Mon, 20 May 2019 15:05:26 +0000 - rev 474584
Push 85888 by scaraveo@mozilla.com at Mon, 20 May 2019 17:47:15 +0000
Bug 1552248 support ftp channel in proxy api r=mayhemer,kmag ChannelWrapper is used throughout webext APIs and it requires a channel to support weakref. FTPChannel did not, thus ftp requests did not go through proxy.onRequest. Differential Revision: https://phabricator.services.mozilla.com/D31540
296ca33d9a0e4bd501df7db94fac65961c7acec5: Bug 1551455 - Reinstall distribution language packs. r=kmag
Michael Kaply <mozilla@kaply.com> - Thu, 16 May 2019 18:19:14 +0000 - rev 474227
Push 85699 by mozilla@kaply.com at Thu, 16 May 2019 22:06:41 +0000
Bug 1551455 - Reinstall distribution language packs. r=kmag Differential Revision: https://phabricator.services.mozilla.com/D31456
b7d165b8966e6a9ca0576fa6ee7c49a52d604d4c: Bug 1547835 - Show release notes on HTML about:addons details r=aswan,flod,rpl,kmag
Mark Striemer <mstriemer@mozilla.com> - Wed, 15 May 2019 19:27:37 +0000 - rev 474119
Push 85664 by mstriemer@mozilla.com at Thu, 16 May 2019 15:44:19 +0000
Bug 1547835 - Show release notes on HTML about:addons details r=aswan,flod,rpl,kmag Differential Revision: https://phabricator.services.mozilla.com/D30428
294fb9eba22edda7dd2f8c3691364eb8b6a2a2d0: Bug 1551744 move webnavigation modules to extensions component r=kmag
Shane Caraveo <scaraveo@mozilla.com> - Wed, 15 May 2019 00:17:25 +0000 - rev 473895
Push 85514 by scaraveo@mozilla.com at Wed, 15 May 2019 01:05:36 +0000
Bug 1551744 move webnavigation modules to extensions component r=kmag Differential Revision: https://phabricator.services.mozilla.com/D31167
9d42cbab5277796bf76e874bdc4fe3eaaad99889: Bug 1551744 move webrequest modules into extension component r=kmag
Shane Caraveo <scaraveo@mozilla.com> - Wed, 15 May 2019 00:20:40 +0000 - rev 473894
Push 85514 by scaraveo@mozilla.com at Wed, 15 May 2019 01:05:36 +0000
Bug 1551744 move webrequest modules into extension component r=kmag Differential Revision: https://phabricator.services.mozilla.com/D31168
998d83fa2ae988509435ba88de2c640f4607f2fa: Bug 1549192 Remove extension shutdownReason footgun r=kmag
Andrew Swan <aswan@mozilla.com> - Thu, 09 May 2019 19:46:38 -0700 - rev 473734
Push 85414 by apavel@mozilla.com at Tue, 14 May 2019 04:18:58 +0000
Bug 1549192 Remove extension shutdownReason footgun r=kmag Checking extension.shutdownReason for any purpose other than detecting app shutdown is unreliable, since actions such as disabing, uninstalling, etc. may happen ito an extension after it has shut down. Remove the temptation for api authors to write incorrect code by removing extension.shutdownReason and replacing it with an isAppShutdown boolean passed to shutdown handlers. Differential Revision: https://phabricator.services.mozilla.com/D30605
46b6ab028e3cb6259bae478a38c4b590384e7d4c: Bug 1549192 Fix extension apis that handle addon disabling r=kmag
Andrew Swan <aswan@mozilla.com> - Thu, 09 May 2019 19:59:21 -0700 - rev 473733
Push 85414 by apavel@mozilla.com at Tue, 14 May 2019 04:18:58 +0000
Bug 1549192 Fix extension apis that handle addon disabling r=kmag API implementations that check shutdownReason for values other than APP_SHUTDOWN during extension shutdown are inherently broken since an addon may be disabled or uninstalled between browser sessions, in which case code that is meant to run in these cases will not get executed. This patch fixes existing api implementations that are broken in this way. Also ensure that APIs' onDisabled methods get called properly when an extension is disabled between browser sessions. Differential Revision: https://phabricator.services.mozilla.com/D30604
90b6ea6c5c2ac2736134dbbc6d21c6515b13e8a3: Bug 1549192 Send ADDON_ENABLE startupReason for addons enabled early during browser startup r=kmag
Andrew Swan <aswan@mozilla.com> - Thu, 09 May 2019 15:54:06 -0700 - rev 473732
Push 85414 by apavel@mozilla.com at Tue, 14 May 2019 04:18:58 +0000
Bug 1549192 Send ADDON_ENABLE startupReason for addons enabled early during browser startup r=kmag Differential Revision: https://phabricator.services.mozilla.com/D30603
0bc1bd7285c1e06298eabf873e627596d95e73c2: Bug 1547835 - Show release notes on HTML about:addons details r=aswan,flod,rpl,kmag
Mark Striemer <mstriemer@mozilla.com> - Mon, 13 May 2019 19:04:11 +0000 - rev 473657
Push 85367 by mstriemer@mozilla.com at Mon, 13 May 2019 19:06:16 +0000
Bug 1547835 - Show release notes on HTML about:addons details r=aswan,flod,rpl,kmag Differential Revision: https://phabricator.services.mozilla.com/D30428
18861619a4b332b44fb1602d42dbba56cca25bdd: Bug 1547882 - Fix test_bug337744.js that expects no %2f in the query of resource URLs r=kmag,kershaw
Valentin Gosu <valentin.gosu@gmail.com> - Fri, 10 May 2019 13:56:27 +0000 - rev 473407
Push 85209 by valentin.gosu@gmail.com at Fri, 10 May 2019 13:57:36 +0000
Bug 1547882 - Fix test_bug337744.js that expects no %2f in the query of resource URLs r=kmag,kershaw Differential Revision: https://phabricator.services.mozilla.com/D30351
6cfaeaa212f82db5129ef7c72f5e4a5e990a1e1f: Bug 1549858 - move blocklist json into tests, r=kmag
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 08 May 2019 19:04:51 +0000 - rev 473174
Push 85075 by gijskruitbosch@gmail.com at Thu, 09 May 2019 00:07:41 +0000
Bug 1549858 - move blocklist json into tests, r=kmag Differential Revision: https://phabricator.services.mozilla.com/D30394
d5a6ca2d0e9d4b68fc1d316ab07d9f4e38a8f11e: bug 1549249 - follow-up to bump add-on db schema so users pick up the changes faster r=kmag a=ryanvm
Dana Keeler <dkeeler@mozilla.com> - Mon, 06 May 2019 13:53:00 -0700 - rev 472806
Push 84845 by opoprus@mozilla.com at Mon, 06 May 2019 22:34:09 +0000
bug 1549249 - follow-up to bump add-on db schema so users pick up the changes faster r=kmag a=ryanvm Reviewers: kmag Tags: #secure-revision Bug #: 1549249 Differential Revision: https://phabricator.services.mozilla.com/D30113
c52835481c084fecff479ddf35e06054c5e0ba32: bug 1549249 - hard-code new add-on signing intermediate so it's always available r=jcj,kmag a=ryanvm
Dana Keeler <dkeeler@mozilla.com> - Mon, 06 May 2019 10:42:52 -0700 - rev 472805
Push 84845 by opoprus@mozilla.com at Mon, 06 May 2019 22:34:09 +0000
bug 1549249 - hard-code new add-on signing intermediate so it's always available r=jcj,kmag a=ryanvm Summary: Our previous approach to making this intermediate available relied on being able to add it to the user's NSS cert DB. This does work in the majority of cases, but there are some situations where it doesn't work (e.g. if the user's DB is set to read only, if they've configured Firefox to run in "nocertdb" mode, if they have a master password but forgot it, and so on). This patch compiles the intermediate in to Firefox in the same way we incorporate the root, so it should always be available. At the same time, this patch reverts the changes from 023dd959512e2cfa685187616560f91efa91183c and 1d35f8d88bdd007e01d42c4ff76c6d10d7c01a98 (the patches that implemented the original approach) because they should no longer be necessary. Reviewers: jcj!, kmag! Tags: #secure-revision Bug #: 1549249 Differential Revision: https://phabricator.services.mozilla.com/D30090
445c0c44fa894aadf3ebf849fef5bdb0aa4c547d: Bug 1549075 Follow-up: Fix system addon test on CLOSED TREE r=kmag a=bustage
Andrew Swan <aswan@mozilla.com> - Sat, 04 May 2019 22:12:55 -0700 - rev 472607
Push 84749 by ccoroiu@mozilla.com at Sun, 05 May 2019 21:43:33 +0000
Bug 1549075 Follow-up: Fix system addon test on CLOSED TREE r=kmag a=bustage
74e72eb8369d8f494be2943cbf010d072d3e266c: Bug 1549075 Don't blow up on builtin addons while rebuilding the extensions database r=kmag a=lizzard CLOSED TREE
Andrew Swan <aswan@mozilla.com> - Sat, 04 May 2019 19:23:37 -0700 - rev 472605
Push 84749 by ccoroiu@mozilla.com at Sun, 05 May 2019 21:43:33 +0000
Bug 1549075 Don't blow up on builtin addons while rebuilding the extensions database r=kmag a=lizzard CLOSED TREE Differential Revision: https://phabricator.services.mozilla.com/D29954
023dd959512e2cfa685187616560f91efa91183c: Bug 1549061 - Add intermediate certificate r=kmag a=lizzard CLOSED TREE
Rob Wu <rob@robwu.nl> - Sat, 04 May 2019 21:39:46 +0000 - rev 472604
Push 84749 by ccoroiu@mozilla.com at Sun, 05 May 2019 21:43:33 +0000
Bug 1549061 - Add intermediate certificate r=kmag a=lizzard CLOSED TREE This patch relies on a schema bump in a previous commit to be effective for users. Differential Revision: https://phabricator.services.mozilla.com/D29940
fc0ae629221af74287f6df6f2ffb8bcc0b52c123: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Thu, 02 May 2019 23:36:24 +0000 - rev 472396
Push 84637 by brennie@mozilla.com at Thu, 02 May 2019 23:37:19 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
97f6ac273b5dcc04a553e4dec24362da2dbc5809: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Thu, 02 May 2019 23:35:02 +0000 - rev 472395
Push 84637 by brennie@mozilla.com at Thu, 02 May 2019 23:37:19 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
634737ac37d4c6bcc1a93206a144c5e58fa70aa4: Bug 1548177 support incognito flag in request filtering r=kmag,robwu
Shane Caraveo <scaraveo@mozilla.com> - Thu, 02 May 2019 16:23:03 +0000 - rev 472344
Push 84618 by scaraveo@mozilla.com at Thu, 02 May 2019 20:31:30 +0000
Bug 1548177 support incognito flag in request filtering r=kmag,robwu Differential Revision: https://phabricator.services.mozilla.com/D29446
a21eae6d674f1c5961414e2f260b3fb35bbe2995: Bug 1527902 - Enable javascript.options.bigint by default r=jandem,kmag
Robin Templeton <robin@igalia.com> - Thu, 02 May 2019 19:19:00 +0000 - rev 472337
Push 84611 by ncsoregi@mozilla.com at Thu, 02 May 2019 19:51:39 +0000
Bug 1527902 - Enable javascript.options.bigint by default r=jandem,kmag Differential Revision: https://phabricator.services.mozilla.com/D29182
13c5249d66a7fea13cac278964ad365564ae4478: Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag
Barret Rennie <barret@brennie.ca> - Thu, 02 May 2019 16:20:34 +0000 - rev 472322
Push 84597 by brennie@mozilla.com at Thu, 02 May 2019 17:02:19 +0000
Bug 1510569 - Port onStateChange notifications inside WebProgressChild.jsm to C++ r=baku,kmag We now also only access the document when the state is nsIWebProgress::STATE_STOP. The comments in the previous code indicated that touching the document inside the event handler when the state is not STATE_STOP would result in the content creating a new about:blank document to retrieve the values from. However, it then went on to do this in another location, causing a document to be created whenever we received an onStateChange event. This should no longer occur. Differential Revision: https://phabricator.services.mozilla.com/D28125
a6ad4039d785f53692c799110dae82ca82a2d279: Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot
Barret Rennie <barret@brennie.ca> - Thu, 02 May 2019 17:00:51 +0000 - rev 472321
Push 84597 by brennie@mozilla.com at Thu, 02 May 2019 17:02:19 +0000
Bug 1510569 - Keep track of whether we are navigating to a new URI in nsDocShell r=mconley,kmag,qdot Previously the `WebNavigationChild` would keep track of when triggering its `nsIWebNavigation`, `goForward`, `goBack`, `gotoIndex`, and `loadURI` methods. It's `nsIWebNavigation` instance is always an `nsIDocShell` and as part of porting `OnStateChange` and `OnLocationChange` events from `WebProgressChild`/`RemoteWebProgress` to `BrowserChild`/`BrowserParent`, this informations needs to be available from the `BrowserChild`. As it stands, it is currently an expando property on the `WebProgressChild`. Instead of introducing yet another XPCOM interface for the WebProgressChild, we now store this information directly on the `nsDocShell`. Furthermore, instead of having the `WebNavigationChild` manage this part of the `nsDocShell`'s state, we can have the `nsDocShell` manage this state itself so it is always consistent. Differential Revision: https://phabricator.services.mozilla.com/D28124
b65d6e86de493a8e94b8c348bf0ab5329d998ed2: Bug 1440537 - Fix a web-extensions test that relies on layout flushes working across cross-origin iframes. r=kmag
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 25 Apr 2019 22:46:42 +0200 - rev 471665
Push 84214 by emilio@crisal.io at Sat, 27 Apr 2019 10:41:11 +0000
Bug 1440537 - Fix a web-extensions test that relies on layout flushes working across cross-origin iframes. r=kmag Same as the previous commit, I could make sendMouseEvent do something fancy / special, but I'd rather not, since it's trivially fixable in the test. Differential Revision: https://phabricator.services.mozilla.com/D28911