If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : 5a1cc56554d1429f3c5af1c8cecaa1d72471ed21
Instead of sending an event through the global EventDispatcher in
GeckoLayerClient, switch to using the per-GeckoView EventDispatcher in
GeckoInputConnection, to handle scroll-to-focused-input-on-resize. This
lets us implement the same functionality for standalone GeckoView.
The patch also fixes some small bugs including unregistering
not-registered events, not scrolling when switching input focus, and
inadvertent scrolling when not showing the keyboard.
MozReview-Commit-ID: 20OZP9dMXtI
--HG--
extra : rebase_source : d9dee0fd8b3d01147b8b2eda5154c380d0f167dd
Pass in the flag names for Tab:OpenUri so we don't have to worry about
synchronizing the flags in Java with ones in C++. r=me for trivial
patch.
MozReview-Commit-ID: BowjLV1s7nT
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : b88ccf98bc2a41aac007d79060424eaa2c2aca88
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : b885ee784704819e181430200af5ef762e269d14
Bug 1345294 introduced nsPrefBranch::{get,set}StringPref(), which allowed the
getting of utf8 strings from prefs, which previously required using
nsISupportsString with {get,set}ComplexValue. That bug also converted most
uses.
This patch finishes the job.
- It removes the nsISupportsString support.
- It converts existing code that relied on the nsISupportsString.
- It removes the lint that was set up to detect such uses of nsISupportsString.
--HG--
extra : rebase_source : fb7af066adfa0491a79fae6282a62b08661553c8
Bug 1297850 removed the only consumer of the background colour on the Java side,
so this can go as well.
MozReview-Commit-ID: DJwrUVUHZ1t
--HG--
extra : rebase_source : be2b5068c57878ff556d1af16eb1df5d5a8779aa
Move the "Bookmark:Insert" and "Image:SetAs" events from GeckoApp to
GeckoApplication. These events are global to the application, and they
operate on the background thread, which will no longer be an option for
the GeckoView event dispatcher.
MozReview-Commit-ID: 8kesv8sJ8At
Remove the native GeckoView loadUri call because it's Fennec-only.
Replace the call with a Fennec-only "Tab:OpenUri" event.
MozReview-Commit-ID: 7xZW9aceoPL
Add a "defaultCallback" option to the doorhanger API that specifies a
callback to call when the doorhanger is dismissed without a button being
clicked. Use that to deny a permission in ContentPermissionPrompt.js
when the doorhanger is dismissed without explicit action.
MozReview-Commit-ID: 9kOAWirI4Ux
This is to avoid a situation where after searching and then navigating to a different URL, the user can already see the new URL (after location change), but not yet edit it (currently, the search term is only dropped after pageshow).
Because location change is too early for checking the documentURI for the presence of an error page in case the load failed, we switch to checking the request's status instead.
We still have to explicitly check for "about:neterror" as well, though, since the way our intent handling code displays an error page in case of an unknown protocol technically counts as a successful pageload.
MozReview-Commit-ID: 8e6WQlD0sf3
--HG--
extra : rebase_source : fa80f45c2bc7b87934907e0386f8c26cd998eb04
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
Change all QIs or instanceof checks against nsIDOMHTMLMediaElement to
check against HTMLVideoElement/HTMLAudioElement.
MozReview-Commit-ID: EpywwFGK33C
--HG--
extra : rebase_source : 3eff2df9580074ed0a71c8fa6750d84a4750fde8
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
The FrameLoaderOwner interface has been implemented in WebIDL for several
years now, so these QIs are simply unnecessary overhead.
MozReview-Commit-ID: LAzvfm5Qhy0
--HG--
extra : rebase_source : 2495c07df21c474f5fabc257ff4db43b0d8047e4
This should have been done when blockedURIs was added (bug 1237198),
when safebrowsing.enabled was renamed (bug 1025965), and when the
forbidden list format was removed (bug 1274893).
MozReview-Commit-ID: AUWR5Efcb2x
--HG--
extra : rebase_source : 990bbd4ba7a6daaa08928a697e72f2d6b5b39a5a
This should have been done when blockedURIs was added (bug 1237198),
when safebrowsing.enabled was renamed (bug 1025965), and when the
forbidden list format was removed (bug 1274893).
MozReview-Commit-ID: AUWR5Efcb2x
--HG--
extra : rebase_source : 533b2e2296d1fe70d6c334bb1766ca26679d224f
Move WebrtcUI loading from browser.js to BrowserCLH.js, so that it can
be loaded without GeckoApp/browser.js being active. Also use the
universal doorhanger API to show the prompts.
MozReview-Commit-ID: Gqsthvn7ZXA
--HG--
extra : rebase_source : 3b3007899bb791b09b35a6a7ab35924468acb6f1
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
The new, preferred solution for displaying additional web content outside of our normal tab infrastructure and UI is to use a separate GeckoView instance. Therefore, the support for different having additional "tab" types that aren't displayed in the normal UI, as well as for multiple GeckoApp instances displaying different tabs is no longer needed and can be removed.
MozReview-Commit-ID: FNx0gJIKybr
--HG--
extra : rebase_source : 4059e03db9586317c9c2928cef1d6dc98406319b
Instead of reading config from about:config, now we read from Android
Preference.
MozReview-Commit-ID: 9yFdknOx8uH
--HG--
extra : rebase_source : c95930357c0e8c191c27d5a35e1c15955ec2d71f
Changes to Promise tests designed to test .then(null) have been reverted, and the browser/extensions directory was excluded because the projects it contains have a separate process for accepting changes.
MozReview-Commit-ID: 1buqgX1EP4P
--HG--
extra : rebase_source : 3a9ea310d3e4a8642aabbc10636c04bfe2e77070
Right now SelectHelper and InputWidgetHelper are loaded in browser.js,
which means they only work for GeckoApp. This patch loads them in
PromptService.js instead, which means they will work in all windows. The
patch also changes some code in SelectHelper and InputWidgetHelper that
used to assume they are running under the browser.xul chrome window.
MozReview-Commit-ID: HveDzIzK1b4
Right now SelectHelper and InputWidgetHelper are loaded in browser.js,
which means they only work for GeckoApp. This patch loads them in
PromptService.js instead, which means they will work in all windows. The
patch also changes some code in SelectHelper and InputWidgetHelper that
used to assume they are running under the browser.xul chrome window.
MozReview-Commit-ID: Jfe6ODyYKVf
Instead of asking for permission in VideoCaptureDeviceInfoAndroid.java,
we now merely check for permission there. The actual permission prompt
now happens in WebrtcUI.js, using the new
"getUserMedia:ask-device-permission" and
"getUserMedia:got-device-permission" notifications.
MozReview-Commit-ID: DSVPjjW2JNR
This patch do 6 things. They are related so I put them in the same patch.
1. Extract MmaEvent Name
2. If MMA is diabled, don't send event.
3. Add check before sending 'Set Default Borwser' deep link
4. Add user attribute for delay messaging focus install status.
5. If the user pref off at runtime, we ask Leanplum to stop and prevent our app sending event to Leanplum.
6. Fix proguard. Only keep necceary files.
MozReview-Commit-ID: APEmr1JXBLH
--HG--
extra : rebase_source : 35b54c11004905c950c1ace84507554a2e1b4f39
This patch do 5 things. They are related so I put them is the same patch.
1. Extract MmaEvent Name
2. If MMA is diabled, don't send event.
3. Add check before sending 'Set Default Borwser' deep link
4. Add user attribute for delay messaging focus install status.
5. If the user pref off at runtime, we ask Leanplum to stop and prevent our app sending event to Leanplum.
MozReview-Commit-ID: APEmr1JXBLH
--HG--
extra : rebase_source : 07913749581b2426f0e5ba3aeb8364b85dbd1b72
This patch do 5 things. They are related so I put them is the same patch.
1. Extract MmaEvent Name
2. If MMA is diabled, don't send event.
3. Add check before sending 'Set Default Borwser' deep link
4. Add user attribute for delay messaging focus install status.
5. If the user pref off at runtime, we ask Leanplum to stop and prevent our app sending event to Leanplum.
MozReview-Commit-ID: APEmr1JXBLH
--HG--
extra : rebase_source : 59c360244bb41467763e3fa11305c00893b7198d
Add event listeners and implement basic messages between chrome and
content so let e10s content in GeckoView request/exit fullscreen. Once
we're on the parent side, we still go through the normal fullscreen flow
so there is no platform or Java change involved.
MozReview-Commit-ID: G1tBIOoFqkB
UAOverridesBootstrapper.js is introduced to delay the initialization of
UserAgentOverrides.jsm until the creation of the first nsHttpChannel.
Uninit will be triggered at profile-change-net-teardown because no network
traffice after this point.
MozReview-Commit-ID: F8Lpn6RyZEm
--HG--
extra : rebase_source : 7c3649b50ad8594dc0968961fbbd2766d0d98b0a
Properly clearing data (history etc.) when shutting down via "Quit" can introduce a possibly noticeable delay (up to the order of a few seconds in bad cases) before the UI actually closes. This patch shows a snackbar for this case, so we don't give users the impression of simply randomly hanging during shutdown.
MozReview-Commit-ID: AqYw8qK8xol
--HG--
extra : rebase_source : 3a1f650dd27ef07ec7eb21dc511decbd94c0a99c
When a non-restartless add-on is (un)installed or updated, we show a doorhanger prompting the user to restart. Currently, the doorhanger's title is using the default logic for choosing its title, that is using the base domain of the tab the doorhanger is being displayed on.
By chance, when the doorhanger is triggered from about:addons there is no domain to display, so the doorhanger is just displaying the restart notification. If however an add-on is automatically updated while the user is browsing, then the restart prompt will show the domain of the currently open tab in conjunction with the restart message. This can be confusing for the user, as it looks like it was in fact the current page that triggered the restart prompt.
Therefore, we change this behaviour and just show a generic "Add-ons" as title for this case.
MozReview-Commit-ID: 3pMwSiLul99
--HG--
extra : rebase_source : 3c11fe19c5cef42226a849b78d554fa846114bfa
We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab.
MozReview-Commit-ID: EJ8RzRzDNAz
--HG--
extra : rebase_source : 2d05c8131a3b25968b36704647a9041b15599668
Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs
- don't appear in our normal tabs UI
- are opened in separate activities
- when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session
Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data.
Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997).
Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk.
Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab.
To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them.
Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work.
MozReview-Commit-ID: 1q5Jtv0DKrE
--HG--
extra : rebase_source : 150e61f2a205e6bc6ea6cf346de0ba42b1935d13
We only want to process the AppEntered/Left message if it actually concerns our currently displayed tab.
MozReview-Commit-ID: EJ8RzRzDNAz
--HG--
extra : rebase_source : 2d05c8131a3b25968b36704647a9041b15599668
Restoring anything other than normal browsing tabs (e.g. custom tabs, web apps) is more involved because those tabs
- don't appear in our normal tabs UI
- are opened in separate activities
- when we're starting up, Android's task switcher might or might not still have available task entries corresponding to such tabs from the last session
Therefore, for now, the session store will simply exclude those kinds of tabs from being saved in the session store data.
Instead of a real restore, if the corresponding tab has been closed or Gecko stopped running, we just recreate the custom tab/web app based on the stored Activity intent data we have available (bug 1352997).
Tab zombification while Gecko is running however remains fully supported, as we continue collecting session history data for all tab types, even if we don't necessarily save it to disk.
Because custom tabs/web apps currently still share a common Gecko browser window with normal tabs, we also have to modify our selected tab tracking logic accordingly, so that selecting one of these special tab types doesn't overwrite the last selected normal browsing tab.
To that effect, we now track the selected tab *ID* in memory and only convert that to a tab index when writing the data to disk. As the ID remains stable while Gecko is running, this makes tracking changes for a sub-group of tabs only easier, as we don't have to watch out for closing tabs of *any* kind affecting the tab index of everything behind them.
Bug 1346008#c3 has some preliminary ideas on how session restoring for custom tabs/web apps could be made to work.
MozReview-Commit-ID: 1q5Jtv0DKrE
--HG--
extra : rebase_source : 150e61f2a205e6bc6ea6cf346de0ba42b1935d13
We can lower the eslint cyclomatic complexity threshold in some directories without adding eslint suppression comments in any .js source files. We need to specify the complexity rule in accessible/.eslintrc because it doesn't inherit the mozilla/recommended rules. eslint's default complexity threshold is 20.
Also bump the eslint-plugin-mozilla version because we modified the mozilla/recommended rules.
MozReview-Commit-ID: 57T4gAjPH7z
--HG--
extra : rebase_source : 4565abfa722b9459cfb4e006e843da13ed7cffd4
extra : intermediate-source : 658588564c08c9fd5e60633d1457f24087de8570
extra : source : 7e0526e3b943419a80c0cd2fa462cabbf8925eb1
That pref isn't set by default, so trying to access it in that case throws a JS error.
MozReview-Commit-ID: 2KIUSztvoXS
--HG--
extra : rebase_source : b2769ba16247db9373c004f152c0e2233fb0652d
This patch replaces the usage of sNextTabParent pointer to store the next
PBrowser parent actor to be used by the next frame loader with the
following information:
* In the case where the content JS has requested a new tab, the ID of the
next TabParent will be stored on the <xul:browser> element.
* In the case where the content JS has requested a new window, the ID of
the next TabParent will be stored on the created nsXULWindow.
This version of the Dynamic Toolbar moves the animation of the toolbar
from the Android UI thread to the compositor thread. All animation for
showing and hiding the toolbar are done with the compositor and a static
snapshot of the real toolbar.
MozReview-Commit-ID: BCe8zpbkWQt
Other events in browser.js are all lower case letter, also change these two to make them consistent.
MozReview-Commit-ID: LkzYUo6OrEA
--HG--
extra : rebase_source : 6853dc40c68c0939d7e318b3a1e88c39495d0648
We could register media control related event after the tab has active media.
But we still need to register "audioFocusChange" in the beginning, because it
affect every tab even the tab has no active media.
MozReview-Commit-ID: ErIBUobnxbg
--HG--
extra : rebase_source : bdc8070f2f2a81f847ebb8e0ec87f6efeb86eb80
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 883a91b249b6953b7872bfb9a8851e8be7257c7b
I'm adding a helper function mozILocaleService::GetRequestedLocale to simplify
most of the callsites that are looking for the first of the requested locales.
In most cases, I'm just matching the behavior of the code with reusing
LocaleService API instead of direct manipulation on the prefs.
That includes how I handle error case scenarios.
In case of sdk/l10n/locale.js I am reusing LocaleService heuristics over
the custom one from the file since the ones in LocaleService are just
more correct and unified accross the whole platform.
In case of FallbackEncoding I have to turn it into a nsIObserver to listen
to intl:requested-locales-changed.
MozReview-Commit-ID: 7rOr2CovLK
--HG--
extra : rebase_source : 2f166cf1746f389a035f7cf557edcadeacb10fa0
Samael Wang
Jim Chen
Cosmin Sabou
Gijs Kruitbosch
Noemi Erli
Ciure Andrei
Dave Townsend
Nicholas Nethercote
Narcis Beleuzu
Jan Henning
Sebastian Hengst
Mark Banner
Dylan Roeh
Nevin Chen
Kyle Machulis
Dan Banner
Jing-wei Wu
Eugen Sawin
Andrew Swan
Richard Newman
Luca Greco
Zibi Braniecki
Michael Comella
James Willcox
Kris Maglione
Francois Marier
Wes Kocher
Masatoshi Kimura
Henry Chang
Rajesh Kathiriya
Thomas Nguyen
Sylvestre Ledru
Johann Hofmann
Florian Quèze
Julian_Chu
Matthew Wein
Christoph Kerschbaumer
Frederik Braun
Ehsan Akhgari
Paolo Amadini
Michael Layzell
Varun Iyer
Nevin Chen
Shih-Chiang Chien
Michael Kaply
Chris Peterson
Carsten "Tomcat" Book
Randall Barker
Alastor Wu
Zibi Braniecki