This bug is for crash report bp-116fba9d-20b9-4611-abf6-8c4fe0190311.

Java stack trace:

android.view.WindowManager$BadTokenException
	at android.view.ViewRootImpl.setView(ViewRootImpl.java:797)
	at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:265)
	at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:73)
	at android.app.Dialog.show(Dialog.java:282)
	at org.mozilla.gecko.prompts.Prompt.tryShowingInputPrompt(Prompt.java:194)
	at org.mozilla.gecko.prompts.Prompt.show(Prompt.java:139)
	at org.mozilla.gecko.prompts.Prompt.show(Prompt.java:112)
	at org.mozilla.gecko.prompts.PromptService.handleMessage(PromptService.java:52)
	at org.mozilla.gecko.EventDispatcher$3.run(EventDispatcher.java:356)
	at android.os.Handler.handleCallback(Handler.java:725)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:175)
	at android.app.ActivityThread.main(ActivityThread.java:5279)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:511)
	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
	at dalvik.system.NativeStart.main(Native Method)

Hello Kenneth - thanks for reporting - do you have steps to reproduce? Thanks.

Don't know of any reliable way to reproduce. Another crash is https://crash-stats.mozilla.com/report/index/5a9ef207-0a29-4051-9039-8b9170190305
These occurred on a Samsung GT-P3110 running Android 4.2.2 and I suspect a low amount of memory may have tickled the issue though I guess that's a bit speculative on my part. Thanks

Fennec team, can you investigate and if there's no leads feel free to downgrade the priority.

exception message for the initial crash is "Unable to add window -- token android.os.BinderProxy@41eddd00 is not valid; is your activity running?"

Not sure why it went in on P1 -- it happens irregularly around once or twice a week.
In any case I moved it to P2, but would be curious as to your findings.
When it happens again I'll try and make more of a note what happened.

Almost all crashes are on the release channel, marking as fix-optional for 67 in case an upliftable patch materializes in beta.

Has happened again on fennec 66, crash report 491f70f3-56e0-4412-a1a5-c8e4f0190417

Has crashed again on 68.1.1

For some reason copy and paste isn't working so I cannot link to the crash report.
Anyway firefox was closing down when the crash happened

This crash signature is showing up in the Focus 8.4.0 topcrash list too.

About 1000 crash reports from Fenix 104.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

:cpeterson, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Increasing severity to S2 to keep autonag happy, though this "top crash" only has three crash reports on Nightly 107.

This other crash signature might be related:

[@ java.lang.RuntimeException: at android.view.ViewRootImpl.setView(ViewRootImpl.java) ]

java.lang.RuntimeException: Adding window failed
	at android.view.ViewRootImpl.setView(ViewRootImpl.java:970)
	at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:384)
	at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:101)
	at android.widget.PopupWindow.invokePopup(PopupWindow.java:1471)
	at android.widget.PopupWindow.showAtLocation(PopupWindow.java:1235)
	at android.widget.PopupWindow.showAtLocation(PopupWindow.java:1202)
	at mozilla.components.browser.menu.BrowserMenu.show(BrowserMenu.kt:129)
	at mozilla.components.browser.menu.BrowserMenu.show$default(BrowserMenu.kt:3)
	at mozilla.components.browser.menu.view.MenuButton.onClick(MenuButton.kt:10)
	at android.view.View.performClick(View.java:6935)
	at android.view.View$PerformClick.run(View.java:26214)
	at android.os.Handler.handleCallback(Handler.java:790)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:164)
	at android.app.ActivityThread.main(ActivityThread.java:7000)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:441)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1408)

This crash signature spiked in Fenix 106.

https://crash-stats.mozilla.org/report/index/ca003154-1b81-46f0-b1c2-0959c0221102

android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running?
	at android.view.ViewRootImpl.setView(ViewRootImpl.java:958)
	at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:381)
	at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:100)
	at org.webrtc.SurfaceEglRenderer$$ExternalSyntheticLambda0.run(Unknown Source:15)
	at android.os.Handler.handleCallback(Handler.java:789)
	at android.os.Handler.dispatchMessage(Handler.java:98)
	at android.os.Looper.loop(Looper.java:164)
	at android.app.ActivityThread.main(ActivityThread.java:6944)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.Zygote$MethodAndArgsCaller.run(Zygote.java:327)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1374)

Nico Grunbaum says we updated libwebrtc in Gecko 106 (bug 1766646). I'll tentatively mark this bug as a possible regression from that update.

I don't see any bug reports in the WebRTC bug tracker that look like the same issue:

https://bugs.chromium.org/p/webrtc/issues/list

We are in 107 RC week, wontfix 106.

:cpeterson, I notice the bug is unassigned. Wondering if is there anyone actively investigating to confirm Comment 16 and Comment 17?
In the meantime, tracking this for 107 and 108 based on severity and crash volume.

We looked at this and do not feel it is webrtc related.

This crash ID is an aggregation of several Java stack traces. To evaluate where the crashes are coming from you need to use the aggregate tab to aggregate on Java stack trace raw. This will show that there is a regression in the signature that is correlated to org.webrtc.SurfaceEglRenderer in v106. To view Java stack trace raw information requires PII access.

https://crash-stats.mozilla.org/signature/?product=Fenix&java_stack_trace_raw=~org.webrtc.SurfaceEglRenderer&signature=android.view.WindowManager%24BadTokenException%3A%20at%20android.view.ViewRootImpl.setView%28ViewRootImpl.java%29

vs the unfiltered crash

https://crash-stats.mozilla.org/signature/?product=Fenix&signature=android.view.WindowManager%24BadTokenException%3A%20at%20android.view.ViewRootImpl.setView%28ViewRootImpl.java%29

Comparing the two shows that +80% are an egl WebRTC crash. Should we spin out a new bug for the regression?

The bug is marked as tracked for firefox107 (beta) and tracked for firefox108 (nightly). We have limited time to fix this, the soft freeze is in a day. However, the bug still isn't assigned.

:cpeterson, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

The only possibility we can come up with here is some sort of camera permissions prompt issue on a restart of the browser. (Uptimes are mostly 0 seconds.) Testing that scenario however indicates the prompts work correctly. We don't have urls in these reports, so we don't know what service they might be associated with.

We also looked at the code here in the sdk and didn't see any recent changes that might have triggered this.

There's one related bug over in the fennec graveyard, but this wasn't much help.

https://bugzilla.mozilla.org/show_bug.cgi?id=1627597

Prompt test page - https://jan-ivar.github.io/dummy/gum.html

At this point if this is webrtc related we have nothing to go on.

Additional context - the 106 release included a libwebrtc update which brought in over a year's worth of improvements authored by Google. Some of this work was performance related. So it seems reasonable to guess here that if we have a race related to prompt display early in startup in geckoview, improvements to the lib would tickle that issue more often.

I think it would be useful to get the geckoview teams thoughts on the error here - android.view.WindowManager$BadTokenException: Unable to add window -- token null is not valid; is your activity running? at android.view.ViewRootImpl.setView(ViewRootImpl.java:1002)

What might cause a null window token early in startup on a prompt?

(In reply to Kevin Brosnan [:kbrosnan] from comment #21)

Comparing the two shows that +80% are an egl WebRTC crash. Should we spin out a new bug for the regression?

Good idea: I filed bug 1799996 for the WebRTC-specific regression.

The Android Foundation (GeckoView) team will review that bug in our next triage.

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit auto_nag documentation.

wontfix Fenix 107-109.

Marking as P3 because Jonathan's changes in Bug 1799996 has reduced crash volume significantly; not sure of precise ways to address remaining volume without more concrete insight.

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 AArch64 and ARM crashes on beta

For more information, please visit auto_nag documentation.

Making this bug a meta bug because it is a generic signature for different crashes.