a9744d6e0ef5c885c574e610f8d538b5592dd6ba: Bug 1414084 - Part 6 - Use one set of functions for managing MenuItems in the UI. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:17:03 +0100 - rev 771274
Push 103647 by mozilla@buttercookie.de at Thu, 22 Mar 2018 21:38:56 +0000
Bug 1414084 - Part 6 - Use one set of functions for managing MenuItems in the UI. r?grisha The original add-on functions have some additional capabilities regarding e.g. checkboxes, disabling the menu or nested menu items that right now aren't required for Webextensions (yet?), but in that case they will simply not be used. MozReview-Commit-ID: DPT8gV2gb6q
cfdb8ebc9f7a1acb13b057f70c25d53b0a9cbb74: Bug 1414084 - Part 5 - Unify menu click event handling. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 14:24:15 +0100 - rev 771273
Push 103647 by mozilla@buttercookie.de at Thu, 22 Mar 2018 21:38:56 +0000
Bug 1414084 - Part 5 - Unify menu click event handling. r?grisha Now that both Webextensions and the NativeWindow API manage their onClick call- back handling by UUID, we can start using the same EventDispatcher message for both. MozReview-Commit-ID: J3RRXrwPdTI
fc882ba7d8e11cb9d8da5550d356d95ac5ef68c8: Bug 1414084 - Part 4 - Move menu item ID generation into the UI. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 15:43:27 +0100 - rev 771272
Push 103647 by mozilla@buttercookie.de at Thu, 22 Mar 2018 21:38:56 +0000
Bug 1414084 - Part 4 - Move menu item ID generation into the UI. r?grisha Since the NativeWindow API now only uses UUIDs as well when dealing with its consumers, we can leave generation of the menu to the Android UI code of Firefox. MozReview-Commit-ID: 1qDLDnePfFE
77d3e588c459c3f9bef4ad0303b2c725f4f806b1: Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:33:42 +0100 - rev 771271
Push 103647 by mozilla@buttercookie.de at Thu, 22 Mar 2018 21:38:56 +0000
Bug 1414084 - Part 3 - Store NativeWindow menu callbacks by UUID. r?grisha MozReview-Commit-ID: 7nEhAUxOIsW
6cb2c4b914d0ae4f85f789cf2327462847e86dc4: Bug 1414084 - Part 2 - Use UUIDs for the NativeWindow menu API, too. r?grisha draft
Jan Henning <jh+bugzilla@buttercookie.de> - Sun, 18 Mar 2018 13:26:16 +0100 - rev 771270
Push 103647 by mozilla@buttercookie.de at Thu, 22 Mar 2018 21:38:56 +0000
Bug 1414084 - Part 2 - Use UUIDs for the NativeWindow menu API, too. r?grisha At the moment, the code for handling of JS-created main menu items is more or less duplicated between the old NativeWindow API and Webextensions, with the only real difference being that the former communicates directly via menu item IDs, while the latter uses UUIDs for messaging between Gecko and the UI. By switching the NativeWindow API to using UUIDs as well, we will be able to unify this code again. As for backward compatibility - the return value of NativeWindow.menu.add was valid for the current session only, so no migration would be necessary - the return value of NativeWindow.menu add was already effectively only an opaque value which only had real meaning for subsequent calls to menu.add, menu.update and menu.remove, so it shouldn't really matter whether we return a plain numeric ID or an UUID in string form - old-style add-ons are now unsupported for better or for worse and our one in- tree caller won't have any problems with this change MozReview-Commit-ID: HdRNhrx1pu7
8aab11873e268797ea45b464a7b67bdfc60bf081: Bug 1447299 - Ensure all APZSampler functions run on the sampler thread. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:23 -0400 - rev 771269
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Ensure all APZSampler functions run on the sampler thread. r?botond Functions in APZSampler that are only invoked without WR (e.g. from AsyncCompositionManager only) can be asserted as running on the sampler thread. Functions that are invoked with WR need to be bounced onto the sampler thread. In all cases the functions are called from the compositor thread, and so we assert that as well. MozReview-Commit-ID: 6Xy0QMqnq39
71c22c316850825ad91c32f21c16c42dea9700f8: Bug 1447299 - Bounce PAPZCTreeManager controller messages through the sampler thread. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:23 -0400 - rev 771268
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Bounce PAPZCTreeManager controller messages through the sampler thread. r?botond The methods on PAPZCTreeManagerParent are always invoked on the compositor thread, which currently is always the same as the sampler thread. When it does RunOnControllerThread calls, there is an implicit ordering with respect to the sampler thread, because the controller thread messages are always dispatched *from* the sampler thread. When we move the sampler thread to be the render backend thread, we have to preseve this implicit ordering, but we have to make it more explicit. This patch accomplishes that by introducing a method on APZSampler. MozReview-Commit-ID: 9eYwkNpVkZ1
deb84fcbd209072b009aaa13f96d7e79cdea78c4: Bug 1447299 - Have the APZCTreeManagerParent store a reference to the APZSampler. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:23 -0400 - rev 771267
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Have the APZCTreeManagerParent store a reference to the APZSampler. r?botond MozReview-Commit-ID: LAahjAK9BxT
82138e76aa6e8e716e60886fe9fa9e0b6c588b7f: Bug 1447299 - Move the RunOnControllerThread from APZCTreeManager::SetLongTapEnabled to the caller. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:23 -0400 - rev 771266
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Move the RunOnControllerThread from APZCTreeManager::SetLongTapEnabled to the caller. r?botond This is functionally a no-op (it just moves the thread-bouncing code from inside APZCTreeManager::SetLongTapEnabled to the call site in APZCTreeManagerParent. The other call site, in widget/android/nsWindow.cpp, is already known to be running on the controller thread (which would be the Java UI thread in that case). This makes the code in APZCTreeManagerParent more consistent and simplifies the next changes. MozReview-Commit-ID: 7bDWS9auknL
137ce36e461701ea60e49c38f31768d11f9af3d1: Bug 1447299 - Move the sampler thread util functions from APZThreadUtils to APZSampler. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:23 -0400 - rev 771265
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Move the sampler thread util functions from APZThreadUtils to APZSampler. r?botond Note that this also makes the utility functions instance methods, because each APZSampler might have a different sampler thread instance. MozReview-Commit-ID: ECtfqYCVuTS
9e32ccaacf52d87e3e4d26a0e28ca96f9a1a8a2c: Bug 1447299 - Have the APZCTreeManager keep a pointer to the sampler. r?botond draft
Kartikaya Gupta <kgupta@mozilla.com> - Thu, 22 Mar 2018 16:35:22 -0400 - rev 771264
Push 103646 by kgupta@mozilla.com at Thu, 22 Mar 2018 21:38:36 +0000
Bug 1447299 - Have the APZCTreeManager keep a pointer to the sampler. r?botond MozReview-Commit-ID: 28YcJr5Ure6
a8559a3c2f4ac9d7b37f9aaf09545f50530b59c1: Bug 1397230 - Generalize blocklist clients to remote settings clients r?mgoodwin draft
Mathieu Leplatre <mathieu@mozilla.com> - Tue, 13 Mar 2018 16:23:57 +0100 - rev 771263
Push 103645 by mleplatre@mozilla.com at Thu, 22 Mar 2018 21:35:19 +0000
Bug 1397230 - Generalize blocklist clients to remote settings clients r?mgoodwin MozReview-Commit-ID: 9VAsTFCuZUf
056daa435d4627f924b6ae98a1af689643cab907: Bug 1447354 - Remove talos XUL overlays. r?jmaher draft
Brendan Dahl <brendan.dahl@gmail.com> - Tue, 20 Mar 2018 11:25:38 -0700 - rev 771262
Push 103644 by bmo:bdahl@mozilla.com at Thu, 22 Mar 2018 21:12:26 +0000
Bug 1447354 - Remove talos XUL overlays. r?jmaher Move the scripts and bootstrapping code that was in the overlay into the extension bootstrap file. MozReview-Commit-ID: EIqQnU7rCbq
8bf380faae74e4921be6000496ca09d4a2c44e8d: No bug, Automated HPKP preload list update from host bld-linux64-spot-301 - a=hpkp-update
ffxbld - Thu, 22 Mar 2018 13:22:03 -0700 - rev 771261
Push 103644 by bmo:bdahl@mozilla.com at Thu, 22 Mar 2018 21:12:26 +0000
No bug, Automated HPKP preload list update from host bld-linux64-spot-301 - a=hpkp-update
8e52cfef41eb0283b40e88b051d4f0f3f84751f4: No bug, Automated HSTS preload list update from host bld-linux64-spot-301 - a=hsts-update
ffxbld - Thu, 22 Mar 2018 13:21:59 -0700 - rev 771260
Push 103644 by bmo:bdahl@mozilla.com at Thu, 22 Mar 2018 21:12:26 +0000
No bug, Automated HSTS preload list update from host bld-linux64-spot-301 - a=hsts-update
5c631dda7e1954fbcd7f0bdb97ec23993b76b0ca: Bug 1436665 - Use Net monitor app object for WebExtension API; r=ochameau draft
Jan Odvarko <odvarko@gmail.com> - Thu, 22 Mar 2018 22:08:21 +0100 - rev 771259
Push 103643 by jodvarko@mozilla.com at Thu, 22 Mar 2018 21:09:29 +0000
Bug 1436665 - Use Net monitor app object for WebExtension API; r=ochameau MozReview-Commit-ID: 2eOVxqboMOr
ad6b46b406cf60cdf8738397c2d3305b46f6ac00: Bug 1436665 - Use separate connection for HAR exporter; r=ochameau draft
Jan Odvarko <odvarko@gmail.com> - Thu, 22 Mar 2018 22:08:08 +0100 - rev 771258
Push 103643 by jodvarko@mozilla.com at Thu, 22 Mar 2018 21:09:29 +0000
Bug 1436665 - Use separate connection for HAR exporter; r=ochameau * HAR exporter disables actions in connector and so needs its own connection MozReview-Commit-ID: G06AsadwLnA
3f93d6fee2861a041b537bf9d0ddc2a521c9595a: Bug 1436665 - Introduce Net monitor app object; r=ochameau draft
Jan Odvarko <odvarko@gmail.com> - Thu, 22 Mar 2018 22:06:49 +0100 - rev 771257
Push 103643 by jodvarko@mozilla.com at Thu, 22 Mar 2018 21:09:29 +0000
Bug 1436665 - Introduce Net monitor app object; r=ochameau * The app object can be disconnected from the UI * The app object can be used by WebExtensions API MozReview-Commit-ID: 4VoyobmDAPj
1f4c1192b9ae8382d26fea52e2be4d0dccce9fbd: Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?mcomella draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Mar 2018 21:51:33 +0100 - rev 771256
Push 103642 by mozilla@buttercookie.de at Thu, 22 Mar 2018 20:56:07 +0000
Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?mcomella For a normal load, we get a request start, the various location change/load events and then a stop. When encountering an error (e.g. server not found), the usual event order is start, stop and then the location change/load events while the error page is loading (compare bug 976426). When displaying the "unknown protocol" error page from within the Content- DispatchChooser however, we never receive any onStateChange events from the WebProgressListener. When this happens within an existing tab, this isn't a problem - the UI never thinks that the tab is starting a page load and thanks to bug 976426 never displays the progress bar. When opening a link in a new tab, though, the UI speculatively creates the tab as STATE_LOADING and shows the progress bar. Because we never receive any state change events if the "unknown protocol" error was triggered, especially not a "Stop" event, the progress bar then never gets hidden because the UI assumes that the tab is still loading. To work around this, we make use of the error type that we were still trans- mitting during DOMContentLoaded - if an error page was detected, we reset the tab's load state in the UI and stop the progress bar. We also take this opportunity to change the handling of Content:LoadError messages. Originally, this message was intended to reset the URL bar if an attempt to load an URL resulted in an immediate error in browser.js. For un- known reasons, the rewrite from loading throbber to progress bar changed the meaning of the event to set the progress value of the progress bar to 80 %, just like DOMContentLoaded. With this patch, a Content:LoadError message will immediately stop and hide the progress bar as well. MozReview-Commit-ID: 8AXICB7mEfK
b760bc5ae65d74578093b80da5747529c2c7e90e: Bug 1278581 - Part 3 - Don't load neterror page manually when protocol couldn't be handled. r?snorp draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 21 Mar 2018 22:47:17 +0100 - rev 771255
Push 103642 by mozilla@buttercookie.de at Thu, 22 Mar 2018 20:56:07 +0000
Bug 1278581 - Part 3 - Don't load neterror page manually when protocol couldn't be handled. r?snorp Our current way is somewhat convoluted - we manually create an about:neterror URL in the Android UI and then load it from the ContentDispatchChooser by simply setting window.location.href, which means that the page URL won't reflect the actual URL we were trying to load and the rest of Gecko will think that the page load succeeded (unless they're explicitly checking the URL for the presence of about:neterror). MozReview-Commit-ID: Z0LSSE6AGU
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip