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
CLOSED TREE
Backed out changeset 4ac559eea9ec (bug 1348803)
Backed out changeset 2ab6e0b8aec6 (bug 1348803)
Backed out changeset f966aef934b1 (bug 1348803)
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 : 8b134332e32cae29a1f963e604f2507433c694b8
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: 4pBKIR8F5tV
--HG--
extra : rebase_source : fc26c98ed7b33552b4eba5b20168394b1b1a4390
This commit adds a check for not prompting the user in case
the permissions have already been granted for accessing
file:// uris
MozReview-Commit-ID: A62AUqqTJSb
--HG--
extra : rebase_source : c5109c2fede109e1942cce240e26b12a220e8574
We are going to need this in the future and starting collection even before releasing
Activity Stream will create a better experience once we turn it on.
And this flag is hard to miss. So let's just get rid of it.
MozReview-Commit-ID: 5oDzXhpQdSA
--HG--
extra : rebase_source : c96800257070af9287d5236625150dbb62985c4b
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
--HG--
extra : rebase_source : 745c0d66c3afd8e487c616891c0f10bd820da1fe
If location change to some special scheme, we might misuse the
location to parse domain. Now only get base domain from host if
the scheme is recognized.(http/https/ftp)
MozReview-Commit-ID: 4MkrNfsUJqQ
---
mobile/android/chrome/content/browser.js | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
--HG--
extra : rebase_source : d7acb12c3e7498a8bc8a03e40727fbe050616df2
This'll allow customising context menu/session store/... behaviour in Gecko depending on the tab type, since in the future we might not only have special behaviour for custom tabs, but for web app tabs etc. as well.
MozReview-Commit-ID: LS6oGfO4KpR
--HG--
extra : rebase_source : 677a013a05cc683cae82c84864509d8f4799b474
As long as the tabs are opened in the same Gecko browser window, splitting the Java UI tabs list into multiple parts breaks too many assumptions, so the easier solution is to allow setting a type attribute on each tab object, which will allow filtering of them later on.
MozReview-Commit-ID: 1PbxMkWTK47
--HG--
extra : rebase_source : ea7b82271b681e04590046a1d5cf9c2230729781
To gauge the impact of bug 1343995 on perceived shutdown times, we want to measure how long sanitising actually takes in practice on Android.
MozReview-Commit-ID: 3gSfT8IoO70
--HG--
extra : rebase_source : 19ffdfbf1005ae4beebaa0c9d8befea31e1aa01f
Merge "DOMServiceWorkerFocusClient" & "DOMWebNotificationClicked"
to "DOMWindowFocus" event. Utilize the event to switch tab when
loading links to an existing target tab.
MozReview-Commit-ID: Hd1NkVkrJA1
