This patch removes the need to process() and then match() on every intent processor.
A successful process() means that we already matched. Doing this in two steps caused
issues when the process() failed but later the simple check in match() returned true.
After this patch lands I intent to remove the match() API from the IntentProcessor
interface in AC:
https://github.com/mozilla-mobile/android-components/issues/6097
* For #4977 - Support opening Fennec pinned website shortcuts in Fenix
Fennec's pinned website shortcuts are set to open the BrowserApp activity.
So we need a new activity alias to actually catch such Intents. Otherwise they
would open "org.mozilla.firefox/.App" without any way to inform that this is
the result of the user clicking on a pinned shortcut.
For actually checking if the newly received Intent is of a Fennec pinned
shortcut we introduce a new FennecBookmarkShortcutsIntentProcessor which will
prepare the Intent to open the shortcut's URL in a new tab.
* For #4977 - Don't keep IntentReceiverActivity on the back stack
For successive Fennec pinned shortcuts to create a new IntentReceiverActivity
and be processed as normal we need to not keep this as our task root.
* For #4977 - Test the FennecBookmarkShortcutsIntentProcessor
* For #5334: added private custom tab processor
* For #5334 - Fixes up IntentReceiverActivity for handling intents
* For 5334: update styling for private custom tabbs
* For 5334: update tests to account for new processors
Note that two are still failing. These appear to be true failures, and will be corrected in a later commit.
* For 5334: fixes bug introduced by changes to IntentReceiverActivity
RCA: intent className and extra were previously set based on which processors matched, not which successfully processed. This patch reintroduces that behavior.
* For 5334: add tests for custom tabs processing
This patch includes:
- WebChannels support enabled by default, with ability to disable it via remote flag
- expanded FxA telemetry (closes#4971)
Co-authored-by: Arturo Mejia <arturomejiamarmol@gmail.com>
Fixes#1771.
This PR protects against the initial `NullPointerException` ever happening.
This is a rare case, and we do not have anything to go on at this point, so we fallback to a new intent, and the user is routed to the home activity.