For photon we need to add some colors.
I don't want change current color and dimen too much. I want to add new resources if possible to avoid confliction.
For Tab Items, there are three layout
1. AutoFitTabsGridLayout. Used in tablet-land/port and phone-land
2. CompactTabsGridLayout. Used in phone-port(with pref on)
3. TabsListLayout. Used in phone-port(default)
In 1.2, we only constrain the gap of the Tab item padding and the layout padding.
In 3, we restrain the thumbnail width to 137dp .
I also make the tab strip longer for tablet. And I change the color of tab item border and set the thumbnail ratio to 4:3.
We might need to remove unused resources and test different density(2.6 and 3 are all xxhdpi!) and sw240,sw360,sw400 combination.
MozReview-Commit-ID: Gp25nG8NkR5
--HG--
extra : rebase_source : d33751ed37f5bc3aae46bcbc95f4906fcbb833f8
The bootstrap catalog is outdated and downloading files from it returns in 404 errors from the CDN.
It's impossible to keep the bootstrap catalog updated. Instead let's start with an empty catalog
and rely on the latest catalog that we synchronize from Kinto.
MozReview-Commit-ID: FduZWJBvj16
--HG--
extra : rebase_source : 46f6d1492d6c291254261dc04a0fb75f78ca1cdf
These rules are just convenience, both for developers and automation.
Instead of having to hard-code to run make in a particular directory to
do l10n-repacks, you can now just do
./mach build installers-de
and that's that.
MozReview-Commit-ID: C4WKXljjN7n
--HG--
extra : rebase_source : f305bb2bc0ddb4712c8b28f5225fd8ad22a16055
To not merge the en-US language pack, the merge-% steps are in
a conditional function that disables that for en-US. Using a function
here as that's easier than a shell if in the merge rule, and
Makefile conditionals don't get evaluated late enough.
To liberate the l10n builds from settings in the automation,
we move the patch logic from LOCALE_MERGEDIR to REAL_LOCALE_MERGEDIR.
To determine strongly when we're in a repack or building a langpack,
the trick here is to
export IS_LANGUAGE_REPACK
in l10n.mk, and only set that to true in the entry-point rules.
Now, we can use that value in config.mk to define the l10n-specific
rules.
I did the same thing for langpack-%, which allows us to disable
the crashreporter files for language packs, for example.
With that,
make installers-de
just works, if you have localizations checked out.
For a while, we might run l10n-merge twice in automation, but it's really not
optional, so let's just make sure we run it.
MozReview-Commit-ID: 3nr33CKxkBQ
--HG--
extra : rebase_source : 0605a4adba018fa4b85d563cdafba80b0533bc91
Set AB_CD on per-locale entry point pattern rules.
Not setting this on the repackaging top-level pattern rules, as they
need AB_CD to be en-US to find the original package to unpack.
MozReview-Commit-ID: JqrLYyEyvvb
--HG--
extra : rebase_source : 82c840f16e131fe8f340e21ff86a34c70e3f7f97
- use EOJ's handy .equals() to compare JSON structures
- generated DSA signature prefix seem to have changed post Java 1.8 update
MozReview-Commit-ID: JwQLb998Kro
--HG--
extra : rebase_source : 802045c6ad6f2c46e34c9765022c5707c65ee3e6
There's some racing going on between compositor methods that use the
XPCOM queue and the disposeNative method that uses the priority queue.
Move everything to the XPCOM queue to fix this condition.
MozReview-Commit-ID: BUxotrpBVsW
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.
Edouard Oger
Nevin Chen
Sebastian Kaspari
Axel Hecht
Karl Dubost
Tushar Saini (:shatur)
Masatoshi Kimura
Rajesh Kathiriya
James Cheng
Grigory Kruglov
Wes Kocher
Gian-Carlo Pascutto
Jim Chen
Luca Greco
Sebastian Hengst
Luciano Italiani
Michael Comella
Nick Alexander
Dylan Roeh