1977303 - Crash in [@ android.util.AndroidRuntimeException: at com.android.internal.policy.PhoneWindow.requestFeature(PhoneWindow.java)]

Status: VERIFIED FIXED

(Firefox for Android :: General, defect, P1)

Description

[Dianna Smith [:diannaS]]

Crash report: https://crash-stats.mozilla.org/report/index/09e5c007-77da-4820-9c92-30abb0250714

Top 10 frames:

0  com.android.internal.policy.PhoneWindow  requestFeature  PhoneWindow.java:324
1  android.app.Dialog  requestWindowFeature  Dialog.java:1126
2  androidx.fragment.app.DialogFragment  setupDialog  DialogFragment.java:22
3  androidx.appcompat.app.AppCompatDialogFragment  setupDialog  AppCompatDialogFragment.java:35
4  androidx.fragment.app.DialogFragment  onGetLayoutInflater  DialogFragment.java:38
5  androidx.fragment.app.FragmentStateManager  createView  FragmentStateManager.java:32
6  androidx.fragment.app.FragmentStateManager  moveToExpectedState  FragmentStateManager.java:149
7  androidx.fragment.app.FragmentManager  executeOpsTogether  FragmentManager.java:1294
8  androidx.fragment.app.FragmentManager  removeRedundantOperationsAndExecute  FragmentManager.java:92
9  androidx.fragment.app.FragmentManager  execPendingActions  FragmentManager.java:150

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to topcrash signatures, which match the following criterion:

• Top 10 AArch64 and ARM crashes on nightly

For more information, please visit BugBot documentation.

Comment 2

[Dianna Smith [:diannaS]]

:calu im not sure what could be the cause here but it started in build 20250711212455. any ideas?

Comment 3

[Dianna Smith [:diannaS]]

:will could this have been caused by bug 1972780?

Comment 4

[William Durand [:willdurand]]

I looked into crash stats and Sentry and there is nothing that seems related to that bug (or the other ones I fixed recently). Maybe Bug 1972159?

Comment 5

[Dianna Smith [:diannaS]]

Thank you for looking!

:gl can you check and see? It was a top crasher although the volume seems lower now.

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

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

:calu, 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 BugBot documentation.

Comment 7

[Andrew McCreight [:mccr8]]

I was wondering about why the performPauseActivity signature was added to the bug, despite not talking about phone stuff, but it looks like the exception for that is java.lang.RuntimeException: Unable to pause activity {org.mozilla.fenix/org.mozilla.fenix.App}: android.util.AndroidRuntimeException: requestFeature() must be called before adding content, whereas the exception for the phone signature are look like android.util.AndroidRuntimeException: requestFeature() must be called before adding content so that explains it.

Comment 8

[Jonathan Almeida [:jonalmeida]]

Attachment: reproduction.webm

I can reproduce this consistently with an API 23 emulator with a debug build from a code checkout that happened at 15-04-2025. With my debugger, I see the crash happen at this point during the navigation from the tabs tray.

I haven't bisected this further, but maybe that will be helpful if calu can take a peek - I see you worked in this area recently. WDYT?

EDIT: just to clarify, the crash stats link showed me that all the crashes are happening on API 23 only, which is why I decided to use an emulator with that version.

Comment 9

[Jonathan Almeida [:jonalmeida]]

I paired with calu on this where we identified that the tabstray is not the cause but instead the SearchDialogFragment that is called from it instead.

After some more debugging, I think I've identified the regressor as bug 1976746 - it was me! I'm currently looking at how best to fix this without backing out the regressor which will require backing out another dependant patch too.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1976746

Comment 11

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

We need to request the window feature that we are using while also
using the DialogFragment.STYLE_NORMAL because after bug 1976746,
we are no longer avoiding insets being applied to lower API
versions.

This is fine without tests since we are going to raise our minSDK
and the only reasonable way I can think of writing a test is to using
this SDK level in UI tests which would make the rest of the tests that
run on this level flaky.

I've tested this locally against an API 23 and 36 emulator; will request
QA testing as well when it lands.

Comment 12

[Dianna Smith [:diannaS]]

:jonalmeida ty!! can you submit an uplift request for this? If this lands soon, I can maybe get it into b3 for 142.

Comment 13

[Jonathan Almeida [:jonalmeida]]

I'd like to have this QA'd in nightly before the uplift because we can't increase test coverage for this and it can affect other API levels too (not as a crash, but a visual change). Would that be okay to hold off until then?

Comment 14

[Dianna Smith [:diannaS]]

yes that is great, I will monitor the crash volume before rolling out to a higher percentage.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/0e675cbac22c
https://hg.mozilla.org/integration/autoland/rev/7083ad966620
RequestWindowFeature for SearchDialogFragment r=calu,android-reviewers

Comment 16

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

We need to request the window feature that we are using while also
using the DialogFragment.STYLE_NORMAL because after bug 1976746,
we are no longer avoiding insets being applied to lower API
versions.

This is fine without tests since we are going to raise our minSDK
and the only reasonable way I can think of writing a test is to using
this SDK level in UI tests which would make the rest of the tests that
run on this level flaky.

I've tested this locally against an API 23 and 36 emulator; will request
QA testing as well when it lands.

Original Revision: https://phabricator.services.mozilla.com/D258528

Comment 17

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

We need to request the window feature that we are using while also
using the DialogFragment.STYLE_NORMAL because after bug 1976746,
we are no longer avoiding insets being applied to lower API
versions.

This is fine without tests since we are going to raise our minSDK
and the only reasonable way I can think of writing a test is to using
this SDK level in UI tests which would make the rest of the tests that
run on this level flaky.

I've tested this locally against an API 23 and 36 emulator; will request
QA testing as well when it lands.

Original Revision: https://phabricator.services.mozilla.com/D258528

Comment 18

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

We need to request the window feature that we are using while also
using the DialogFragment.STYLE_NORMAL because after bug 1976746,
we are no longer avoiding insets being applied to lower API
versions.

This is fine without tests since we are going to raise our minSDK
and the only reasonable way I can think of writing a test is to using
this SDK level in UI tests which would make the rest of the tests that
run on this level flaky.

I've tested this locally against an API 23 and 36 emulator; will request
QA testing as well when it lands.

Original Revision: https://phabricator.services.mozilla.com/D258528

Comment 19

[Jonathan Almeida [:jonalmeida]]

Attachment: Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

We need to request the window feature that we are using while also
using the DialogFragment.STYLE_NORMAL because after bug 1976746,
we are no longer avoiding insets being applied to lower API
versions.

This is fine without tests since we are going to raise our minSDK
and the only reasonable way I can think of writing a test is to using
this SDK level in UI tests which would make the rest of the tests that
run on this level flaky.

I've tested this locally against an API 23 and 36 emulator; will request
QA testing as well when it lands.

Original Revision: https://phabricator.services.mozilla.com/D258528

Comment 20

[Jonathan Almeida [:jonalmeida]]

Comment on attachment 9502798 [details]
Bug 1977303 - RequestWindowFeature for SearchDialogFragment r=calu

(I tried using the new Lando uplift request and ended up with multiple patches and no approval request form - sorry!)

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Crashes in beta.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Using a device on Android 6 (API 23), click on the address or create a new tab from the tabs tray.

2. Using a device on Android 12 (API 32), click on the address or create a new tab from the tabs tray.
3. In step 1, there should be text focus on the search bar and the app should not crash.
4. In step 2, there should be text focus on the search bar and the search bar position does not move.

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This change does not have UI test coverage because it's for an API level we will no longer be supporting soon. Manual QA verification to notice any visual mistakes is recommended.
• String changes made/needed: n/a
• Is Android affected?: Yes

Comment 21

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/7083ad966620

Comment 22

[Vasilica Tamas (Android QA) [:vtamas]]

Attachment: AddressBarFlicker.mp4

The QA team tested this fix on Firefox for Android 143 (2025-07-24) using the following devices with Android 12: Samsung Galaxy Note 8, Motorola Moto G30, Lenovo Yoga Tab 11, Xiaomi 12 T, Realme C35 and Samsung A13. Confirming that the address bar is successfully focused when opening a new tab from tabs tray but the flicker still persists - this may be related to Bug 1890636.

Unfortunately, we didn't have an Android 6 available for testing.

Comment 23

[Dianna Smith [:diannaS]]

:jonalmeida I'm holding beta 3 mobile to give this more time. Should we move forward given that we don't have an Android 6 available to confirm? I am not pressed to build this AM, I can wait until nightly shows signs of improvement

Comment 24

[Vasilica Tamas (Android QA) [:vtamas]]

The QA team will be able to provide results on a physical Android 6 device on Monday, as the colleague who has access to it is on PTO until then.

Comment 25

[Jonathan Almeida [:jonalmeida]]

(In reply to Dianna Smith [:diannaS] from comment #23)

:jonalmeida I'm holding beta 3 mobile to give this more time. Should we move forward given that we don't have an Android 6 available to confirm? I am not pressed to build this AM, I can wait until nightly shows signs of improvement

I was most concerned about regressions in non-Android 6 devices, if we landed this patch in beta and it didn't reduce the crash rate, that would also be okay to me because we haven't made the situation worse.

Let's move forward if you agree as well. Thank you for the discussion and holding the release!

Comment 26

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/da134ff043f1
https://hg.mozilla.org/releases/mozilla-beta/rev/dddc55a449c7

Comment 27

[Adina Petridean QA [:apetridean]]

I was not able to reproduce this issue on the Sony Xperia Z2 (Android 6.0.1) and the OnePlus A3000 (Android 6). I tried using Nightly builds from 15.04.2025, 20.04.2025, and the latest Nightly build 143.0a1 from 27.06.2025.

Comment 28

[Adina Petridean QA [:apetridean]]

Attachment: Screen Recording 2025-07-28 at 18.07.06-1.mov

Comment 29

[Adina Petridean QA [:apetridean]]

Later edit: Reproduced this issue with OnePlus A3000 (Android 6) and Sony Xperia Z2 (Android 6.0.1) on the latest Firefox beta 142.0b3.
Steps: 1. Open the FX app.
2. Tap on the tabs tray.
3. Tap on the PB icon.
4. Tap on the +PRIVATE button.
5. Observe the behavior.

Please check the attached video recorded on Nightly 143.0a1 – 26.07.2025, where the issue appears to be fixed.

Comment 30

[Adina Petridean QA [:apetridean]]

Verified as fixed on Fenix 142.0b4 with OnePlus A3000 (Android 6) and Sony Xperia Z2 (Android 6.0.1).