BrowserApp's sanitize() function assumed that the Sanitizer would return promises for each sanitization handler, so it could wait for them to resolve before proceeding with shutdown (which was also the assumption behind the patch for bug 1266594). In fact even the Sanitizer expected to do this is well, since it wrapped each of its handling functions within a promise/task/sendRequestForResult. However it turns out that Sanitizer's clearItem function then failed to actually return this promise - apparently ever since this was implemented.
MozReview-Commit-ID: 6hN3UTXUIuV
--HG--
extra : rebase_source : 4971bc02962c817037a565595d3c1cedb0532d76
Remove GeckoEventListener and NativeEventListener now that we uniformly
use BundleEventListener. Also remove related classes NativeJSContainer,
NativeJSObject, and GeckoRequest, as well as related tests and C++
code.
The "Messaging" object in Messaging.jsm is replaced with a dummy object
that redirect calls to the global and/or window event dispatcher.
Convert events used in PageActions to bundle events. UI thread events
are used because the listeners require the UI thread. The observer
notifications from Java to Gecko are converted to events as well.
Convert events used in AccountsHelper to bundle events. Most events are
kept as Gecko thread events, but a couple events that start activities
are converted to UI thread events.
Convert events used in IntentHelper to bundle events. UI thread events
are used for most events because the listeners perform operations on
Intent objects, which is best done on the UI thread. For
"Intent:GetHandlers", use a Gecko thread event because it's possible we
want a synchronous callback response.
Convert events used in HomePanelsManager to bundle events. Background
thread events are used because HomePanelsManager processes panel changes
in the background thread. Changing to background thread events also lets
us make the change queue a simple ArrayList instead of a
ConcurrentLinkedQueue, because there is no longer multiple threads
involved.
Convert the "HomePanels:Data" event to a GeckoBundle/BundleEventListener
event. UI thread event is used because the listener invokes the callback
on the UI thread.
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.
When a snackbar with a button callback is dismissed, this translates to a rejected promise from sendRequestForResult(). We need to catch this in order to avoid a spurious 'JavaScript Error: "uncaught exception: undefined"' message appearing in the console and possibly causing confusion.
MozReview-Commit-ID: 7hsAOAMTeDP
--HG--
extra : rebase_source : 6c5eb28d2e0dcf39a35b310d1e1c45cfc47f272b
Convert events used in SharedPreferencesHelper to
GeckoBundle/BundleEventListener events. Gecko thread events are used
because the listeners are expected to be synchronous, especially for the
SharedPreferences:Get event, which also requires a synchronous callback.
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.
Convert NotificationHelper events to use BundleEventListener and
GeckoBundle. UI events are used to perform notification operations, and
to keep access to mClearableNotifications to the UI thread. Also,
refactor some recently-added code in NotificationHelper.
There's a pull request [1] and issue [2] on GitHub tracking the work to land this
in the page-metadata-parser repository. Multiple potential sources for getting a
'provider name' are considered in the linked issue - however they all have
slightly different semantic meanings. Only 'og:site_name' actually has the same
meaning as "provider name". Therefore it is pretty safe to land this part.
[1] https://github.com/mozilla/page-metadata-parser/pull/81
[2] https://github.com/mozilla/page-metadata-parser/issues/79
MozReview-Commit-ID: KQFSLo85JoS
--HG--
extra : rebase_source : ba86e5c3785cda500a1e8f5a8887228c72f6d00f
Convert "Wifi:Enable" and "Wifi:GetIPAddress" events to GeckoBundle
events. Use the UI thread because we do things like starting activities
and using system services, which are best done on the UI thread.
Convert JavascriptBridge, JavascriptTest, and other relevant code to use
the new Bundle events. We used the same "Robocop:JS" event for
communicating both ways before, but now that we have a unified bus, we
need two different events, "Robocop:JS" and "Robocop:Java" for two-way
communication.
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.
Convert prompts to use BundleEventListener and GeckoBundle.
DefaultDoorHanger.setOptions accepts a JSONObject argument, but if we
converted it to GeckoBundle, it would involve a lot of extra changes in
the other doorhanger code. So this patch adds GeckoBundle.fromJSONObject
and converts JSONObject to GeckoBundle within
DefaultDoorHanger.setOptions. In the future, another patch would convert
all doorhanger code to use GeckoBundle instead of JSONObject.
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`.
We only extract metadata that we'd want to store. For now this is just image_url.
In case we try to store page metadata before corresponding history record has been inserted,
we queue up metadata and wait for an event from GlobalHistory letting us know that history
record is now available, at which point we try inserting metadata again.
MozReview-Commit-ID: 2FpIqc6uHMb
--HG--
extra : rebase_source : 5839e04f82e174f50a61c107d271b4bda3f748c8
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
Bug 1058438 moved disabled hosts to the permission manager which are already cleared by these modules.
MozReview-Commit-ID: InprrYLvjMR
--HG--
extra : rebase_source : 806c2542cbab953b74ad82611501ecac32400930
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
On newer Android versions, double tapping an entry in the app chooser is equivalent to tapping it once and selecting "Just once". To enable this functionality for our own app chooser when downloading a file, this patch enables passing a button index to the prompt dialog which will be chosen by default if a double tap has been detected.
To do this, we track the input value we receive in onChange. If we receive the same value twice in a row and a button has been configured, we close the dialogue and pass the result with that button back to the caller.
MozReview-Commit-ID: EVs2x3OtHmB
--HG--
extra : transplant_source : %85Td%83%0D%DD%D0%1D%F48a%5D%A0%CF%B4%A5%CE%5E%22%7E
extra : histedit_source : 190cf52e481b637172ea3b49ccec606f31dc86cf
Jim Chen
Florian Quèze
Jan Henning
Sebastian Kaspari
Eugen Sawin
Dylan Roeh
srivatsav
Nevin Chen
Tooru Fujisawa
Grisha Kruglov
Matthew Noorenberghe
Makoto Kato
Tom Tromey
Kit Cambridge