Closed Bug 1591077 Opened 3 years ago Closed 3 years ago

Crash in [@ android.content.res.Resources$NotFoundException: at android.content.res.Resources.getValue(Resources.java)]

Categories

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

Firefox 68
Unspecified
Android
defect

Tracking

(firefox-esr68 fixed)

RESOLVED FIXED
Firefox 68
Tracking Status
firefox-esr68 --- fixed

People

(Reporter: marcia, Assigned: vlad.baicu)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(1 file)

This bug is for crash report bp-30dad622-9445-4c8e-938c-39bf50191024.

Seen while looking at mobile crash stats: https://bit.ly/2pO4UXt. Crash was present in 68 but seems to be increasing in scope in 68.2. APIs range from 15-23. Currently #37 overall on release.

Comments are not useful.

Interesting part of stack might be at org.mozilla.gecko.firstrun.SendTabPanel.onCreateView(SendTabPanel.java:36)

Java stack trace:

android.content.res.Resources$NotFoundException
	at android.content.res.Resources.getValue(Resources.java:1884)
	at android.content.res.Resources.getDrawable(Resources.java:1521)
	at org.mozilla.gecko.firstrun.SendTabPanel.onCreateView(SendTabPanel.java:36)
	at android.support.v4.app.Fragment.performCreateView(Fragment.java:2439)
	at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1460)
	at android.support.v4.app.FragmentManagerImpl.moveFragmentToExpectedState(FragmentManager.java:1784)
	at android.support.v4.app.FragmentManagerImpl.moveToState(FragmentManager.java:1852)
	at android.support.v4.app.BackStackRecord.executeOps(BackStackRecord.java:802)
	at android.support.v4.app.FragmentManagerImpl.executeOps(FragmentManager.java:2625)
	at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2411)
	at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2366)
	at android.support.v4.app.FragmentManagerImpl.execSingleAction(FragmentManager.java:2243)
	at android.support.v4.app.BackStackRecord.commitNowAllowingStateLoss(BackStackRecord.java:654)
	at android.support.v4.app.FragmentPagerAdapter.finishUpdate(FragmentPagerAdapter.java:146)
	at android.support.v4.view.ViewPager.populate(ViewPager.java:1244)
	at android.support.v4.view.ViewPager.setCurrentItemInternal(ViewPager.java:669)
	at android.support.v4.view.ViewPager.setCurrentItemInternal(ViewPager.java:631)
	at android.support.v4.view.ViewPager.setCurrentItem(ViewPager.java:612)
	at com.booking.rtlviewpager.RtlViewPager.setCurrentItem(RtlViewPager.java:94)
	at org.mozilla.gecko.firstrun.FirstrunPager$1.next(FirstrunPager.java:77)
	at org.mozilla.gecko.firstrun.FirstrunPanel.next(FirstrunPanel.java:94)
	at org.mozilla.gecko.firstrun.FirstrunPanel.lambda$onCreateView$0$FirstrunPanel(FirstrunPanel.java:64)
	at org.mozilla.gecko.firstrun.FirstrunPanel$$Lambda$0.onClick(Unknown Source)
	at android.view.View.performClick(View.java:4191)
	at android.view.View$PerformClick.run(View.java:17229)
	at android.os.Handler.handleCallback(Handler.java:615)
	at android.os.Handler.dispatchMessage(Handler.java:92)
	at android.os.Looper.loop(Looper.java:137)
	at android.app.ActivityThread.main(ActivityThread.java:4960)
	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:1038)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:805)
	at dalvik.system.NativeStart.main(Native Method)
Priority: -- → P1

The crash ratio is pretty low. But let's take a peek at this anyway ... seems related to an image we need for firstrun?

((ImageView) root.findViewById(R.id.firstrun_image)).setImageDrawable(getResources().getDrawable(image));

Flags: needinfo?(vlad.baicu)
Assignee: nobody → vlad.baicu
Flags: needinfo?(vlad.baicu)

I haven't been able to reproduce but I can speculate based on my code investigation. Since we've been told that there aren't any leanplum config variables for the onboarding panels on release, this is most likely a bug within the OnboardingResources helper class (for which we should file a new bug and drop it completely as soon as we have everything localized - it adds unnecesary complexity, redundant in most cases and makes everything a lot more error prone) which causes the default resources for the send tab panel to not be initialized properly.

Speculative fix, make sure that send tab resources are always initialized, regardless of the localization status.

Comment on attachment 9108078 [details]
Bug 1591077 - Make sure send tab resources are always initialised.r=AndreiLazar

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: Speculative fix for onboarding crash
  • User impact if declined: Users will continue to experience crashes
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Moved the initialisation of some resources
  • String or UUID changes made by this patch:
Attachment #9108078 - Flags: approval-mozilla-esr68?

Comment on attachment 9108078 [details]
Bug 1591077 - Make sure send tab resources are always initialised.r=AndreiLazar

Crash fix, let's uplift for the next fennec build.

Attachment #9108078 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.