There are few things that are either Fennec-specific or don't work
currently under GeckoView w/ e10s under TestRunnerActivity. Disable
these so we can get some testing going in automation.
This also replaces 'isFennec' with the more correct 'is_fennec'.
Differential Revision: https://phabricator.services.mozilla.com/D19016
--HG--
extra : moz-landing-system : lando
Invert screen pixels in `nsWindow`.
Update `RequestScreenPixels` in `nsWindow` to accept a `GeckoResult` as an argument and save as a `GlobalRef`.
Update `RecvScreenPixels` in `nsWindow` in order to invert the image before sending over JNI rather than requiring callers to invert the image themselves.
Complete the `GeckoResult` if there is one in `RecvScreenPixels` instead of making a callback to the compositor.
Remove `RecvScreenPixels` from `GeckoSession` and `GeckoSession.Compositor`.
Move `RecvScreenPixels` and `getPixels` to `GeckoDisplay`
Rename `getPixels` to `capturePixels`
Return Bitmap from `RecvScreenPixels`.
Return `GeckoResult` from `capturePixels`.
Add doc comments to new methods and classes.
Update FennecNativeDriver to use `GeckoView` and `GeckoResult`.
Update API docs and Changelog
Add tests
Differential Revision: https://phabricator.services.mozilla.com/D18944
--HG--
extra : moz-landing-system : lando
Although about.css, aboutMemory.css and aboutSupport.css are mobile-specific
style, these CSS files are used in toolkit, not mobile/android.
Since GeckoView doesn't has chrome.jar, these files are missing. So we should
move these CSS files to toolkit since we have mobile theme in toolkit.
Differential Revision: https://phabricator.services.mozilla.com/D20792
--HG--
rename : mobile/android/themes/core/about.css => toolkit/themes/mobile/global/about.css
rename : mobile/android/themes/core/aboutMemory.css => toolkit/themes/mobile/global/aboutMemory.css
rename : mobile/android/themes/core/aboutSupport.css => toolkit/themes/mobile/global/aboutSupport.css
extra : moz-landing-system : lando
The extension is only ever used for local files, so don't bother retrieving it
otherwise.
Differential Revision: https://phabricator.services.mozilla.com/D21049
--HG--
extra : moz-landing-system : lando
While it's not clear how many apps might still have a generic HTTP-only intent-
filter at this stage, we only collect that information once per session, so to
be on the safe side we still check both schemes separately and merge the data.
Differential Revision: https://phabricator.services.mozilla.com/D20860
--HG--
extra : moz-landing-system : lando
Use the more concise way of defining functions and more arrow functions.
Also use a class to define "App" objects.
Differential Revision: https://phabricator.services.mozilla.com/D20859
--HG--
extra : moz-landing-system : lando
"Prior to Android 8.0 (API level 26), if an app requested a permission at
runtime and the permission was granted, the system would also incorrectly
grant the app the rest of the permissions that belonged to the same permission
group, and that were registered in the manifest.
For apps targeting Android 8.0, this behavior has been corrected. The app is
granted only the permissions it has explicitly requested. However, once the
user grants a permission to the app, all subsequent requests for permissions
in that permission group are automatically granted."
https://developer.android.com/about/versions/oreo/android-8.0-changes#rmp
Our FilePicker can delegate other applications to record media files
(photo/audio/video) which are then to be sent to websites. They must be saved
locally before the upload, scenario that wasn't possible anymore on Oreo+
because of the change in how Android handles runtime permissions.
As a way to get around this one could grant the "Storage" permission from
System Settings which would grant the app both READ and WRITE access.
But for actually being prepared to handle all situations our FilePicker must
ask for the WRITE_EXTERNAL_STORAGE permission at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D20821
--HG--
extra : moz-landing-system : lando
This is needed to make the handler to avoid race conditions where some code
tries to access a resource://android URI before the handler has been
registered.
Depends on D18739
Differential Revision: https://phabricator.services.mozilla.com/D18740
--HG--
extra : moz-landing-system : lando
Before this change, HasSubstitution would return false for "gre" or "app" which
is incorrect, since these handlers exist.
Differential Revision: https://phabricator.services.mozilla.com/D18739
--HG--
extra : moz-landing-system : lando
The bulk of this is copy/pasted from a standard android-api-16 debug
build. The only changes are a few extra environment variables in the
taskcluster config, the subconfig file, and the mozconfig, as well as
the --enable-mozsearch-plugin flag in the mozconfig.
Depends on D20766
Differential Revision: https://phabricator.services.mozilla.com/D20767
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Even though using text.replace() is supposed to keep the existing spans intact,
in practice the composition spans still get lost, even when the replacement text
is identical (because there was in fact no capitalisation difference between
user-entered text and autocomplete result).
One approach to fix this would be to manually save the composition spans and
subsequently restore them afterwards, like we already do this a few lines
further down below, in the other major code path through onAutocomplete().
However while trying to generalise that approach, the most natural approach for
the caller to specify which spans it wanted to save was to pass a Predicate
lambda to the state saving function, which for some reason led to strange
"Didn't find class" errors.
So instead, we just restart input for affected IMEs (i.e. Sony's keyboard) to
get them back into sync with the new contents of the EditText.
To avoid unnecessarily calling restartInput(), though, we only do this if the
user-entered text (which at this stage is known to correspond to the auto-
complete result when compared case-*insensitively*) actually differs from the
autocomplete result.
Differential Revision: https://phabricator.services.mozilla.com/D20487
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Using this flag will cause GeckoWebExecutor.fetch() to not automatically
follow redirects, which is the default behavior if no flag is specified.
Differential Revision: https://phabricator.services.mozilla.com/D19523
--HG--
extra : moz-landing-system : lando
This simply lets you request 'count' random bytes. A SHA-256 digest is
included for verifying the integrity of the response.
Differential Revision: https://phabricator.services.mozilla.com/D19503
--HG--
extra : moz-landing-system : lando
Patch from bug 1519418 introduced a regression by removing line separators from
the uid parameter contained within deeplinks. However, not all deeplinks are
mandatory to contain the uid parameter. Added a null check before replacing the
line separators.
Differential Revision: https://phabricator.services.mozilla.com/D20367
--HG--
extra : moz-landing-system : lando
It wasn't clear in callee code that the window was the top-window and it wasn't necessary in many cases. Relying on the top-window would also cause problems with Fission if the windows are in separate processes.
Differential Revision: https://phabricator.services.mozilla.com/D20395
--HG--
extra : moz-landing-system : lando
Looks like accessibility-test-framework was added to maven central so we can
remove this.
Differential Revision: https://phabricator.services.mozilla.com/D20365
--HG--
extra : moz-landing-system : lando
The behaviour of switching to an already opened tab for an item in the stream
list was already in place, this patch just modifies the item's layout by
adding a text hint about this possibility - "Switch to tab", dynamically,
depending on if a tab is already opened or not in the current session.
Each stream item will implement `Tabs.OnTabsChangedListener` and check if the
changed Tab had stream's Url.
If so it will pass this event to the list's Adapter which will refresh the
stream item's layout.
Differential Revision: https://phabricator.services.mozilla.com/D18997
--HG--
extra : moz-landing-system : lando
Removed intended throw of IllegalStateException for Nightly when a page was not considered safe as a PWA.
Differential Revision: https://phabricator.services.mozilla.com/D18533
--HG--
extra : moz-landing-system : lando
Otherwise the user should see and be able to interact with the whole page.
Refactored `PictureInPictureController` to check the media playing status for
only the current tab, the one the user has in front and for which we may allow
PiP because `GeckoMediaControlAgent.isMediaPlaying()` would give us false
positives in the case where the current Tab is in fullscreen but not playing
media, while at the same time a background Tab is playing media.
BrowserApp will only force fullscreen after returning from PiP if media
playback has ended, but will keep fullscreen for playing/paused media.
Differential Revision: https://phabricator.services.mozilla.com/D19750
--HG--
extra : moz-landing-system : lando
Using an ItemTouchHelper for various motion actions means it will have a
strong reference to that item's layout and prevent it from being destroyed when
the adapter tries to remove it before the animations are finished - the item
will be removed from RecyclerView's Adapter but the item's layout will still
remain on screen.
Differential Revision: https://phabricator.services.mozilla.com/D19673
--HG--
extra : moz-landing-system : lando
Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
The scrollTo() and scrollBy() functions in the PanZoomController may be
used to scroll the root document in GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D18898
--HG--
extra : moz-landing-system : lando
Modifying the manual font size settings while the GeckoFontScaleListener is
active is theoretically possible, but probably not the most sensible way of
using that API. Therefore, we prohibit it and throw an exception in that case.
There is one complication, though: The very same API is used by the font scale
listener itself in order to modify the font size settings according to the
system font scale. Therefore, we have to move the GeckoFontScaleListener into
the GeckoView package itself, so that we can provide a package-private internal
API that bypasses the above usage checks.
This means that going forward, Fennec needs to use the official GeckoView API
to communicate with the font scale listener, too. As we've moved out the Shared-
Preferences watching in part 5, this doesn't pose any insurmountable
difficulties.
Because for a short while I encountered some strange crashes where getRuntime()
in GeckoApplication apparently returned null while trying to initialise the
listener, I'm tying its initialisation to creation of the runtime, just to be on
the safe side.
Differential Revision: https://phabricator.services.mozilla.com/D18507
--HG--
rename : mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoFontScaleListener.java
extra : moz-landing-system : lando
Some callers might prefer to manually set the font size in analogy to WebView's
WebSettings.setTextZoom(), respectively allow their users to do so.
Subsequently, we're also going to switch the GeckoFontScaleListener to operate
on those settings.
Because the effects of font inflation are more difficult to quantify than a
plain text zoom, we just check that operating the runtime setting sets the
corresponding Gecko pref. Besides, there already are further platform (ref)tests
checking the actual operation of font inflation itself.
Differential Revision: https://phabricator.services.mozilla.com/D17749
--HG--
extra : moz-landing-system : lando
With the dependencies on Fennec's GeckoPreferences and GeckoSharedPrefs gone, we
can now move the class into GeckoView in preparation for hooking it up to the
GeckoViewRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D18506
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/GeckoFontScaleListener.java => mobile/android/geckoview/src/main/java/org/mozilla/gecko/GeckoFontScaleListener.java
extra : moz-landing-system : lando
For easier testing in Fennec, we want to continue watching the respective
SharedPreferences key and toggle the listener in response to *that* instead of
directly wiring it into our Settings menu (GeckoPreferences), however because
that functionality is Fennec-specific, we move that logic out of the font scale
listener itself.
In conjunction with this, we also decouple the enabled state of the listener
from its attached state.
The enabled state can now be toggled at all times, but unless the listener is
also attached to a context, it simply won't have any practical effect.
Differential Revision: https://phabricator.services.mozilla.com/D17746
--HG--
extra : moz-landing-system : lando
In practice, everything in the GeckoFontScaleListener will run on the UI thread,
so get rid of the `synchronized` methods and just enforce the threading
assumptions in the public API.
Differential Revision: https://phabricator.services.mozilla.com/D18505
--HG--
extra : moz-landing-system : lando
Going forward, we want to be able to toggle the enabled state at all times, and
being able to do this before calling initialize() seems a bit inconsistent.
Hence, we rename it to the more neutral-sounding attachToContext().
Differential Revision: https://phabricator.services.mozilla.com/D17745
--HG--
extra : moz-landing-system : lando
The GeckoFontScaleListener is intended to live as long as the app (and there-
fore Gecko) remains alive and consequently keeps a reference to the
*application* context, so the linter warning can be safely suppressed.
Also reorder imports to match coding style.
Differential Revision: https://phabricator.services.mozilla.com/D17743
--HG--
extra : moz-landing-system : lando
It's only being referenced in these two lines in mobile.js, but nowhere else
anymore.
Differential Revision: https://phabricator.services.mozilla.com/D19309
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
This manifests as silent child process crashes; let's try to avoid
that when we can.
Differential Revision: https://phabricator.services.mozilla.com/D19089
--HG--
extra : moz-landing-system : lando
Functionally, we want Marionette to be enabled whenever remote
debugging enabled and disabled whenever remote debugging is enabled.
That's not particularly well supported by Gecko prefs, so we don't try
to handle all situations. We force the Marionette pref whenever the
remote debugging pref changes; if consumers get themselves into a bad
state by fiddling the Marionette pref independently, that's fine:
GeckoView will take back control eventually.
There are a couple of wrinkles here. The first is that GeckoView and
Marionette race to set themselves up in "profile-after-change". We
ensure that both are configured before GeckoView notifies
"marionette-startup-requested". The second is that the initial value
of the Marionette pref is taken from the environment variable
MOZ_MARIONETTE; therefore, we set that variable when starting the
Gecko thread.
Differential Revision: https://phabricator.services.mozilla.com/D17580
--HG--
extra : moz-landing-system : lando
This is just a testing convenience. Remote debugging is engine-wide,
not session-wide, so it doesn't fit the other actions _exactly_; but
the "multiprocess" option is also somewhat engine-wide, so it doesn't
seem wildly out of place.
Differential Revision: https://phabricator.services.mozilla.com/D18616
--HG--
extra : moz-landing-system : lando
Once a webextension using a blocking WebRequest listener has started loading,
all network connections covered by the extension's manifest are held until the
extension is ready the process them.
One condition for the extension being ready apparently includes browser startup
having progressed far enough, as signified by "browser-delayed-startup-finished"
having been dispatched.
Therefore, we have to start sending that notification when opening a new Gecko-
View window, too, and copy Fennec's InitLater() system for that.
Unlike Fennec, we cannot tie registration of those InitLater() runnables to the
initial content load having progressed far enough because of
a) e10s, which makes that approach neither easily possible nor really sensible,
as content will load in a different process in that case, and
b) because we're racing with extension startup here - if extensions are loaded
quick enough to block even the initial page load, we'd be deadlocked: We
cannot send the notification until the page finishes loading, but the page
cannot load until we send the notification. Fennec isn't affected by the
latter problem because "sessionstore-windows-restored", which Fennec will
send in any case, serves as an alternative pathway for completing extension
startup.
And unlike Desktop, we don't really have any chrome content to paint, so we
cannot tie delayed initialisation to a paint listener for that, either.
Therefore, we simply fire off a runnable at the *end* of geckoview.js's
startup() method, which should give more pressing initialisation tasks enough of
a headstart.
For completeness, we're also adding the "browser-idle-startup-tasks-finished"
notification and thereby solve bug 1465832 as well, allowing the ScriptPreloader
to detect which scripts are commonly loaded during GeckoView startup and to
start caching and pre-parsing them.
Differential Revision: https://phabricator.services.mozilla.com/D18865
--HG--
rename : mobile/android/modules/DelayedInit.jsm => mobile/android/modules/geckoview/DelayedInit.jsm
extra : moz-landing-system : lando
That way, domain highlighting (and therefore the URL justification code that
right-justifies the TLD within the URL bar) can run even on error pages.
This also means that the workaround from bug 1479311 for blocking javascript:
URIs from being highlighted in ToolbarDisplayLayout is no longer required -
the base domain for domain highlighting is now being generated from the same
URI that actually ends up being displayed in the URL bar, and as such the
existing checks in browser.js for only generating a base domain for HTTP(S)/
FTP-URIs, but not any other schemes, finally work the way they are intended.
Differential Revision: https://phabricator.services.mozilla.com/D18587
--HG--
extra : moz-landing-system : lando
Currently, the Android front-end uses a tab's base domain both for permission
prompt doorhangers, as well as for doing domain highlighting in the URL bar. The
base domain in turn is based on the document's nodePrincipal's URI.
As per bug 1325955, the nodePrincipal is the right choice for permission
prompts, but it causes some problems for domain highlighting instead: For error
pages for example, the nodePrincipal's URI will be some variety of
about:neterror, which means that the front-end won't be able to do any domain
highlighting based on that, since
a) we don't generate any baseDomain anyway because the URI's scheme isn't
HTTP(S)/FTP, and
b) even if we did, the nodePrincipal's baseDomain won't match the contents of
the URI displayed in the URL bar.
Therefore, we want to separate these two concerns, and generate two baseDomains:
One based on the nodePrincipal for use in permission prompts, and one based on
the display URI, which going forward will power our domain highlighting.
Differential Revision: https://phabricator.services.mozilla.com/D18586
--HG--
extra : moz-landing-system : lando
Summary:
For every `Enter` or `Shift+Enter` ACTION_DOWN event a new next/previous search
will be made.
Keeping the buttons pressed will cycle through all the search results endlessly.
Depends on D17133
Reviewers: JanH
Reviewed By: JanH
Bug #: 1498911
Differential Revision: https://phabricator.services.mozilla.com/D18203
--HG--
extra : histedit_source : 626b863aa35e63e113be81deecadd8193f1e1c01
Replaced deprecated method which returns null if device is on an IPv6-only network with a newer one that can return IPv6 address.
Depends on D18324
Differential Revision: https://phabricator.services.mozilla.com/D18326
--HG--
extra : moz-landing-system : lando
Updated play-services-cast to 16.0.0 in order to benefit from the IPv6 and other features.
Differential Revision: https://phabricator.services.mozilla.com/D18324
--HG--
extra : moz-landing-system : lando
This is a rollup of all the patches that have landed on the cedar project branch:
891252fdd0
Bug 1492475 - Part 1: Migrate most, if not all nsSearchService consumers to use async APIs. r=florian
79b2eb2367
Bug 1492475 - Part 2: Move nsIBrowserSearchService.idl to toolkit/components/search/nsISearchService.idl and update references. r=florian
a947d3cdf0
Bug 1492475 - Part 3: The search service init() method should simply return a Promise. r=florian
c1e172dfac
Bug 1492475 - Part 4: Remove the synchronous initialization flow. r=florian
cd41189eac
Bug 1492475 - Part 5: Since async initialization of the search service now is implicit behavior, remove the distinctive verbiage used internally. r=florian
2ae7189dfa
Bug 1492475 - Part 6: Update the cache build task to work with an actual Promise and re-initialize only once at the same time - all to fix race conditions here. r=florian
c8ee92973f
Bug 1492475 - Part 7: Make the region fetch not block the init flow, to ensure it's as fast as possible. r=florian
c44e674e16
Bug 1492475 - Part 8: Introduce an init flag, which can only be used privately, that allows to explicitly skip waiting for the region check process to complete. r=florian
6c79eaf1d3
Bug 1492475 - Part 9: Update unit tests to stop using 'currentEngine', in favor of 'defaultEngine'. r=Standard8
21b3aa17ee
Bug 1492475 - Part 10: Update unit tests to be fully aware of the new, async signatures of the search service API and remove sync init flow tests. r=mkaply,florian
ce5ba69019
Bug 1492475 - Part 11: Repair incorrect usage of the `identifier` property of nsISearchEngine instances. r=florian
fd177a7994
Bug 1518543 - Fix up the Android (Fennec) nsISearchService shim to work with the new asynchronous API. r=florian
3653d8ee22
Bug 1523708 - Change the search service interaction in the show-heartbeat action to use the new async API. r=florian
Differential Revision: https://phabricator.services.mozilla.com/D18355
--HG--
rename : netwerk/base/nsIBrowserSearchService.idl => toolkit/components/search/nsISearchService.idl
extra : moz-landing-system : lando
Since ./mach bootstrap installs Android SDK into ~/.mozbuild, we should detect
this location as default SDK install path.
Also, --with-android-max-sdk and --with-android-min-sdk are still in android.m4
because confvars.sh sets MOZ_ANDROID_MIN_SDK_VERSION.
Differential Revision: https://phabricator.services.mozilla.com/D15463
--HG--
extra : moz-landing-system : lando
Added additional logging. In case the agent is not attached but we are not on a
release or beta build, allow createNotification to be called with a null context
so that we may be able to gather more information from the reports.
Depends on D18115
Differential Revision: https://phabricator.services.mozilla.com/D18116
--HG--
extra : moz-landing-system : lando
Use MediaControlService's context when creating the notification in order to
prevent a NPE.
Differential Revision: https://phabricator.services.mozilla.com/D17391
--HG--
extra : moz-landing-system : lando
There can be a slight delay (in rapport with actually loading the page) until
the ContentBlockingEvent is received.
To account for this, we'll use an overly generous 500ms timeout before
actually checking if we have the right tracking status.
Differential Revision: https://phabricator.services.mozilla.com/D17344
--HG--
extra : moz-landing-system : lando
`Enter` will search for the next occurrence of the "Find" string.
`Shift+Enter` will search for the previous occurrence of the "Find" string.
For this, FindInPageBar will intercept all `onKey` events and
- on `KeyEvent.ACTION_DOWN` will consume `Shift+Enter` which would otherwise
insert a newline character in the search box
- on `KeyEvent.ACTION_UP` will do a new next/previous search depending on the
keys pressed.
Differential Revision: https://phabricator.services.mozilla.com/D17133
--HG--
extra : moz-landing-system : lando
The desktopMode property on Fennec's tab object is already being correctly being
preserved when (re)creating a tab [1], but we don't propagate its state to the
content window's desktop viewport mode setting.
[1] When restoring into a fresh tab, the session restore code passes the stored
desktopMode flag to addTab, whereas zombifying an existing tab destroys its
<browser>, but leaves the tab object's properties intact, so we merely need to
re-set the desktop viewport mode on the new <browser>'s content window.
Differential Revision: https://phabricator.services.mozilla.com/D17774
--HG--
extra : moz-landing-system : lando
We use foreground services, so this is necessary in order to be able to target
Android P.
The GeckoView example app needs it for the crash handling service.
Differential Revision: https://phabricator.services.mozilla.com/D16423
--HG--
extra : moz-landing-system : lando
android.test.* is no longer part of the main framework, so as per
https://developer.android.com/training/testing/set-up-project,
- we must no longer declare them as a *required* dependency in our manifests
- we must explicitly include a dependency on them in our build config
This will temporarily break running tests depending on android.test.* (i.e.
mainly Robocop) on devices using P or newer until we also start targeting P as
well.
Differential Revision: https://phabricator.services.mozilla.com/D16422
--HG--
extra : moz-landing-system : lando
Once we start compiling with API28, android.test.* is no longer part of the main
framework JAR and will be included from separate libraries instead.
Those additional JARs will then subsequently show up on the class path in
Gradle, too.
Because our SDKProcessor is currently set up to process only one JAR at a time
and because we don't actually need to generate bindings for those test classes,
we simply filter them out again.
We explicitly only filter the android.test.* JARs and use findAll so that if the
android classpath unexpectedly gains another member, we're alerted to that fact
and can consciously take a decision on whether to ignore it as well or not.
Differential Revision: https://phabricator.services.mozilla.com/D16421
--HG--
extra : moz-landing-system : lando
This patch removes the XBL videocontrols binding and make <video>
to always use the UA Widget to generate controls.
DevTools tests that look for NAC is switched to use <input type=file>.
Differential Revision: https://phabricator.services.mozilla.com/D17571
--HG--
extra : moz-landing-system : lando
VIEWPORT_MODE_DESKTOP *forces* the desktop mode viewport everywhere, whereas
VIEWPORT_MODE_MOBILE merely enables <meta> viewport support for pages that have
that tag defined, but still uses the desktop mode viewport for all other pages.
Differential Revision: https://phabricator.services.mozilla.com/D17159
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
After the changes from bug 1514340 the app is now informed about tracking with
Content:ContentBlockingEvent instead of Content:SecurityChange
Also initialized mLastTracking with unknown as that is the default value
when no tracking event has been received (eg: no tracking elements on the page)
Depends on D16822
Differential Revision: https://phabricator.services.mozilla.com/D16823
onSecurityChange from browser.js will not send information about tracking
anymore to Java (because it doesn't know about that anymore).
onContentBlocking from browser.js will be responsible for this from now on.
is called after onSecurityChange which will have created a SiteIdentity()
for that tab in Java
is informed only about tracking status which it caches to only send updates
downstream to Java. Will not propagate identical events one after the other.
will not fire for websites which do not contains any tracking elements
A Content:ContentBlockingEvent received in Java will update the tracking
property of SiteIdentity and finally update the UI with
ToolbarDisplayLayout#updateSiteIdentity().
Differential Revision: https://phabricator.services.mozilla.com/D16822
I'm taking an old ticket number just to close it. The files removed
no longer exist in the tree; the NSS option exists and probably
shouldn't -- but that's for another day, so let's just make it not
warn for now.
Depends on D15016
Differential Revision: https://phabricator.services.mozilla.com/D15017
--HG--
extra : moz-landing-system : lando
On debug builds whenever we would attempt to retrieve the value of localUid it
would be null because the LP debug id is never persisted.
Differential Revision: https://phabricator.services.mozilla.com/D16319
--HG--
extra : moz-landing-system : lando
We keep old cache code in the tree only because of offline cache. We no longer allow using old disk or memory cache. This patch removes all preferences manipulation from old cache code that isn't used by offline cache. It removes also some related code (e.g. everything smart size related, unused defines etc.), but the goal wasn't to remove all unused code from the old cache.
Let SessionStoreUtils be a WebIDL namespace, rather than a XPCOM service
Differential Revision: https://phabricator.services.mozilla.com/D9776
--HG--
rename : toolkit/components/sessionstore/nsSessionStoreUtils.cpp => toolkit/components/sessionstore/SessionStoreUtils.cpp
extra : moz-landing-system : lando
I quickly tested on Fennec with the whole stack and I am able to list workers, inspect workers etc...
Could not see any issue at first glance.
Differential Revision: https://phabricator.services.mozilla.com/D16175
--HG--
extra : moz-landing-system : lando
James Willcox
Oana Pop Rus
Emily Toop
Makoto Kato
Jan Henning
Eitan Isaacson
Kris Maglione
Petru Lingurar
Thomas Wisniewski
Noemi Erli
Christoph Kerschbaumer
Agi Sferro
Andreea Pavel
Kartikaya Gupta
Matthew Noorenberghe
Ciure Andrei
Bogdan Tara
Vlad Baicu
Cosmin Sabou
Eugen Sawin
Michael Kaply
Geoff Brown
Dorel Luca
Jonathan Kingston
Andrei Lazar
Coroiu Cristina
Natalia Csoregi
Jesse Schwartzentruber
Razvan Maries
Daniel Varga
Randall Barker
Brindusan Cristian
Nick Alexander
Andrew Erickson
Gijs Kruitbosch
shindli
Yuan Cheng
Delphine Lebédel
Zibi Braniecki
prathiksha
Andrew Swan
Mike de Boer
Dylan Roeh
Mike Conley
Myk Melez
Ryan Hunt
Dennis Schubert
Sebastian Hengst
Ehsan Akhgari
Alphan Chen
Narcis Beleuzu
arthur.iakab
Timothy Guan-tin Chien
Francesco Lodolo (:flod)
John Lin
Margareta Eliza Balazs
alwu
Matt Brubeck
Michal Novotny
Julian Descottes
Sylvestre Ledru