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
Use the global EventDispatcher for signaling update results. The event
listener in about.js must be unregistered after every event to prevent
memory leaks, so expectUpdateResult() is added and called whenever we
are expecting update results.
Although regression window testing pin this to bug 1260276, I believe
this is a regression from bug 1126967. Bug 1260276 just make it more
visible because we stop automatically redirect users to the original
page.
This patch fix the bug by checking if the current page is in readerable
state (i.e. not error state), and send the message accordingly.
MozReview-Commit-ID: B5UJcPvVlAc
--HG--
extra : rebase_source : 630347e1f4256550857d84bc6e8a30036b114362
Session store will be notified in the next patch.
MozReview-Commit-ID: APTJykdnMF2
--HG--
extra : rebase_source : f3cdd3e5529f470834c32d6ae2289a6d272cba67
Every way I've tried to move a browser in the deck results in the browser being
reset (it loses its docShell and contentDocument). So now we treat
deck.children as a set of browsers instead of a list, and make BrowserApp._tabs
the sole keeper of the user visible tabs list order. That means
deck.selectedIndex should no longer be used to get the user visible index of the
currently selected tab (deck.selectedPanel is still valid), and that all
additions to deck can be appends.
Note if this gets reverted at some later date: there's currently a bug, which
this change renders moot, where we reinsert a close-undo tab correctly in the
_tabs list, but incorrectly append it to the deck instead of inserting it.
MozReview-Commit-ID: Id7FR1p1nfN
--HG--
extra : rebase_source : 1506f513e653c67d066601fb9038bee098be9479
Delay-loaded tabs all have browsers pointing to about:blank, so there's not much sense in querying browser.currentURI for them. Instead we read their session data to determine the correct URL, which allows selectOrAddTab to successfully detect duplicate tabs even when they are zombified.
MozReview-Commit-ID: JZ179Y85Ehe
--HG--
extra : rebase_source : bc34d34d501a994ce989c27858cc529b78b5ae3d
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
This patch is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
--HG--
extra : rebase_source : e8f90249454c0779d926f87777f457352961748d
More JPZ leftovers, I presume. In any case what's left doesn't do anything really useful and a DXR search didn't reveal any remaining users, so this can be thrown out.
MozReview-Commit-ID: 9dN6Jifpbvw
--HG--
extra : rebase_source : 04614d729a55e00c5331ecc321ca2ef5b5e73747
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : a9634be57f3f43e30f42431e8a28846d958534ee
Since we don't want to show the media control for the short sound, so we added the duration checking.
And this checking only needs to be run when the media is active, we don't need to check the inactive media.
MozReview-Commit-ID: AaVGi77nXJ1
--HG--
extra : rebase_source : c565fe64ec4030f0519eb0a8cfe493e95bae4fe4
Since BBC website puts their audio in another iframe, we can't get the media
element to check its duration, so we always return false.
The ideal way to fix it is to get every iframe and check its element, but I think
it's not very easy to do considering the flexibility of using iframe and the cost time.
First, if we want to get the information inside iframe, we need to listen the
onload event, but it's async operation. If there are lots iframe, we need to spend
lots time to wait every iframe. The worst situation is we got the nested iframe,
it would need lots time and effect to wait every iframe loaded and get the element we want.
Therefore, I would prefer the workaround which is to reverse the checking condition,
that is we only check duration for the main window.
MozReview-Commit-ID: F93BjbzRMXO
--HG--
extra : rebase_source : 9409649db241b466967ab1e7f467e177c06c728f
I don't think we ever check this attribute in our code and rely on the presence of "__SS_restore" instead, but we should fix this for consistency and any add-ons or future code that might depend on this.
MozReview-Commit-ID: JwB6kpiKsaR
--HG--
extra : rebase_source : a3c98f4c76a67a8c1a42e1740cf09ab121f8f5b5
Even if we do the rest of our location change processing only for top level location changes, we still need to update the state of the back and forward buttons even on subframe navigation, so they can become enabled/disabled as necessary.
MozReview-Commit-ID: 2wuFZMKtTfj
--HG--
extra : rebase_source : 6085fee3818b0ce610f2ddca3f8be0657f355916
We used to need these for the back button long press history menu, but now we no longer do.
MozReview-Commit-ID: LAZYffLODN3
--HG--
extra : rebase_source : b6c10e3dc785230d247587b1a34c3b819424db9c
This should be more foolproof than having to remember to use the dedicated setParentId() function when writing to that variable from outside of the tab constructor.
MozReview-Commit-ID: 1KlXf60VsoF
--HG--
extra : rebase_source : 3ae5234a0113b6077a91e873c7a5e5919b162af3
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : f5ec320bd21dac91bf1baa162aaabae3ced911e3
For components also referencing it in code, see the blockers of bug 1336311.
MozReview-Commit-ID: 4tUZ24HKBWy
--HG--
extra : rebase_source : ec16149f525b9b7eaca7f96f1369929d21497121
Since bug 1228593, the mobile session store
- once again flushes its data when we are quitting, to make sure the latest state (including any potential cleaning of history/tabs) is flushed to disk
- ignores windows/tabs closing as a byproduct of shutdown
The latter point is dependent on a new shutdown notification introduced in that bug. Because we forgot to add that notification to the restart code used for add-on updates, in that case the session store currently doesn't enter shutdown mode and therefore records the window being closed during shutdown before flushing its data to disk, which means that all open tabs are lost.
MozReview-Commit-ID: LgtdQoYwacM
--HG--
extra : rebase_source : 1bf6c544d9e25961a0e64236678ca5938e8a69fe
Convert events used in FindInPageBar to GeckoBundle/BundleEventListener
events. UI thread events are used because the listener performs UI
operations. FindInPageBar also sends some events like "FindInPage:Find"
from Java to Gecko; those events will be converted in another bug.
Convert observers in ActionBarHandler.js to events that go through
WindowEventDispatcher. "TextSelection:Get" now replies through the
callback interface rather than a "TextSelection:Data" event. The patch
also adds new lazy-loading events in browser.js to replace the
lazy-loading observers that ActionBarHandler relied on.
Convert the events used in MediaCastingBar and ChromeCastPlayer to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
A tab object should know how to zombify itself instead of having to rely on the MemoryObserver. This also simplifies the situation for anybody else who wants to call this function since it is no longer necessary to figure out how to load the MemoryObserver for this.
MozReview-Commit-ID: 5IX114QUjBT
--HG--
extra : rebase_source : 964186678848b804e5f0550e1b6a328d7fcfbc50
Actors outside of the session store shouldn't have to poke around within the session store's data structure and end up reimplementing parts of the session store code (and cause data loss if the implementation is incomplete) in order to restore delay loaded zombie tabs. Therefore, we simply expose a method for this via BrowserApp's tab object.
To simplify handling and make the method a little more fool-proof for external callers, the check whether the tab is actually zombified is moved into the restoreZombieTab() function.
Later on, we can also hook up this method to the appropriate web extension API (see bug 1322485).
MozReview-Commit-ID: 85lnbCpMcP3
--HG--
extra : rebase_source : a6f1cfa11debcb18471b49804776521c60655fce
When turning off SPS profiler by configure option, or we build non-SPS arch build such as android/aarch64, Tab.prototype.onStateChange already throws the exception because Profiler isn't defined.
So we should check AppConstants.MOZ_ENABLE_PROFILER_SPS to use Profiler object.
MozReview-Commit-ID: A9ISurxiRmc
--HG--
extra : rebase_source : 25103e97cd4827edef33335e3aec9384a6695526
Convert the "Tab:*" observers in browser.js, which go through the observer
service, to events that go through GlobalEventDispatcher.
FindHelper.js uses "Tab:Selected" through a lazy loader, but I don't
think FindHelper should listen to "Tab:Selected" at all until it is
being used. THerefore, this patch adds "Tab:Selected" registration to
FindHelper.js itself.
Convert events used in Tabs to GeckoBundle/BundleEventListener events.
All of the events are converted to UI thread events, because a lot of
the listeners modify states in Tab (e.g. through
`Tab.handleLocationChange()`), and those states are later accessed on
the UI thread. We used to modify the states on the Gecko thread, and
then access them on the UI thread, which introduces potential race
conditions. Therefore, I think it's best to convert these events
wholesale to UI thread events to avoid races.
Tabs.notifyListeners now calls the listeners directly if it's already on
the UI thread, instead of posting to the UI thread again. This is meant
as an optimization because the events are now coming in on the UI thread
already.
The "Tab:SelectAndForeground" and "Tab:Select" events are merged into
one "Tab:Select" event, and a "foreground" option is added.
The "Tab:StreamStart" and "Tab:StreamStop" events are merged into one
"Tab:RecordingChange" event, and a "recording" option is added to
indicate starting or stopping.
Convert events used in ZoomedView to GeckoBundle/BundleEventListener
events.
"Window:Resize", "Browser:ZoomToPageWidth", and
"Browser:ZoomToRect" listeners are removed because they are not sent
anywhere.
The "Content:LocationChange" listener is merged into the
"Gesture:CloseZoomedView" listener, so that we can leave
"Content:LocationChange" alone for now. Otherwise we would have to
convert the "Content:LocationChange" listener in Tabs as well.
The listeners are changed from global listeners to per-GeckoApp
listeners, because two of the events, "FormAssist:AutoCompleteResult" and
"FormAssist:Hide", are per-GeckoApp events also used by FormAssistPopup.
Because the events are now per-GeckoApp events, they are now registered
from onAttachedToWindow and onDetachedFromWindow.
Convert "FormAssist:*" events in FormAssistPopup to
GeckoBundle/BundleEventListener events. UI thread events are used
because the listener performs operations on the UI thread.
Also convert the "FormAssist:*" observers in browser.js to use
WindowEventDispatcher.
The "FormAssist:AutoComplete" event that goes from Gecko to Java is
renamed to "FormAssist:AutoCompleteResult" to prevent conflict with the
event with the same name that goes from Java to Gecko.
When restoring recently closed tabs during a browsing session, we can just pass the stored parentId as a parameter to addTab and be done with it.
During startup however, we first need to update the parent tab IDs before being able to use it.
At the moment, new tabs are always opened at the end of the tab list and cannot be resorted by the user, so child tabs always appear *after* their parent tabs in the tab list. However because we don't want to rely on this behaviour, we still need to collect a complete mapping between old and new tab IDs first before being able to update the stored parent tab IDs.
Therefore we cannot use the usual method of passing in the parentId during tab creation and have to set it after the fact for this case.
MozReview-Commit-ID: JT5YSkuOSZw
--HG--
extra : rebase_source : 5487f05ed5fd99e12e4f33170688243b36da55e4
Having the previous tab ID in the session store data is required in order to be able to create a mapping between old and new IDs on starting up.
Likewise, the parent ID now needs to be tracked on the Gecko side as well, so it can be saved by the session store and later used when restoring a tab/session.
MozReview-Commit-ID: 3zwoZ9YpZlC
--HG--
extra : rebase_source : 25254f6dbbfbf8291fd1d6dcd194540b15da0cef