Consider adding new build defines or test condition defines for different Flavors of Android
Categories
(Fenix :: Tooling, enhancement)
Tracking
(Not tracked)
People
(Reporter: olivia, Unassigned)
References
(Blocks 1 open bug)
Details
Right now, in Gecko, we can use an android build define when we need to block or branch code on android. This platform list has a list of these flags. It would be nice to have build defines for focus, fenix, and geckoview-test-runner as well.
The first use case would be bug 1880376. In that bug, visibilityState works in Fenix, but not in the pure GeckoView test runner. (So we would potentially like to run tests for fenix but not geckoview-test-runner.)
|
Reporter | |
Comment 1•9 months ago
|
||
(I have a sense Fennec may have had these flags based on the stale documentation, but am not 100% sure.)
|
||
Comment 2•9 months ago
|
||
I assume these will also be exported and to be used via mozinfo so that it can be used as well for test expectations in manifest files?
|
|
Reporter | |
Comment 3•8 months ago
•
|
||
Should say, I'm mostly interested in test condition defines.
We don't want to encourage breaking or misusing the GeckoView layer by overuse of build defines in the product, but I think they could have their uses when applied carefully. For example, if something is much easier to do on the platform layer that we wish to only impact Fenix and the change wouldn't benefit other GV consumers. (So, the delegate framework is a massive overhead.) Thought is situations like bug 1833277 with more info here, when it could be beneficial to have different product behavior without hurting the GV philosophy too much, since no other consumers will be interested in those changes.
|
|
Reporter | |
Updated•8 months ago
|
|
||
Comment 4•8 months ago
|
||
An idea: maybe it would make sense to expose an API in GV to get application id or something like that. I am not entirely convinced this should be a cpp level define.
Description
•