author Jan Henning <jh+bugzilla@buttercookie.de>
Thu, 07 Feb 2019 20:41:16 +0000
changeset 512996 95b884dcbd6f001b990a6353980280050fab9ac6
parent 97770 d37d4edce6dd592f04afa606deb1ae327c07b4a4
child 542548 0cb5b1fca65d933c683e6eb4b54183db15eee0ee
permissions -rw-r--r--
Bug 1496684 - Dispatch commonly expected startup notifications when opening a GeckoView window. r=snorp a=lizzard Once a webextension using a blocking WebRequest listener has started loading, all network connections covered by the extension's manifest are held until the extension is ready the process them. One condition for the extension being ready apparently includes browser startup having progressed far enough, as signified by "browser-delayed-startup-finished" having been dispatched. Therefore, we have to start sending that notification when opening a new Gecko- View window, too, and copy Fennec's InitLater() system for that. Unlike Fennec, we cannot tie registration of those InitLater() runnables to the initial content load having progressed far enough because of a) e10s, which makes that approach neither easily possible nor really sensible, as content will load in a different process in that case, and b) because we're racing with extension startup here - if extensions are loaded quick enough to block even the initial page load, we'd be deadlocked: We cannot send the notification until the page finishes loading, but the page cannot load until we send the notification. Fennec isn't affected by the latter problem because "sessionstore-windows-restored", which Fennec will send in any case, serves as an alternative pathway for completing extension startup. And unlike Desktop, we don't really have any chrome content to paint, so we cannot tie delayed initialisation to a paint listener for that, either. Therefore, we simply fire off a runnable at the *end* of geckoview.js's startup() method, which should give more pressing initialisation tasks enough of a headstart. For completeness, we're also adding the "browser-idle-startup-tasks-finished" notification and thereby solve bug 1465832 as well, allowing the ScriptPreloader to detect which scripts are commonly loaded during GeckoView startup and to start caching and pre-parsing them. Differential Revision: https://phabricator.services.mozilla.com/D18865

# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

# -----------------------------------------------------------------
# symlinks.sh -- create links from NSPR builds
# syntax: symlinks.sh
# Description:
# symlinks.sh creates some symbolic links for NSPR build targets
# that are not actually build, but for which there are NSPR
# binaries suitable for running on the intended target. ... got
# that?
# Suggested use: After copying NSPR binaries to
# /s/b/c/nspr20/<platform> run symlinks.sh to create the links
# for all supported platforms.
# The symlinks in this script correspond to the NSPR 4.1.1
# release. Adjust as necessary.
# -----------------------------------------------------------------

ln -s SunOS5.6_DBG.OBJ SunOS5.7_DBG.OBJ
ln -s SunOS5.6_OPT.OBJ SunOS5.7_OPT.OBJ

ln -s SunOS5.6_DBG.OBJ SunOS5.8_DBG.OBJ
ln -s SunOS5.6_OPT.OBJ SunOS5.8_OPT.OBJ

ln -s SunOS5.7_64_DBG.OBJ SunOS5.8_64_DBG.OBJ
ln -s SunOS5.7_64_OPT.OBJ SunOS5.8_64_OPT.OBJ


# --- end symlinks.sh ---------------------------------------------