e53c3086489e2b6e0e8f0e48a1bb9b107e3d19f3: Bug 1348273 - Convert the network-related annotations; r?mcmanus draft
Gabriele Svelto <gsvelto@mozilla.com> - Sat, 17 Mar 2018 00:17:40 +0100 - rev 775277
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the network-related annotations; r?mcmanus MozReview-Commit-ID: FG1RRjC1lZR
597a51280f85b14db40d26111f4fede94ed1ffc6: Bug 1348273 - Convert the XPCOM annotations; r?froydnj draft
Gabriele Svelto <gsvelto@mozilla.com> - Sat, 17 Mar 2018 00:11:05 +0100 - rev 775276
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the XPCOM annotations; r?froydnj MozReview-Commit-ID: EQZsx3phBoe
c2f2fbd827be6cace544af0856e48cf208227c4b: Bug 1348273 - Convert the telemetry annotations; r?Dexter draft
Gabriele Svelto <gsvelto@mozilla.com> - Sat, 17 Mar 2018 00:07:22 +0100 - rev 775275
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the telemetry annotations; r?Dexter MozReview-Commit-ID: GxeACvkWbYO
a5d07c3759e06586cff0577b6e8073589d8590b9: Bug 1348273 - Convert the graphics annotations; r?jrmuizel draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 23:57:43 +0100 - rev 775274
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the graphics annotations; r?jrmuizel This patch also removes some crash notes whose contents are already gathered through annotations and surfaced via Socorro. MozReview-Commit-ID: L5tDNEgRLw0
1dcb64b45ecac7a8bf5a7b97ca6c9c919dca3a09: Bug 1348273 - Convert the Android-specific annotations and use the machine-generated whitelist in the crash reporter; r?jchen draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 23:15:50 +0100 - rev 775273
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the Android-specific annotations and use the machine-generated whitelist in the crash reporter; r?jchen MozReview-Commit-ID: 7A5bmBdBQ08
0d04784d9cbd75551578e83dc8de6441c04955f1: Bug 1348273 - Convert the IPC-related annotations; r?jimm draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 21:50:51 +0100 - rev 775272
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the IPC-related annotations; r?jimm MozReview-Commit-ID: LIywhQ0y08O
979050125263741b78b8d3ed76dc24e110ffd092: Bug 1348273 - Convert the docshell and XPConnect-related annotations; r?bz draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 21:29:16 +0100 - rev 775271
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the docshell and XPConnect-related annotations; r?bz MozReview-Commit-ID: 7ACJI5xWOsa
e2e0d60bab8ab2d37019fcbb89d634dc18c74bd1: Bug 1348273 - Convert the accessibility annotations; r?surkov draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 21:21:08 +0100 - rev 775270
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Convert the accessibility annotations; r?surkov MozReview-Commit-ID: 8PaNpnD7KVU
48c8a9a8a8afa6db74cc753ec5ec6ebf6392d163: Bug 1348273 - Implementation of machine-generated crash annotations; r?ted.mielczarek draft
Gabriele Svelto <gsvelto@mozilla.com> - Fri, 16 Mar 2018 21:04:39 +0100 - rev 775269
Push 104678 by gsvelto@mozilla.com at Fri, 30 Mar 2018 19:30:59 +0000
Bug 1348273 - Implementation of machine-generated crash annotations; r?ted.mielczarek This patch introduces the machinery to generate crash annotations from a YAML file. The relevant functions are updated to take a typed enum (in C++) and an integer constant (in JavaScript). Once written out to the .extra file the annotations are converted in string form and are no different than the existing ones. The existing whitelists and blacklists of annotations are also generated from the YAML file and the existing duplicate code has been consolidated. MozReview-Commit-ID: 7bmnkxNphAN
e2c1c32ad93c89736419be9d8afb7f05adcfde89: Bug 1450323 - Debugger: Update Pause Points. r=jimb draft
Jason Laster <jason.laster.11@gmail.com> - Fri, 30 Mar 2018 14:36:33 -0400 - rev 775268
Push 104677 by bmo:jlaster@mozilla.com at Fri, 30 Mar 2018 19:17:32 +0000
Bug 1450323 - Debugger: Update Pause Points. r=jimb
175e61756bc91e20e35d2aa9fa9a363d7a3daf03: Bug 1434711 - WebGL causes a crash with the AMDGPU-PRO video driver. draft
Gian-Carlo Pascutto <gcp@mozilla.com> - Thu, 29 Mar 2018 14:04:46 +0200 - rev 775267
Push 104676 by bmo:gpascutto@mozilla.com at Fri, 30 Mar 2018 19:16:35 +0000
Bug 1434711 - WebGL causes a crash with the AMDGPU-PRO video driver. MozReview-Commit-ID: FrRpicj5NF
a8bcb7c80429b508014a5781bb5375a19e54347d: Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Mar 2018 21:51:33 +0100 - rev 775266
Push 104675 by mozilla@buttercookie.de at Fri, 30 Mar 2018 19:09:15 +0000
Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin 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
c1bb1f245f7578f260eeab230a479539c01c5ecc: 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 775265
Push 104675 by mozilla@buttercookie.de at Fri, 30 Mar 2018 19:09:15 +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
99d86f385510fd7a50cba892ab2601d53c25fd9f: Bug 1278581 - Part 2 - Ensure a stray key-up event doesn't end up in Gecko after committing the URL bar input. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 21 Mar 2018 20:44:31 +0100 - rev 775264
Push 104675 by mozilla@buttercookie.de at Fri, 30 Mar 2018 19:09:15 +0000
Bug 1278581 - Part 2 - Ensure a stray key-up event doesn't end up in Gecko after committing the URL bar input. r?jchen When editing the URL bar, we're committing the input and starting a page load in response to a key-down event for the Enter key. We end up hiding the ToolbarEditLayout from within the key event handler, which means that by the time we get the corresponding key-up event, input focus has moved on and the key event ends up being dispatched to the GeckoView and consequently to Gecko. This means that loading an URL from the URL bar by pressing Enter will reset millisSinceLastUserInput, which defeats our logic to distinguish URLs loaded via the Android UI from those loaded by clicking on links within the content. MozReview-Commit-ID: 3Wbnk3bnqVS
1dcb8ac8cd0af3bf0c3563219c24d48c33e70eba: Bug 1444965 - Fix search composition migration for beta and nightly. r?mak,mythmon draft
Drew Willcoxon <adw@mozilla.com> - Fri, 30 Mar 2018 11:55:38 -0700 - rev 775263
Push 104674 by bmo:adw@mozilla.com at Fri, 30 Mar 2018 18:56:12 +0000
Bug 1444965 - Fix search composition migration for beta and nightly. r?mak,mythmon MozReview-Commit-ID: 1uJnSImEBVx
eb195c3b3933aea89f46aa83bf382d41ca103c5b: Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Mar 2018 21:51:33 +0100 - rev 775262
Push 104673 by mozilla@buttercookie.de at Fri, 30 Mar 2018 18:49:14 +0000
Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin 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
e976a8e62baa984fbb23a3be17437e3f3a2b8db3: 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 775261
Push 104673 by mozilla@buttercookie.de at Fri, 30 Mar 2018 18:49:14 +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
ab10a92a23ab7f4a38d255e56ad40db2b59a094d: Bug 1278581 - Part 2 - Ensure a stray key-up event doesn't end up in Gecko after committing the URL bar input. r?jchen draft
Jan Henning <jh+bugzilla@buttercookie.de> - Wed, 21 Mar 2018 20:44:31 +0100 - rev 775260
Push 104673 by mozilla@buttercookie.de at Fri, 30 Mar 2018 18:49:14 +0000
Bug 1278581 - Part 2 - Ensure a stray key-up event doesn't end up in Gecko after committing the URL bar input. r?jchen When editing the URL bar, we're committing the input and starting a page load in response to a key-down event for the Enter key. We end up hiding the ToolbarEditLayout from within the key event handler, which means that by the time we get the corresponding key-up event, input focus has moved on and the key event ends up being dispatched to the GeckoView and consequently to Gecko. This means that loading an URL from the URL bar by pressing Enter will reset millisSinceLastUserInput, which defeats our logic to distinguish URLs loaded via the Android UI from those loaded by clicking on links within the content. MozReview-Commit-ID: 3Wbnk3bnqVS
907caa72bf2bd198fa8b5a1d812fbcba0c2a0370: Bug 1450323 - Debugger: Update Pause Points. r=jimb draft
Jason Laster <jason.laster.11@gmail.com> - Fri, 30 Mar 2018 14:36:33 -0400 - rev 775259
Push 104672 by bmo:jlaster@mozilla.com at Fri, 30 Mar 2018 18:43:56 +0000
Bug 1450323 - Debugger: Update Pause Points. r=jimb
05f66903ea10f80b31f11134f402e2f5f806c7f6: Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin draft
Jan Henning <jh+bugzilla@buttercookie.de> - Thu, 22 Mar 2018 21:51:33 +0100 - rev 775258
Push 104671 by mozilla@buttercookie.de at Fri, 30 Mar 2018 18:41:23 +0000
Bug 1278581 - Part 4 - Ensure the progress bar doesn't get stuck after displaying the error page. r?esawin 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
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip