Closed Bug 1555332 Opened 2 years ago Closed 1 year ago

Crash in [@ java.lang.IllegalStateException: at android.support.v7.app.AppCompatDelegateImpl.createSubDecor(AppCompatDelegateImpl.java)]

Categories

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

Firefox 68
Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- fixed
firefox68 --- wontfix
firefox69 --- unaffected
firefox70 --- unaffected

People

(Reporter: marcia, Assigned: petru)

References

Details

(Keywords: crash, Whiteboard: [fennec68.1])

Crash Data

This bug is for crash report bp-3a46ee2b-4f84-4205-b909-aab790190528.

New 68 crash which appears to have started in b3: https://mzl.la/2ECtajJ. Only a handful of devices, mostly running API 28. Looks like something theme related - did we make any theme changes?

java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.
at android.support.v7.app.AppCompatDelegateImpl.createSubDecor(AppCompatDelegateImpl.java:555)
at android.support.v7.app.AppCompatDelegateImpl.ensureSubDecor(AppCompatDelegateImpl.java:518)
at android.support.v7.app.AppCompatDelegateImpl.setContentView(AppCompatDelegateImpl.java:466)
at android.support.v7.app.AppCompatActivity.setContentView(AppCompatActivity.java:140)
at org.mozilla.gecko.GeckoApp.onCreate(GeckoApp.java:1090)
at org.mozilla.gecko.BrowserApp.onCreate(BrowserApp.java:643)
at android.app.Activity.performCreate(Activity.java:7326)
at android.app.Activity.performCreate(Activity.java:7317)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3066)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3229)
at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:78)
at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:108)
at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:68)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1926)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:6981)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1445)

Not too many crashes, the last ones so far in 68.0b7

Priority: P1 → P3

This is back on 68.0 release. :(

Petru, can you maybe take a look or redirect?

Flags: needinfo?(petru.lingurar)

This seems very interesting because that code from the stack trace is always called.
So if it was to be a problem with the theme I'd assume it would result in a 100% crash. Why would it be ok in most of the cases but not in some ... ?
Will investigate.

Assignee: nobody → petru.lingurar
Status: NEW → ASSIGNED
Flags: needinfo?(petru.lingurar)

BrowserApp has the theme set here.
It's Gecko.App theme extends Theme.AppCompat and has windowActionBar declared, which is what Android checks and throws that Exception for.
So this issue indeed shouldn't happen. I'm thinking that the build may be corrupt ..?

Because the crashes seem to be piling up as a workaround for stopping them we could do

 TypedArray a = obtainStyledAttributes(R.styleable.AppCompatTheme);
   if (!a.hasValue(R.styleable.AppCompatTheme_windowActionBar)) {
       setTheme(R.style.Theme_AppCompat_Light_DarkActionBar);
   }
   a.recycle();

before

   setContentView(getLayout());

from which now the crash starts.

One of the comments mentions "Substratum Theme Error." Other than that, the current comments are not very useful.

Thanks Marcia!
This does indeed makes more sense as Substratum theming will indeed overwrite our styles and other assets.
I also saw reports coming from custom roms and a user saying that he uses a rooted device, all of this leading us to believe that this crashes are indeed because of external modifications.
Will try a few such themes in the hope that I'll be able to reproduce.

See Also: → 1389082

Found some easy STRs confirmed also by email with a reporter:

  • Have the Swift Dark Substratum theme Firefox overlay applied for the previous 67 release
  • Update to 68
  • Next app starts would result in an immediate app crash with the above stack trace

Solution to this is to update the Substratum overlay for our application.
The solution proposed in comment 5 (the best we could do) would in fact prevent this sort of customization so it isn't feasible.

Based on comment 5 and this I'll close this as WORKSFORME. This issue is entirely caused by an external modification and can also be resolved entirely by the user.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
Keywords: regression

WFM implies that the problem went away on its own. From what you're saying, it sounds like this is more of a wontfix.

That said, the crash volume is reaaalllllly high here (#4 overall). Do we have any idea why this only started spiking in 68? I'm not sure we can just ignore this issue so quickly.

Flags: needinfo?(petru.lingurar)
Resolution: WORKSFORME → WONTFIX

Petru - We talked a bit about this bug at the Channel meeting today. Is there anything else we can do on our end to reduce the amount of crashes - 2236 crashes/751 installations? Reopening for the moment while we continue the discussion.

Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

I don't think there is anything we can do.

The possibility that an application with external overlays applied would crash after update is documented in the Swift Themes documentation

When an app that has an overlay applied on it gets updated, there's very huge chances that it will start crashing. This is how dynamic overlays work and you are now aknowledging how these kind of crashes are not caused by bad coding in the themes. The best way you can keep things stable is by keeping automatic updates for all apps turned off on the Play Store. It will be your responsibility for apps crashing if you refuse to turn off automatic updates or deliberately update apps that have an overlay on top without then rebuilding the overlay accordingly, removing old overlays on the app, and ultimately remove all overlays on the app if the new update is causing issues, and patiently waiting for the new app version to be supported, if possible.
When you keep automatic updates turned off, we advise updating the theme first when you see it in the updates pending list. Check the changelog and check for the new supported versions of apps if there are any, and then you can update your other themeable apps if those versions are now supported by the update, if you want them themed of course.

Asked about this issue on Swift Themes official Telegram and got from an admin that

yes, the crash would happen because the overlay was made for Firefox v67, but users would update to v68 before it was supported by the theme/would update the browser and not update the overlay. this is fixed in the current iteration of the themes now as long as the overlay was properly updated

And indeed the crashes seem to disappear now based on users updating the overlays for Firefox 68.

Flags: needinfo?(petru.lingurar)

OK, glad to see this going down now as themes are updated. FWIW, I think it's perfectly fine to close this bug once we've confirmed that's happening, I just don't want to see us close this out before we've exhausted our options for trying to get a resolution, even if it's not from our end.

Hopefully minor updates, i.e. 68.0->68.1, don't have the same issue and this was a one-off bump. For now, calling this fixed via upstream changes.

Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Whiteboard: [fennec68.1]

Hi, there are still some crashes with ID: java.lang.IllegalStateException: at android.support.v7.app.AppCompatDelegateImpl.createSubDecor(AppCompatDelegateImpl.java) for RC version here
I wanted to verify the issue but theme "Swift Dark Substratum" must be payed.

You need to log in before you can comment on or make changes to this bug.