Bug 1348273 - Convert the network-related annotations; r?mcmanus MozReview-Commit-ID: FG1RRjC1lZR

Bug 1348273 - Convert the XPCOM annotations; r?froydnj MozReview-Commit-ID: EQZsx3phBoe

Bug 1348273 - Convert the telemetry annotations; r?Dexter MozReview-Commit-ID: GxeACvkWbYO

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

Bug 1348273 - Convert the Android-specific annotations and use the machine-generated whitelist in the crash reporter; r?jchen MozReview-Commit-ID: 7A5bmBdBQ08

Bug 1348273 - Convert the IPC-related annotations; r?jimm MozReview-Commit-ID: LIywhQ0y08O

Bug 1348273 - Convert the docshell and XPConnect-related annotations; r?bz MozReview-Commit-ID: 7ACJI5xWOsa

Bug 1348273 - Convert the accessibility annotations; r?surkov MozReview-Commit-ID: 8PaNpnD7KVU

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

Bug 1450323 - Debugger: Update Pause Points. r=jimb

Bug 1434711 - WebGL causes a crash with the AMDGPU-PRO video driver. MozReview-Commit-ID: FrRpicj5NF

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

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

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

Bug 1444965 - Fix search composition migration for beta and nightly. r?mak,mythmon MozReview-Commit-ID: 1uJnSImEBVx

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

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

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

Bug 1450323 - Debugger: Update Pause Points. r=jimb

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