GitLab

7785: Import strings from android-l10n. r=jonalmeida a=mozilla-l10n-automation-bot

n/t
Co-authored-by: Mozilla L10n Automation Bot <release+l10n-automation-bot@mozilla.com>

7716: No issue: add Activity.reportFullyDrawnSafe. r=NotWoods a=mcomella

The production method is imported from Fenix:
    https://github.com/mozilla-mobile/fenix/blob/69020a1f269c57e86fb4eb1dfd25d3ea168b5a29/app/src/main/java/org/mozilla/fenix/ext/Activity.kt#L28



And was verified to address the issue it was added for.
Co-authored-by: Michael Comella <michael.l.comella@gmail.com>

The production method is imported from Fenix:
    https://github.com/mozilla-mobile/fenix/blob/69020a1f269c57e86fb4eb1dfd25d3ea168b5a29/app/src/main/java/org/mozilla/fenix/ext/Activity.kt#L28

And was verified to address the issue it was added for.

7273: For #4637 - Query manifests with share targets r=grigoryk a=NotWoods

My intent is to expose this function so that we can use it with the Fenix custom share sheet.

We want to support sharing from websites to PWAs. PWAs can define a "share target" which will receive sharing data. We can expose PWAs in the custom share sheet so that other websites can send data to them.
Co-authored-by: Tiger Oakes <toakes@mozilla.com>

7578: Closes #6460: Upstream RunWhenReadyQueue r=grigoryk a=NotWoods



7629: Enable incremental room kapt processing r=grigoryk a=NotWoods

This saves us nearly 6 minutes in the artifact transformations stage.

7780: Expose l10n strings by default (fix #7777) r=Amejia481 a=Pike

Use a wild card pattern to find localizable strings.

If you're having WIP strings, put them into another file that's
not name `strings.xml`.



7781: Trim whitespace from email & call context share r=Amejia481 a=sblatz
Co-authored-by: Tiger Oakes <toakes@mozilla.com>
Co-authored-by: Axel Hecht <axel@pike.org>
Co-authored-by: Sawyer Blatz <sdblatz@gmail.com>

7778: Update Glean to v31.4.1 r=travis79 a=travis79
Co-authored-by: Travis Long <tlong@mozilla.com>

Use a wild card pattern to find localizable strings.

If you're having WIP strings, put them into another file that's
not name `strings.xml`.

7746: Issue #7712: SearchActionProvider: Pass in suspending function instead of a Deferred<SearchEngine> r=csadilek a=pocmo

While integrating the provider into Fenix I came to the conclusion that it makes much more sense
to pass in a suspending function. With that the caller does not need to deal with scopes and
dispatchers themselves.

(Follow-up from #7713)
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>

While integrating the provider into Fenix I came to the conclusion that it makes much more sense
to pass in a suspending function. With that the caller does not need to deal with scopes and
dispatchers themselves.

7774:  GeckoView update (nightly) (20200720-140538) r=pocmo a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

7666: Closes #7665: Add support for converting TrackingProtectionPolicy to ContentBlocking.Setting r=Amejia481 a=jonalmeida
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>

7651: [RFC] Introducing an RFC process. r=csadilek,Amejia481,jonalmeida,psymoon,rocketsroger a=pocmo

Hey folks. A long time ago we briefly talked about having something like an RFC process to discuss larger changes before writing any code (I kind of tried that [for brower-state](https://github.com/pocmo/android-components/pull/3

) back then and it was quite helpful). I would like to revive that effort. And in true tautological fashion this is an RFC for having an RFC process.

A bunch of other projects have RFC processes too. I think what we need is a very lightweight version of that. We probably do not need a super elaborate and complicated process. The main goal here is to foster and document discussions around substantial(!) changes before writing code and opening a PR - and having this discussion open for everyone.

What do you think? I have been drafting a more detailed document describing the process for our documentation site. I'll attach it to that PR later.
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>

Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
Co-authored-by: Jonathan Almeida <jalmeida@mozilla.com>
Co-authored-by: Simon Chae <chaesmn@gmail.com>
Co-authored-by: Roger Yang <royang@mozilla.com>

7759: Issue #7753: EngineViewPresenter: Temporarily disable releasing of engine session. r=csadilek a=pocmo

That was a new behavior that was introduced with the migration to `BrowserStore/State` and, surprise!, it can cause a white page of death - even though the order of events look correct and make sense. Anyhow, more in #7753. I think we should temporarily disable this and continue to investigate the actual cause of the white page issue.
Co-authored-by: Sebastian Kaspari <s.kaspari@gmail.com>

7770:  Docs update (20200719-121015) [ci skip] r=pocmo a=MickeyMoz



7771:  Public Suffix List update (20200719-140547) r=pocmo a=MickeyMoz



7772:  GeckoView update (nightly) (20200719-140546) r=pocmo a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

7752: Import strings from android-l10n. r=pocmo a=mozilla-l10n-automation-bot

n/t
Co-authored-by: Mozilla L10n Automation Bot <release+l10n-automation-bot@mozilla.com>

7760: L10N uplift script r=pocmo a=grigoryk

A script to help us uplift l10n commits from the automation bot into release branches (or, whatever other branches we want).

You can use it with multiple branches, it defaults to a dry-run (no changes performed):
```
➜  android-components git:(l10nCherry) ✗ ./l10n-uplift.py releases/48.0 releases/44.0

Processing l10n commits for 'releases/48.0'...
Since 'releases/48.0' split off 'master', there were 8 commit(s) from release+l10n-automation-bot@mozilla.com.
Of those, 0 commit(s) already uplifted.
Need to uplift 8 commit(s).
Uplifting (dry-run)...

Processing l10n commits for 'releases/44.0'...
Since 'releases/44.0' split off 'master', there were 24 commit(s) from release+l10n-automation-bot@mozilla.com.
Of those, 24 commit(s) already uplifted.
Need to uplift 0 commit(s).
Nothing to uplift.
```

There's a "verbose" mode, as well. To actually perform the work, you have to pass in an "--uplift" parameter:
```
➜  android-components git:(l10nCherry) ✗ ./l10n-uplift.py releases/48.0 --verbose --uplift

Processing l10n commits for 'releases/48.0'...
Since 'releases/48.0' split off 'master', there were 8 commit(s) from release+l10n-automation-bot@mozilla.com.

Hashes of those commits on 'master' are: ['032ace1d', '0e790177', '65d9aa6d', 'b86e1c04', '37110f38', '79a81a7a', '6359ec7b', '743acf82']

Of those, 2 commit(s) already uplifted.
Hashes of commits already uplifted to 'releases/48.0': ['032ace1d', '0e790177']

Need to uplift 6 commit(s).
Hashes of commits to uplift from 'master' to 'releases/48.0': ['65d9aa6d', 'b86e1c04', '37110f38', '79a81a7a', '6359ec7b', '743acf82']

Uplifting (for real)...
Cherry picking 65d9aa6d from 'master' to 'releases/48.0'
Cherry picking b86e1c04 from 'master' to 'releases/48.0'
Cherry picking 37110f38 from 'master' to 'releases/48.0'
Cherry picking 79a81a7a from 'master' to 'releases/48.0'
Cherry picking 6359ec7b from 'master' to 'releases/48.0'
Cherry picking 743acf82

 from 'master' to 'releases/48.0'
Uplifted 6 commits from 'master' to 'releases/48.0'
```

It also works on Fenix, as well:
```
➜  fenix git:(master) ✗ ../android-components/l10n-uplift.py releases/v79.0.0

Processing l10n commits for 'releases/v79.0.0'...
Since 'releases/v79.0.0' split off 'master', there were 11 commit(s) from release+l10n-automation-bot@mozilla.com.
Of those, 0 commit(s) already uplifted.
Need to uplift 11 commit(s).
Uplifting (dry-run)...
```

I've made the "master" branch name easily configurable so that we can switch it later on to `main` or whatever else we pick.
Co-authored-by: Grisha Kruglov <gkruglov@mozilla.com>

7717: Closes #7702: Close unsupported extension pages on startup r=Amejia481 a=csadilek

Described the why here: https://github.com/mozilla-mobile/android-components/issues/7702#issue-656152408

 and in the comments below.

It's pretty easy to do, and aside from the described edge cases, this will also solve the problem when upgrading from GV 79 to 80 (from registerWebExtension to installBuiltIn) where we would otherwise end up with broken extension tabs (reader pages). Since that's the default behaviour too when uninstalling extensions, I would like to land this to prevent a bad user experience.
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>

to ContentBlocking.Setting.

We added the changes needed for Fenix to apply the policy settings they
need to the GeckoRuntime directly.

Since we require GeckoView changes to support the fix, we will let the
fix ride the train. However, to avoid breaking the build variants in
Fenix, we add the GeckoEngine extensions that are needed for the beta
variant. This would not give us the full benefits of the perf fixes,
but it will avoid regressing ETP changes should we upgrade the engine
and forget to apply changes we need for Fenix's GeckoProvider in beta.
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>

7758: Closes #7757: Add blob in default engine supported scheme r=Amejia481 a=rocketsroger
Co-authored-by: Roger Yang <royang@mozilla.com>

7755:  GeckoView update (beta) (20200717-140307) r=Amejia481 a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>

7756:  GeckoView update (nightly) (20200717-140306) r=Amejia481 a=MickeyMoz
Co-authored-by: MickeyMoz <sebastian@mozilla.com>