Closed Bug 2012763 Opened 4 months ago Closed 2 months ago

Consider updating NimbusGeckoPrefHandler architecture and follow-ups

Categories

(Firefox for Android :: Experimentation and Telemetry, task, P1)

All
Android
task

Tracking

()

RESOLVED FIXED
150 Branch
Tracking Status
firefox149 --- wontfix
firefox150 --- fixed

People

(Reporter: olivia, Assigned: olivia)

References

(Blocks 1 open bug)

Details

(Whiteboard: [group6][fxdroid])

Attachments

(6 files, 1 obsolete file)

:jonalmeida and I discussed some potential architecture changes for how NimbusGeckoPrefHandler is situated. It might be better for it to be a part of browser-engine-gecko. This bug is to follow-up on if that is a possible and desirable change.

It might also be necessary to change the abstraction layer from Gecko calls to AC in NimbusGeckoPrefHandler because the observer is likely going to require AC abstractions in bug 2006095. The mixing and matching of abstractions feels like it adds architecture debt.

This bug might be for concept-engine. Leaving the same title until we do more investigation.

Also, should look to try and increase testing coverage for this project.

Assignee: nobody → ohall
Summary: Consider updating NimbusGeckoPrefHandler to browser-engine-gecko → Consider updating NimbusGeckoPrefHandler architecture and follow-ups
Priority: P3 → P1

When refactoring NimbusGeckoPrefHandler, it became more clear having
the explicit Gecko preference type names would be helpful.

The original implementation expected being able to infer the type from the
T type of value. However, this seems brittle due to multiple sources of types
and the fact that T should only ever be one of three values or is else invalid.

Additionally, coordinating between the Kotlin types that can come from Java or Rust also
increased the questionability of how accurate the T type might be when used on
a when statement when attempting to convert into a SetGeckoPreference.

This patch passes the information along on the BrowserPreference object
to be more explicit of the preference type expectations.

This patch:

  • Adds experiments/prefhandling directory and moves associated files
  • Moves helper/extension functions from NimbusGeckoPrefHandler to NimbusGeckoPrefHandlerExtensions
  • Refactors GeckoView method calls to Android Components calls and adds engine dependency
  • Some documentation/refactoring to consolidate and name throwables
  • Additional test coverage
Blocks: 1908182, 2001415

This patch:

  • Converts NimbusGeckoPrefHandlerTest away from a singleton to a
    constructed element that takes an engine an nimbusApi.
  • Reorganizes how observer registration occurs by adding a start function.

This patch:

  • Adds experiments/prefhandling directory and moves associated files
Attachment #9547759 - Attachment description: WIP: Bug 2012763 - Part 3: Add constructor to NimbusGeckoPrefHandlerTest → WIP: Bug 2012763 - Part 4: Add constructor to NimbusGeckoPrefHandlerTest

There is a bug where preference types sometimes haven't been fetched when setting.
Knowing the types is required because Nimbus sends all preferences over as strings.

This patch adds a check in these cases and will fetch the type information,
if it is missing.

Attachment #9547759 - Attachment description: WIP: Bug 2012763 - Part 4: Add constructor to NimbusGeckoPrefHandlerTest → WIP: Bug 2012763 - Part 4: Add constructor to NimbusGeckoPrefHandler
Attachment #9547420 - Attachment description: WIP: Bug 2012763 - Part 2: Refactor NimbusGeckoPrefHandler → Bug 2012763 - Part 2: Refactor NimbusGeckoPrefHandler
Attachment #9547863 - Attachment description: WIP: Bug 2012763 - Part 3: Move files to folder → Bug 2012763 - Part 3: Move files to folder
Attachment #9547759 - Attachment description: WIP: Bug 2012763 - Part 4: Add constructor to NimbusGeckoPrefHandler → Bug 2012763 - Part 4: Add constructor to NimbusGeckoPrefHandler
Attachment #9548040 - Attachment description: WIP: Bug 2012763 - Part 5: Fix issue when preference type isn't known → Bug 2012763 - Part 5: Fix issue when preference type isn't known
See Also: → 2019616

Just to catch this early, on the Try at (https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=N1jd89nsTlSioYtz8JR1ZQ.0&searchStr=ui-&revision=b77bc47fae0945307556a9e7b9951ecffd7b6c4b) I see some shards in the ui-test-arm jobs crashing in loop with

Matrix: link

java.lang.IllegalThreadStateException: Expected thread 2 ("main"), but running on thread 68 ("DefaultDispatcher-worker-1")
     FATAL EXCEPTION: DefaultDispatcher-worker-1
Process: org.mozilla.fenix.debug:mozilla.components.lib.crash.CrashHandler, PID: 8623
java.lang.IllegalThreadStateException: Expected thread 2 ("main"), but running on thread 68 ("DefaultDispatcher-worker-1")
	at org.mozilla.gecko.util.ThreadUtils.assertOnThreadComparison(ThreadUtils.java:141)
	at org.mozilla.gecko.util.ThreadUtils.assertOnThread(ThreadUtils.java:107)
	at org.mozilla.gecko.util.ThreadUtils.assertOnUiThread(ThreadUtils.java:84)
	at org.mozilla.geckoview.GeckoRuntime.create(GeckoRuntime.java:652)
	at org.mozilla.fenix.gecko.GeckoProvider.createRuntime(GeckoProvider.kt:61)
	at org.mozilla.fenix.gecko.GeckoProvider.getOrCreateRuntime(GeckoProvider.kt:40)
	at org.mozilla.fenix.components.Core.geckoRuntime_delegate$lambda$0(Core.kt:278)
	at org.mozilla.fenix.components.Core.$r8$lambda$VDoFJR2vLCdc212UPXEn2LofB-k(Unknown Source:0)
	at org.mozilla.fenix.components.Core$$ExternalSyntheticLambda28.invoke(D8$$SyntheticClass:0)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)
	at org.mozilla.fenix.components.Core.getGeckoRuntime(Core.kt:277)
	at org.mozilla.fenix.components.Core.engine_delegate$lambda$0(Core.kt:248)
	at org.mozilla.fenix.components.Core.$r8$lambda$w-bBz4uVQbTj_b2pNcVVXsc48Ao(Unknown Source:0)
	at org.mozilla.fenix.components.Core$$ExternalSyntheticLambda22.invoke(D8$$SyntheticClass:0)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)
	at org.mozilla.fenix.components.Core.getEngine(Core.kt:158)
	at org.mozilla.fenix.components.Components.nimbus_delegate$lambda$0$0(Components.kt:231)
	at org.mozilla.fenix.components.Components.$r8$lambda$pbObrpLwg0ATx4D7F8bKQZyGIsY(Unknown Source:0)
	at org.mozilla.fenix.components.Components$$ExternalSyntheticLambda34.invoke(D8$$SyntheticClass:0)
	at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:86)
	at org.mozilla.fenix.components.NimbusComponents.geckoPrefHandler_delegate$lambda$0(NimbusComponents.kt:48)
	at org.mozilla.fenix.components.NimbusComponents.$r8$lambda$e9HlduSNysmcdey82pGBh8S5DeY(Unknown Source:0)
	at org.mozilla.fenix.components.NimbusComponents$$ExternalSyntheticLambda2.invoke(D8$$SyntheticClass:0)

Which bubbles down to

	at org.mozilla.fenix.crashes.NimbusExperimentDataProvider.getExperimentData(NimbusExperimentDataProvider.kt:23)
	at mozilla.components.lib.crash.runtimetagproviders.ExperimentDataRuntimeTagProvider.invoke(ExperimentDataRuntimeTagProvider.kt:62)
	at mozilla.components.lib.crash.CrashReporter.getRuntimeTags(CrashReporter.kt:154)
	at mozilla.components.lib.crash.CrashReporter.onCrash$lib_crash_debug(CrashReporter.kt:312)
	at mozilla.components.lib.crash.handler.ExceptionHandler.uncaughtException(ExceptionHandler.kt:44)
	at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1071)
	at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1066)
	at kotlinx.coroutines.internal.CoroutineExceptionHandlerImplKt.propagateExceptionFinalResort(CoroutineExceptionHandlerImpl.kt:31)

Thanks, yeah! I had noticed they were orange and was working through it today.

I had a T test failure earlier that was truly an intermittent, so I was front-loaded into thinking this one was too since it was green on the second attempt. I had opened up for review while I investigated.

  • This patch removes the existing test Nimbus FML due to bug 2020683
  • Improves null case handling from (!!) to silently continuing as it is
    unrecoverable
Blocks: 2020769
Blocks: 2020683
Blocks: 2021139
  • This patch removes the existing test Nimbus FML due to bug 2020683
Attachment #9557420 - Flags: approval-mozilla-release?

firefox-release Uplift Approval Request

  • User impact if declined/Reason for urgency: No user impact.

Has CI impact as we are ingesting the FML files from central/beta/release into experimenter and this one has become invalid due to the feature having both "gecko-pref" and "default" as of application-services 150.

  • Code covered by automated testing?: no
  • Fix verified in Nightly?: yes
  • Needs manual QE testing?: no
  • Steps to reproduce for manual QE testing: N/A
  • Risk associated with taking this patch: low
  • Explanation of risk level: Configuration-only change. Feature is not used.
  • String changes made/needed?: N/A
  • Is Android affected?: yes
Attachment #9557420 - Flags: approval-mozilla-release? → approval-mozilla-release+
Regressions: 2027633

Removed test and fml over in bug 2027633.

Comment on attachment 9557420 [details]
Bug 2012763 - Part 6: Remove Nimbus FML

This can ride the 150 train.

Attachment #9557420 - Flags: approval-mozilla-release+ → approval-mozilla-release-
Attachment #9557420 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: