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
I missed this part of the code when refactoring the icon code in bug 1290014 - because this code
never used our favicon loader but instead accessed the database directly. Now this code is using
the same pipeline we use from Java code and should therefore always load (or generate) an icon.
MozReview-Commit-ID: 9WPvTW1uscI
--HG--
extra : rebase_source : 8f07cb040c0fb7d5b33dbd3ae47ec4a4df8668f0
Convert events used in the two JavaAddonManager implementations to
GeckoBundle/BundleEventListener events. Gecko thread events are used to
keep with previous behavior. The external interface for addons is kept
the same (using Bundle/JSONObject as container objects), in order to
preserve compatibility, while the internal implementation is changed to
use GeckoBundle.
When clearing private data on exit, Gecko sends a "Sanitize:ClearHistory" message back to the Java UI, so the latter can clear the history DB if necessary.
For some users, this process is not working, presumably because there is a race condition depending on whether Gecko gets as far as sending that message before the background thread responsible for receiving that message has already shut down/had its listener unregistered, or not.
Therefore, we now wait until the UI's sanitize handlers have been called before starting to shut it down as well.
MozReview-Commit-ID: HoifMYv3spA
--HG--
extra : rebase_source : de4bb656c67104b9d5b1ea83329b77de0688a5d6
The notification bar will be dimmed if in Reader Mode and user scroll
down the page. If not in Reader Mode, make sure the notification bar is
not dimmed.
MozReview-Commit-ID: 87LisdS3nRO
--HG--
extra : rebase_source : c7a6795a2b9b007aeddbee1044f94168a03cd761
Convert the "TextSelection:*" events to use BundleEventListener /
GeckoBundle, in both ActionBarTextSelection.java and
FloatingToolbarTextSelection.java. UI events are used because the
listeners require the UI thread. The "TextSelection:Update" listeners
are removed because the event is no longer sent by ActionBarHandler.
Convert "Doorhanger:Add" and "Doorhanger:Remove" to bundle events. UI
events are used because the listener performs UI operations. As part of
the refactoring, DoorHangerConfig was refactored to use GeckoBundle, and
due to that change, a lot of other doorhanger-related classes also had
to be refactored to use GeckoBundle.
Doing QI from nsIEditor to nsIEditorIMESupport doesn't make sense because editor should always support all methods and attributes of nsIEditorIMESupport (it does NOT mean that all nsIEditor implementation need to support IME).
This patch moves all of them to nsIEditor for avoiding redundant QIs.
MozReview-Commit-ID: DzIKuGHG4iy
--HG--
extra : rebase_source : cc5e9a6ae4572ebe461d9770ffa5c23d33dc8526
Convert "SearchEngines:Data" to use BundleEventListener/GeckoBundle,
including usages in BrowserSearch, SearchPreferenceCategory,
testAddSearchEngine, testDistribution, etc. Also, convert JSON parsing
code in various classes. UI thread is used because the event listeners
perform various UI operations based on the event data.
Convert events that are only used in robocop tests to Bundle events,
which are then used through Actions.expectGlobalEvent /
expectWindowEvent.
"Content:" prefix is added to "DOMContentLoaded" to follow the event
naming convention.
SelectionHandlerTest.java is removed because it's no longer used
anywhere.
Bug 1321418 - 1. Use GekcoBundle events in GeckoApp; r=snorp r=sebastian
Switch GeckoApp to using GeckoBundle events everywhere. UI or Gecko
events are used if the event requires the UI or Gecko thread,
respectively, and background events are used for all other events.
There are changes to some other Java classes, such as SnackbarBuilder
and GeckoAccessibility, due to the switch to GeckoBundle.
For "Snackbar:Show", we need the global EventDispatcher because the
event can be sent to both GeckoApp and GeckoPreferences. Howveer, we
only want one listener registered at the same time, so we register and
unregister in GeckoApp's and GeckoPreferences's onPause and onResume
methods.
Bug 1321418 - 2. Use appropriate JS EventDispatcher to send GeckoApp events; r=snorp r=sebastian
Change JS code that sends events to GeckoApp to use either the global
EventDispatcher or the per-window EventDispatcher.
"Session:StatePurged" is not used so it's removed. "Gecko:Ready" in
geckoview.js is not necessary because it's only used for GeckoApp, so
it's removed from geckoview.js.
Bug 1321418 - 3. Use GeckoBundle events in BrowserApp; r=snorp r=sebastian
Switch BrowserApp to using GeckoBundle events, in a similar vein as
GeckoApp. UI or Gecko events are used if the event handlers required UI
or Gecko thread, respectively, and background events are used for all
other events.
Some other Java classes also have to be modified as a result of
switching to GeckoBundle.
Bug 1321418 - 4. Use global EventDispatcher to send BrowserApp events; r=snorp r=sebastian
Change JS code that sends events to BrowserApp to use the global
EventDispatcher instead of "Messaging".
Bug 1321418 - 5. Update usages of events in tests; r=gbrown
Update cases where we use or wait for events in tests.
Context menu items used UUIDs as their prompt list item IDs. However,
prompt list items only support integers as IDs. This error didn't show
up before because JSONObject was silently ignoring the error. This patch
changes to using an incremental integer as the ID and fixes the error.
The idea is that cancelling edit mode when opening a new tab implies that we want to select it as well, otherwise we wouldn't have to cancel edit mode in the first place.
MozReview-Commit-ID: Gova1ymzlHn
--HG--
extra : rebase_source : a1d957de82a5e1ec9bf9162e1f01641e34e16ab4
This can happen if the users sets browser.sessionstore.max_tabs_undo to 0 - with no closed tabs available, without this fix the resulting exception breaks browser.js's closed tab handling, meaning the tab gets closed in the UI but not in Gecko.
MozReview-Commit-ID: 7yMyIB6UzAB
--HG--
extra : rebase_source : 37ca55519b30cbd5d263127d3ecd6b893ccfafc9
Add a new EventDispatcher interface to Messaging.jsm, and provide means
to access either the global EventDispatcher through
EventDispatcher.instance or a per-window EventDispatcher through
EventDispatcher.for(window). The old Messaging object is retained until
we can convert all existing uses of it in Fennec to use EventDispatcher,
at which point `Messaging` will be made to point to
`EventDispatcher.instance`.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
This patch removes support for mozapp iframes, leaving support for
mozbrowser iframes intact. Some of the code has been rewritten in order
to phrase things in terms of mozbrowser only, as opposed to mozbrowser
or app. In some places, code that was only useful with apps has been
completely removed, so that the APIs consumed can also be removed. In
some places where the notion of appId was bleeding out of this API, now
we use NO_APP_ID. Other notions of appId which were restricted to this
API have been removed.
For the short sound, we don't want to show the media control interface for them, eg. game effect.
Therefore, we check the media's duration to decide whether need to notify Java side "Tab:MediaPlaybackChange" or not.
MozReview-Commit-ID: 8PlQl2w2BSI
--HG--
extra : rebase_source : c4e5d38eae1dba22af268ea575dd6c9672e7cf9f
When user resumes media from the page, we should notify MediaControlService so
that it can change the playing icon to the correct status.
MozReview-Commit-ID: 15e2GrxvB6a
--HG--
extra : rebase_source : 3bb6714c6c8e10d83a629dc7dd55d6e8a3070b0f
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
This converts nsIMediaManagerService to use nsIArray rather than
nsISupportsArray. All usages of the interface are updated.
MozReview-Commit-ID: 1PLczEptf59
Also this makes the gScreenWidth/gScreenHeight variables unused, so those can
come out too and the Window:Resize handler can be simplified a bit.
MozReview-Commit-ID: 96iF16jSKBB
--HG--
extra : rebase_source : 01db1de5cc548db107267d84dda5b774cd652883
This patch introduces WebsiteMetadata.jsm which imports fathom and page-metadata-parser.
The code has been slightly modified to not depend on more node libraries.
On DOMContentLoaded the module will extract the metadata asynchronously and send it with
a 'Website:Metadata' event.
MozReview-Commit-ID: LxhYOTvvdsF
--HG--
extra : rebase_source : e31286bd7268ad62d55f1a5318cde79442e9acba
Make contentDocumentChanged and isContentDocumentDisplayed calls require
the caller to pass in a window object, so that we can get the widget and
GeckoLayerClient from the window object. This way these calls no longer
depend on having a global layer client in AndroidBridge.
We decided to remove it because:
* Modern video controls include an exit fullscreen button
* After bug 1031519, you have to swipe down from the top of the screen to
display the soft back button so the copy does not make sense.
Note that the `MozShowFullScreenWarning` event was removed previously in the
platform in [1] so we remove the listener attachment here without replacing it.
[1]: https://hg.mozilla.org/integration/fx-team/rev/a6a5f79e630d
MozReview-Commit-ID: HwyyUkWkUUH
--HG--
extra : rebase_source : 99b81c1f71aca357c3a9ea34e63fc7d20bed994f
Remove the input method change notification that GeckoInputConnection
sends to FormAssistPopup, so there's no dependency on FormAssistPopup
from inside GeckoInputConnection or GeckoInterface. Instead,
FormAssistPopup now actively queries the current input method, and
performs blocklisting based on that.
The 'MEDIA_PLAYING_CHANGE' is used for controling media control interface and
the 'AUDIO_PLAYING_CHANGE' is used for showing the tab sound indicator.
MozReview-Commit-ID: 8hZjC77Ju71
--HG--
extra : rebase_source : 3699ea482e89a5c2535defce8ca2689a180d5c49
When restoring a recently closed tab from the corresponding home panel, we normally directly switch to the freshly recreated tab. However if we've entered the home panels through editing mode (as opposed to opening a new tab with about:home), editing mode takes priority and the restored tab is opened in background instead, because we return to the originally selected tab when exiting editing mode.
To fix this inconsistency, we introduce a new parameter for opening tabs from Gecko that cancels editing mode if necessary to allow for directly switching to the new tab.
MozReview-Commit-ID: 4iqPISmtNIx
--HG--
extra : rebase_source : fab9dc911171deef1a984bd96993287d146b370a
This patch replaces the old favicon code with the new icon code
in the UI code.
MozReview-Commit-ID: 2YdDpYUhb0M
--HG--
extra : rebase_source : 1c07eebdd4d9d873040a60a19b2aa30efc712cb7
