This is a "hacked" fix. The key idea is to specify the value in manifest on "add to home screen confirm prompt."
We need to reuse prefetch result for manifest.install().
The plan is to land this patch before Chrome Dev Summit(10/30) for demostration and fix the rest of the issue in a follow up bug.
MozReview-Commit-ID: A4B0ZK7UjyK
--HG--
extra : rebase_source : a91a490a08cb4ec18e5ff9f2e78f11efa6fdd98b
Since the pref flip in bug 1380617, the default nsUri attributes have been returning punycode for IDN-based domain names, so we need to switch to using the "display"-prefixed variants as a simple fix to
- preserve compatibility with previously stored logins
- pretty-print unicode domains in the login manager UI instead of showing punycode
This patch is more or less a straight (DXR-)search and replace and has hopefully caught all relevant instance of nsUri access related to logins.
For test_disabled_hosts, we're basically reverting bug 1380617, since the login service will now once again return IDN domains in Unicode where allowed.
MozReview-Commit-ID: 5SvW0MuTrGu
--HG--
extra : rebase_source : 02e4414c72b86d6bebf368f9a79a70d144575493
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
"getEffectiveHost" further down expects the URI to be available - apparently this was broken ever since the original implementation.
MozReview-Commit-ID: C1Q6PBYcvk3
--HG--
extra : rebase_source : 5e71c300261ba9cbaff7e006ce22637c29596680
To avoid mismatches between the Unicode and Punycode versions of a domain, we should normalise the "appOrigin" that can get stored as part of a tab's extra session store data.
To that extent, we move the code that stores the appOrigin into the Tab object's constructor, so we don't have to parse the URL twice.
MozReview-Commit-ID: KFr8CeeOYTe
--HG--
extra : rebase_source : 4494ed02047b33c187143f3789ed663e5022bf35
The URL can end up being user-visible for "Recently closed tabs" (certainly on Android, and also when hovering over an entry on Desktop, at least in the old menu bar), so we should use pretty URLs instead of Punycode.
MozReview-Commit-ID: Kil2ChToYa8
--HG--
extra : rebase_source : 937332a852c6814317cdc58473437e3bc77faf15
Amongst others, this includes some prompts, as well as various progress messages sent to the Java UI.
We also fix getTabWithURL to be able to find tabs regardless of whether the given URL to search is written in Punycode or with Unicode characters.
MozReview-Commit-ID: K7xhgz2IK2h
--HG--
extra : rebase_source : cf8a56ef84be77a6c01d7c926b7eae43a20ca453
Change the subscripts (e.g. FormAssistant.js) that we load in BrowserCLH
into proper .jsm modules. This avoids the `defineLazyScriptGetter`
incompatibility mentioned in the bug, and when we turn on shared JSM
global, any memory advantage we get from using subscripts should not
matter anymore.
MozReview-Commit-ID: krSwANdtb5
--HG--
rename : mobile/android/chrome/content/ActionBarHandler.js => mobile/android/modules/ActionBarHandler.jsm
rename : mobile/android/chrome/content/FormAssistant.js => mobile/android/modules/FormAssistant.jsm
rename : mobile/android/chrome/content/InputWidgetHelper.js => mobile/android/modules/InputWidgetHelper.jsm
rename : mobile/android/chrome/content/SelectHelper.js => mobile/android/modules/SelectHelper.jsm
rename : mobile/android/chrome/content/WebrtcUI.js => mobile/android/modules/WebrtcUI.jsm
extra : rebase_source : fa361c9eeea38485ba6a8f6c49321c32304d4006
Use ActionBarHandler in BrowserCLH.js instead of browser.js, so it can
handle text selection for all windows. Also update ActionBarHandler to
reflect the new usage and to support multiple windows.
MozReview-Commit-ID: G8sKu2XyAAG
Use event callbacks instead of separate events to deliver
FormAssistPopup replies back to FormAssistant. This lets us better
handle having multiple FormAssistPopup instances across Fennec, custom
tabs, and PWAs.
FormAssistant._currentInputElement is removed because it does not allow
us to have multiple concurrent popups. Instead, we track the current
element through the event callback closure.
FormAssistant._currentInputValue is also removed for similar reasons,
and I don't think it was really necessary.
MozReview-Commit-ID: DdeMBGCxDou
To support FormAssistPopup in custom tabs, we need to move the
FormAssitant object out of browser.js and into its own separate file.
BrowserCLH.h in turn loads FormAssistant.js when necessary.
MozReview-Commit-ID: 7CFQ9R16P4J
Move the form fill event listeners out of browser.js and into
BrowserCLH.js, and update them to support chrome windows, so we can
handle form fill events for Fennec, custom tabs, and PWAs.
MozReview-Commit-ID: Fb5gWmGvxfE
Use the BrowserCLH for PromptService startup, to consolidate startup
handling code and also to delay loading PromptService.
MozReview-Commit-ID: 25UgVH7wrrs
Move `addLazyGetter` and `addLazyEventListener` utility functions from
GeckoViewStartup.js into GeckoViewUtils.jsm, so they can be used for
both Fennec and standalone GeckoView.
Also switch to "chrome-document-loaded" for loading
DownloadNotifications because that's later in the startup sequence.
MozReview-Commit-ID: 1caMtufkHGR
The mechanics implemented here involve listening for extension updates that
require new permissions, notifying the user with icons attached to the
top level Add-ons menu and to the individual item in about:addons, and
then showing the permissions dialog when the user asks to update.
The basic plumbing is mostly in ExtensionPermissions.js, this also
required a fair amount of change to aboutAddons to accomodate new UI
elements, and to handle updates gracefully.
MozReview-Commit-ID: Jkgc3OVYtnc
--HG--
extra : rebase_source : 5df3e12df8c422285fbc25c459dc420b395fa824
This ensures that `intl.locale.os` is always set, even if the system locale changes
while Fennec is in the background.
This commit also restores `Strings.flush()` calls that are necessary to have Fennec's
non-Java UI reflect locale changes.
With this commit, the geolocation popup still doesn't behave correctly: when the
locale system is set to match OS locale, although the pref is set the locale doesn't
change. This applies in two scenarios: on first run (the popup is always English)
and when the locale changes at runtime (the popup uses an earlier OS locale).
Bug 1397925 should complete the fix.
MozReview-Commit-ID: 8zeZuYXFYdy
--HG--
extra : rebase_source : 9da9aae7ed8420faa7567c9db29b1110b3289d9f
Lazily load AndroidLog.jsm since we only need it for debug logging, and
logging is normally turned off in GeckoView code.
MozReview-Commit-ID: 5HNzYTwujMS
--HG--
extra : rebase_source : f6902e25a445d29001f93e024e7cc82fddbb58f2
Move AsyncPrefs initialization to inside browser.js to only load it for
Fennec. Also, delay initialization until later in startup.
MozReview-Commit-ID: 7gLaXA5UJud
--HG--
extra : rebase_source : c71edca4a13f3de785e06f2e0a249ff80fd8c1d4
Lazily load AndroidLog.jsm since we only need it for debug logging, and
logging is normally turned off in GeckoView code.
MozReview-Commit-ID: 5HNzYTwujMS
--HG--
extra : rebase_source : 5ef9bbe21ff1a53bc0e805f473154e1cf60d3b08
Move AsyncPrefs initialization to inside browser.js to only load it for
Fennec. Also, delay initialization until later in startup.
MozReview-Commit-ID: 7gLaXA5UJud
--HG--
extra : rebase_source : c721bbc6c9340f65161c415405dfba16e527b962
This will allow us to call Tabs.loadUrl with a referrer URI from the Pocket top
stories.
MozReview-Commit-ID: IGdoTo80SGG
--HG--
extra : rebase_source : 52c616720fb1735e593f02330d1dd02db45f501f
In order to show download notifications, we need to initialize the
DownloadNotifications module outside of browser.js. This patch moves
initialization to BrowserCLH.js, and includes a refactoring of the
`addObserverScripts` function. The "chrome-document-interactive"
notification is used to trigger initialization because it is roughly
equivalent to where we used to initialize the module inside browser.js.
MozReview-Commit-ID: 8o1KZWRt69K
--HG--
extra : rebase_source : a588a4e0933069bbbde00dc07c97141c889dfc81
Use tint to provide two colors for page action icon in normal/private mode.
We would not tint icons that already have their own colors(for example: ic_readermode_on.png or casting_active.png)
or are came from 3-party addons.
MozReview-Commit-ID: 8uuMucKGLw5
--HG--
extra : rebase_source : 7d213e2b96fab8389b2b2c69e1fdb8ecfe569f20
extra : intermediate-source : ee7c5cecab194ae54317d77de05b2e2f84e1122e
extra : source : a97a2b9700a27e944691536adec6112451ff1f24