This undoes a caveat created from the last changeset; I did not profile this
change.
MozReview-Commit-ID: 6jpXyt0GRUj
--HG--
extra : rebase_source : e200e7942782ad042a6bb703f137dac71a398a21
I replaced JSON parsing for all highlight candidates (at most, 500) with a
faster estimation using regex: we only use the full JSON parsing to get the
perfect values for the items to be shown (~5).
One caveat of this change: JSON parsing will be moved to the main thread when
the getMetadataSlow is lazily-loaded.
Disclaimer: my device seems to be running faster than yesterday so profiling
may not be consistent but here are the profiling results:
- HighlightsRanking.extractFeatures: 78.1% -> 54.5%
- Highlight.<init>: 26.5% -> 14.5%
- JSONObject.<init>: 11.4% -> rm'd
- initFast*: (replaced JSONObject.<init> & friends) -> 4.2%
With ^ the disclaimer in mind, runtime decreased from 12.6s to 5.3s (this is
slower due to profiling).
MozReview-Commit-ID: CTqAyDDmaJQ
--HG--
extra : rebase_source : 1318c460b55159e38a5dd41d53ebcee00e67029c
After the previous changeset, some numbers stood out:
- HighlightsRanking.extractFeatures: 44.9%
- HighlightCandidate.getFeatureValue: 19.4%
- Collections.secondaryHash: 17.3%
- HashMap.get: 11.7%
My hypothesis was that our HighlightCandidate.features implementation was slow:
it was mapping FeatureNames -> values in a HashMap but HashMap look-ups are
slower than a direct memory access.
I replaced the implementation with a direct access from an array - about as
fast as we can get. This encouraged me to make some changes with the following
benefits:
- Rewrote HighlightsRanking.normalize to save iterations and allocations.
- Rm code from HighlightsRanking.scoreEntries: we no longer need to iterate to
construct the filtered items, we just index directly into the list
- Rewrote HighlightsRanking.decay(), which I think is a little clearer now.
- Saved a few iterator/object allocations inside inner loops in places.
The tests pass and we have coverage for the normalize changes but not for
scoreEntries.
---
For perf, my changes affected multiple methods so the percentages are no longer
reliable but I can verify absolute runtime changes. I ran three tests, the best
of which showed an overall 33% runtime compared to the previous changeset and
the other two profiles showed a 66% overall runtime. In particular, for the
middle run, the changes for affected methods go from X microseconds to Y
microseconds:
- Features.get: 3,554,796 -> 322,145
- secondaryHash: 3,165,785 -> 35,253
- HighlightsRanking.normalize: 6,578,481 -> 1,734,078
- HighlightsRanking.scoreEntries: 3,017,272 -> 448,300
As far as I know, my changes should not have introduced any new inefficiencies
to the code.
MozReview-Commit-ID: 9THXe8KqBbB
--HG--
extra : rebase_source : a190bc2e7c0f3ed2b5cb65202b902dcd455b3aa8
This reduces the calls to `getColumnIndexOrThrow` to 9 (from 1.6k) and
HighlightsRanking.extractFeatures goes from 77.1% inclusive CPU time -> 40.8%,
14.6k ms -> 7.1k ms.
MozReview-Commit-ID: L6HqvBK5I4i
--HG--
extra : rebase_source : f67c5ed207a4684edc4a3e7779dabd59c7f98608
This undoes a caveat created from the last changeset; I did not profile this
change.
MozReview-Commit-ID: 6jpXyt0GRUj
--HG--
extra : rebase_source : 7d09b16829376caf1116364e71dddbab7a5314a3
I replaced JSON parsing for all highlight candidates (at most, 500) with a
faster estimation using regex: we only use the full JSON parsing to get the
perfect values for the items to be shown (~5).
One caveat of this change: JSON parsing will be moved to the main thread when
the getMetadataSlow is lazily-loaded.
Disclaimer: my device seems to be running faster than yesterday so profiling
may not be consistent but here are the profiling results:
- HighlightsRanking.extractFeatures: 78.1% -> 54.5%
- Highlight.<init>: 26.5% -> 14.5%
- JSONObject.<init>: 11.4% -> rm'd
- initFast*: (replaced JSONObject.<init> & friends) -> 4.2%
With ^ the disclaimer in mind, runtime decreased from 12.6s to 5.3s (this is
slower due to profiling).
MozReview-Commit-ID: CTqAyDDmaJQ
--HG--
extra : rebase_source : 8cc0ca6ba8cecbf00abdc5de9477a5760d89df0b
After the previous changeset, some numbers stood out:
- HighlightsRanking.extractFeatures: 44.9%
- HighlightCandidate.getFeatureValue: 19.4%
- Collections.secondaryHash: 17.3%
- HashMap.get: 11.7%
My hypothesis was that our HighlightCandidate.features implementation was slow:
it was mapping FeatureNames -> values in a HashMap but HashMap look-ups are
slower than a direct memory access.
I replaced the implementation with a direct access from an array - about as
fast as we can get. This encouraged me to make some changes with the following
benefits:
- Rewrote HighlightsRanking.normalize to save iterations and allocations.
- Rm code from HighlightsRanking.scoreEntries: we no longer need to iterate to
construct the filtered items, we just index directly into the list
- Rewrote HighlightsRanking.decay(), which I think is a little clearer now.
- Saved a few iterator/object allocations inside inner loops in places.
The tests pass and we have coverage for the normalize changes but not for
scoreEntries.
---
For perf, my changes affected multiple methods so the percentages are no longer
reliable but I can verify absolute runtime changes. I ran three tests, the best
of which showed an overall 33% runtime compared to the previous changeset and
the other two profiles showed a 66% overall runtime. In particular, for the
middle run, the changes for affected methods go from X microseconds to Y
microseconds:
- Features.get: 3,554,796 -> 322,145
- secondaryHash: 3,165,785 -> 35,253
- HighlightsRanking.normalize: 6,578,481 -> 1,734,078
- HighlightsRanking.scoreEntries: 3,017,272 -> 448,300
As far as I know, my changes should not have introduced any new inefficiencies
to the code.
MozReview-Commit-ID: 9THXe8KqBbB
--HG--
extra : rebase_source : 0c3f4c4f1e854d96c77bace60392fc4c7274e6e7
This reduces the calls to `getColumnIndexOrThrow` to 9 (from 1.6k) and
HighlightsRanking.extractFeatures goes from 77.1% inclusive CPU time -> 40.8%,
14.6k ms -> 7.1k ms.
MozReview-Commit-ID: L6HqvBK5I4i
--HG--
extra : rebase_source : b190f8f29a2f1720d5a5b9eb2f703a9433ac6ace
I took the time to change jcentral (which is just wrong) to jcenter,
which is the tag used in the nexus.xml.
Order matters! Gradle resolves dependencies in the order given. That
is, jcenter is preferred to google.
MozReview-Commit-ID: CcWBukhiHa4
--HG--
extra : rebase_source : 73a3b3f013d9154ff3f5732593ba9fbe2b75d1f0
This adds a new class, GeckoView.ProgressListener.SecurityInformation, which provides an API for accessing the information passed to GeckoView in GeckoView:SecurityChange messages. GeckoView then passes this object to ProgressListener in onSecurityChanged() calls. Also updates CustomTabsActivity and GeckoViewActivity to reflect the new API and removes the old integer security status param from onSecurityChanged.
It appears that on some devices (e.g., Huawei P10) the video decoder returns null output buffers rather than the common 8 bytes graphic buffer handles.
MozReview-Commit-ID: 2Wp7gDuN2pV
--HG--
extra : rebase_source : ceed957e5db98c13400a6195ad937f74e0b7d7a9
Capture click events for select and input elements to restore previous
behavior. This will always invoke helper prompts for those elements,
even if scripts stop the click event propagation. r=me for trivial
patch.
MozReview-Commit-ID: KOfjc58Zb0Y
This undoes a caveat created from the last changeset; I did not profile this
change.
MozReview-Commit-ID: 6jpXyt0GRUj
--HG--
extra : rebase_source : 33d8a0d1e20bf927ac8a09dc34b8acf1684ea416
I replaced JSON parsing for all highlight candidates (at most, 500) with a
faster estimation using regex: we only use the full JSON parsing to get the
perfect values for the items to be shown (~5).
One caveat of this change: JSON parsing will be moved to the main thread when
the getMetadataSlow is lazily-loaded.
Disclaimer: my device seems to be running faster than yesterday so profiling
may not be consistent but here are the profiling results:
- HighlightsRanking.extractFeatures: 78.1% -> 54.5%
- Highlight.<init>: 26.5% -> 14.5%
- JSONObject.<init>: 11.4% -> rm'd
- initFast*: (replaced JSONObject.<init> & friends) -> 4.2%
With ^ the disclaimer in mind, runtime decreased from 12.6s to 5.3s (this is
slower due to profiling).
MozReview-Commit-ID: CTqAyDDmaJQ
--HG--
extra : rebase_source : 326b04e32eae97adfd5d48d9a53fae507bf0e40a
After the previous changeset, some numbers stood out:
- HighlightsRanking.extractFeatures: 44.9%
- HighlightCandidate.getFeatureValue: 19.4%
- Collections.secondaryHash: 17.3%
- HashMap.get: 11.7%
My hypothesis was that our HighlightCandidate.features implementation was slow:
it was mapping FeatureNames -> values in a HashMap but HashMap look-ups are
slower than a direct memory access.
I replaced the implementation with a direct access from an array - about as
fast as we can get. This encouraged me to make some changes with the following
benefits:
- Rewrote HighlightsRanking.normalize to save iterations and allocations.
- Rm code from HighlightsRanking.scoreEntries: we no longer need to iterate to
construct the filtered items, we just index directly into the list
- Rewrote HighlightsRanking.decay(), which I think is a little clearer now.
- Saved a few iterator/object allocations inside inner loops in places.
The tests pass and we have coverage for the normalize changes but not for
scoreEntries.
---
For perf, my changes affected multiple methods so the percentages are no longer
reliable but I can verify absolute runtime changes. I ran three tests, the best
of which showed an overall 33% runtime compared to the previous changeset and
the other two profiles showed a 66% overall runtime. In particular, for the
middle run, the changes for affected methods go from X microseconds to Y
microseconds:
- Features.get: 3,554,796 -> 322,145
- secondaryHash: 3,165,785 -> 35,253
- HighlightsRanking.normalize: 6,578,481 -> 1,734,078
- HighlightsRanking.scoreEntries: 3,017,272 -> 448,300
As far as I know, my changes should not have introduced any new inefficiencies
to the code.
MozReview-Commit-ID: 9THXe8KqBbB
--HG--
extra : rebase_source : 2358fe83acebaf04a61d912e88f8cf420b7df3d7
This reduces the calls to `getColumnIndexOrThrow` to 9 (from 1.6k) and
HighlightsRanking.extractFeatures goes from 77.1% inclusive CPU time -> 40.8%,
14.6k ms -> 7.1k ms.
MozReview-Commit-ID: L6HqvBK5I4i
--HG--
extra : rebase_source : e3f3997abb8c625bf121927be3140e43378f644e
Before this patch, we used the Gradle sdk-manager-plugin to download
and install Android SDKs and other dependencies. This plugin is now
deprecated; the main dependency downloading functionality has been
incorporated into the Android-Gradle build plugin. Unfortunately,
it's been incorporated into newer versions that in turn require newer
toolchains than we currently support, so we can't use the new
functionality immediately.
Rather than replace sdk-manager-plugin with equivalent Gradle-based
functionality, this ticket uses recently added bootstrap functionality
to bootstrap the Android SDK during the dependencies task. It then
_uses_ that SDK to run the dependency fetching task, _produces_ an
android-sdk-linux.tar.xz, and then _uploads_ the new artifact as a
private artifact, ready to be pushed into tooltool. This avoids
engineers building this critical part of the toolchain locally
themselves, and will also feed into ongoing work to push toolchain
artifacts into build jobs in Task Cluster.
MozReview-Commit-ID: B6FC0ugaCef
--HG--
extra : rebase_source : 782719438a464b8021db58be398be9d5afb3b543
This was only ever used to automatically fetch Android SDK
dependencies in the android-gradle-dependencies job in Task Cluster.
That function is now provided by newer Android-Gradle build plugins.
MozReview-Commit-ID: Adrxm2rAPlZ
--HG--
extra : rebase_source : 6cccb53e2ebc2642ee6c61ef13fcb6d8321b67cf
I'm confident nobody is configuring this locally, so there's no reason
to keep the existing name (and grow the new semantics) nor to
deprecate the existing name explicitly.
MozReview-Commit-ID: HW3epgwZFpO
--HG--
extra : rebase_source : d328f9ce9299dcd80e508925314236747aee1ea3
The flag is needed only for the old onInputExhausted() callback and should not be used for onInputStatus(). (It prevents native implementation from receiving notification required for resolving promise.)
MozReview-Commit-ID: 9NKmY38zHGI
--HG--
extra : rebase_source : ee4b7a2edd82a13f63063ecd5a2b1387485a3aa2
This is used by the iOS implementation of AS to get the highlight titles.
MozReview-Commit-ID: 1p5Lf9OBcfD
--HG--
extra : rebase_source : f2a71e2a27c56fadff6710d3e321678a71994c8a
This should not be run in AS yet because each time it's called, it reads from
the disk and even the tests on desktop take 3s+ to run.
MozReview-Commit-ID: 5h4BcH3myCn
--HG--
extra : rebase_source : cf4c9465a211f369d0ceb6b0e56a22c5f0ad6c1c
I could not make sense of the existing names at all.
Bug 1379021 is going to:
- Remove the vTimeSince view, so I didn't change the name
- Create a new layout file, so I didn't change the resource IDs accordingly
MozReview-Commit-ID: 1WUzyhrzQYZ
--HG--
extra : rebase_source : fdf218b3e965a28f5a519c32fa7a745257885e2a
extra : source : 4b47118ce5bbb26c5c0b999790730d41c27e77e6
I'm a little concerned that this will hide other bugs but it's pretty
complicated to track down without an STR (e.g. what are all the possible ways
we load the HomePager with TopSites as the default and swap in new highlights?
How about unloading? When is onSizeChanged called?) so I don't think it's worth
investigating further.
MozReview-Commit-ID: 6OuFJ2iQsdL
--HG--
extra : rebase_source : 576e29298f131870fed987793663de499285ab1d
We want most builds to be actually using sccache, so we include
mozconfig.cache from mozconfig.common. However, since the --with-ccache
configure option doesn't exist on non-compile jobs (e.g. artifact
builds), we move to using the CCACHE environment variable instead, which
allows us to unset it in mozconfig.no-compile.
And since mozconfig.no-compile is always included where no_sccache is
set, we can remove that variable.
--HG--
extra : rebase_source : a8c743de1fd7a3c0fbc53f7c233df36585897767
GeckoViewFragment was more of a hack for GeckoApp-based custom tabs, and
if we want to provide a fragment implementation for GeckoView, I think
it'll look a lot different than today's GeckoViewFragment. So for now, I
think it's best to revert the changes that added GeckoViewFragment, and
that also simplifies GeckoView lifecycle management.
MozReview-Commit-ID: 5WzIZ8TyBDV
In the frontend we need to know if XUL buttons in the toolbar were
triggered by a touch event, so we're passing on the inputSource
in the command event.
MozReview-Commit-ID: DMvgZULk9hT
--HG--
extra : rebase_source : c455c8ec77e439bf02c1e3e8d34a36e1fb5e3bd0
The nexus.xml included in this patch is the result of starting Nexus
and manually adding the jcenter proxy repository using the Nexus web
administration interface (all in a Docker container). I know of no
way to do this configuration incrementally without the web interface.
The diff between new and the default generated configuration is a
single new <repository>..</repository> element.
MozReview-Commit-ID: 2Bg5qX41pHB
--HG--
extra : rebase_source : c945acabcedd98439a0ca0e26251bab1a41de197
extra : source : 9b794a7fc266da1ae81afd795f91e72d04bbc992
There are some situations where spans are not properly synced from
current text to shadow text. This patch takes more steps to make sure
spans are synchronized.
MozReview-Commit-ID: 1xhsJllE7Ro
--HG--
extra : rebase_source : 743828adfe9dfda93480a5372697989a77492d52
I verified the behavior is the same by replacing StringUtils.join with
TextUtils.join in the StringUtils.join test (which passed) before deleting it
all.
MozReview-Commit-ID: 1pmSdTuG0LU
--HG--
extra : rebase_source : 5d596b28f27f540a6ac57217b9e134e267e823e7
extra : source : 9cdc0fcca44abc8f2ec1ea8f853ca31f8d59ce10
The implementation of magnifying glass is changed from ImageView to ImageButton which causes to this gray background.
To keep it have same visual, we have to configure it with transparent background.
MozReview-Commit-ID: 33zYpylOzsC
--HG--
extra : rebase_source : a3d8ff4d00243e1c12465b8f67ccba337d62f34c
flush() invalidates all buffers so buffer callbacks emitted earlier than that should not proceed when they're executed after.
MozReview-Commit-ID: 3KjCmW2VwTy
--HG--
extra : rebase_source : 11ea4f017e3add355f70762f8f43f82829f9ccd2
We already have logo icons in different branding folders, the following 4 icons are redundant and
should be removed to prevent increasing APK size.
- australis/res/drawable-hdpi/firefox_logo.png
- australis/res/drawable-xhdpi/firefox_logo.png
- australis/res/drawable-xxhdpi/firefox_logo.png
- australis/res/drawable-xxxhdpi/firefox_logo.png
MozReview-Commit-ID: COWXJsYrAVE
--HG--
extra : rebase_source : 792c3406a906985fca142674a63498b8a5ea44fd
Add a sample implementation of PermissionDelegate for geckoview_example;
Because the prompt code has some existing boilerplate, the actual
prompts are implemented in BasicGeckoViewPrompt.
MozReview-Commit-ID: EDfmRPn4cjR
--HG--
extra : rebase_source : 3b4b770c606a9be3326bca3acd87770c5f8bb4fa
Add PermissionDelegate interface and implement support for Android and
content permissions (WebRTC permissions will be implemented later).
MozReview-Commit-ID: 1B2DUjh8Ajw
--HG--
extra : rebase_source : 7c0a4489b136100ca57740512436bb8cccc62f3a
Add GeckoViewPermission.js, which is responsible for handling requests
from Gecko for permissions, and passing those requests to GeckoView.
MozReview-Commit-ID: C0g24hKEYbf
--HG--
extra : rebase_source : fe949fde01ddba207b12f2bd49e52ea2bc8b8c5e
For a lot of GeckoView content process code, we send a message from
content to chrome, using a message manager, only to forward the message
to Java as an event, using an event dispatcher. This patch gives
Messaging.jsm the ability to be used in content process directly, and
lets events transparently pass through to Java.
MozReview-Commit-ID: 15dKKpQCXqJ
--HG--
extra : rebase_source : 3ab93052de3676244843c55c50ae5ade63ab8f11
It would be nice to reuse GeckoViewHandler for delegates too (e.g. for
the new PermissionDelegate), but delegates need to always listen to
their events. This patch adds an "always listen" option for
GeckoViewHandler that still keeps track of the current listener/delegate
instance, but registers for all events at initialization rather than
only when there is a listener.
MozReview-Commit-ID: JtskpZMy9T4
--HG--
extra : rebase_source : 99170bc0b19d605dde4dbf08690bb31d310ed113
Include necessary WebRTC files and permissions for GeckoView. For
permissions, we need to add the RECORD_AUDIO permission to GeckoView's
AndroidManifest.xml, but since the file is not preprocessed, we can't
use an `#ifdef MOZ_WEBRTC` block, so I think we'll just have to
unconditionally include the permission.
MozReview-Commit-ID: IUd8FFMsW99
--HG--
extra : rebase_source : b75462d53e6bd05b324e8551c888853c8678ec6b
I verified the behavior is the same by replacing StringUtils.join with
TextUtils.join in the StringUtils.join test (which passed) before deleting it
all.
MozReview-Commit-ID: 1pmSdTuG0LU
--HG--
extra : rebase_source : 3c20a5ceccaebd3d30a935b3ea20c87ace7d628f
extra : source : 9cdc0fcca44abc8f2ec1ea8f853ca31f8d59ce10
In order to get Firefox to work with multiple built-in languages, we want
to bundle the same file in desktop as we do in fennec - res/multilocale.json
MozReview-Commit-ID: BY1cMYd0q8Q
--HG--
extra : rebase_source : 4bc95d0055a98869481324654d9e91bdf0734894
New upstream stable release.
Unions (untagged enums) for (unsafe) interoperability with C.
The `break` keyword can yield an expression value from a `loop`.
Non-capturing closures coerce to function pointers.
Numeric initializers for tuple structs.
MozReview-Commit-ID: 6TMjzXZuBKg
--HG--
extra : rebase_source : 3596ad4a1a1e299a4520fe064389912aeb986968
Grisha showed me the link from Android API level to SQLite version and
presumably all 3.7.* releases are forwards compatible so we can relax the
requirement of which version of Android the test DBs need to be created on: I
updated the comment accordingly.
MozReview-Commit-ID: Fhu95671kSK
--HG--
extra : rebase_source : 65bb4f565c1e5c64d91292077084324ba6f40dd6
This will be used to join with the PageMetadata table so we can extract
PageMetadata values in our top sites queries.
MozReview-Commit-ID: EmwjyFM1qUf
--HG--
extra : rebase_source : 54888226238ad4d25bbe6e8c1c34bcaef2522288
This change is fixing an issue unrelated to this bug.
It was using Visits.HISTORY_GUID, which is not in the table and thus doesn't
make sense for the first clause of the foreign key constraint. Visits & its
replacement have the same value so the behavior should not change.
MozReview-Commit-ID: 8EbJh586DN3
--HG--
extra : rebase_source : 91c54707cb021528144df81a369ae813ace9e975
add handling of about:home in intent.data explicitly.
MozReview-Commit-ID: D46VVQaR0Z1
--HG--
extra : rebase_source : 37db2673e52f28ac6db216417ac88337dafdfb6d
I verified this fixed the issue by:
- Attaching a debugger and checking against the STR call order (comment 3).
- Ensuring the favicons in the SearchEngineRow looked correct
MozReview-Commit-ID: GJeh3FLim36
--HG--
extra : rebase_source : 2511fde68599e5a1ae2096ee186704e064426754
onSizeChanged should only be called when the size actually changes. However,
I did notice weird behavior in the debugger where `formatImage` appeared to be
called twice from onSizeChanged, however, I was unable to reproduce this
behavior with log statements.
MozReview-Commit-ID: A5amGqTxv55
--HG--
extra : rebase_source : 1a53346d35102f1925941d3723c369f6b276ec5a
Sebastian Hengst
Michael Comella
Wes Kocher
Nick Alexander
Luca Greco
Dylan Roeh
John Lin
Jim Chen
James Willcox
Rajesh Kathiriya
Thomas Nguyen
Mike Hommey
Carsten "Tomcat" Book
Bevis Tseng
maliu
Edouard Oger
Mehdi Soleimannejad
Sebastian Kaspari
cnevinc
Eugen Sawin
Kaku Kuo
James Cheng
Nevin Chen
Chenxia Liu
Tushar Saini (:shatur)
L10n Bumper Bot
Delphine Lebédel
jwu
Johann Hofmann
Ryan VanderMeulen
Michael Kaply
jwu
Isaac Schemm
Zibi Braniecki
Bob Clary
Tomislav Jovanovic
Jan Henning
Ralph Giles
friedger
Munro Mengjue Chiang