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
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
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
