767002 - StrictMode policy violation - StrictModeDiskReadViolation on system installed notification launch

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

I/ActivityManager(  193): Displayed org.mozilla.fennec/.WebApps$WebApp1: +760ms
D/StrictMode( 3625): StrictMode policy violation; ~duration=299 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=31 violation=2
D/StrictMode( 3625): 	at android.os.StrictMode$AndroidBlockGuardPolicy.onReadFromDisk(StrictMode.java:1089)
D/StrictMode( 3625): 	at android.app.SharedPreferencesImpl.awaitLoadedLocked(SharedPreferencesImpl.java:184)
D/StrictMode( 3625): 	at android.app.SharedPreferencesImpl.getBoolean(SharedPreferencesImpl.java:241)
D/StrictMode( 3625): 	at org.mozilla.gecko.ProfileMigrator.isProfileMoved(ProfileMigrator.java:323)
D/StrictMode( 3625): 	at org.mozilla.gecko.GeckoProfile.getDir(GeckoProfile.java:126)
D/StrictMode( 3625): 	at org.mozilla.gecko.GeckoProfile.shouldRestoreSession(GeckoProfile.java:152)
D/StrictMode( 3625): 	at org.mozilla.gecko.GeckoApp.initialize(GeckoApp.java:1773)
D/StrictMode( 3625): 	at org.mozilla.gecko.GeckoApp.onWindowFocusChanged(GeckoApp.java:2154)
D/StrictMode( 3625): 	at com.android.internal.policy.impl.PhoneWindow$DecorView.onWindowFocusChanged(PhoneWindow.java:2366)
D/StrictMode( 3625): 	at android.view.View.dispatchWindowFocusChanged(View.java:5735)
D/StrictMode( 3625): 	at android.view.ViewGroup.dispatchWindowFocusChanged(ViewGroup.java:851)
D/StrictMode( 3625): 	at android.view.ViewRootImpl.handleMessage(ViewRootImpl.java:2557)
D/StrictMode( 3625): 	at android.os.Handler.dispatchMessage(Handler.java:99)
D/StrictMode( 3625): 	at android.os.Looper.loop(Looper.java:137)
D/StrictMode( 3625): 	at android.app.ActivityThread.main(ActivityThread.java:4424)
D/StrictMode( 3625): 	at java.lang.reflect.Method.invokeNative(Native Method)
D/StrictMode( 3625): 	at java.lang.reflect.Method.invoke(Method.java:511)
D/StrictMode( 3625): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:784)
D/StrictMode( 3625): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:551)
D/StrictMode( 3625): 	at dalvik.system.NativeStart.main(Native Method)


--
Nightly (04.21)
Galaxy Nexus (Android 4.0.4)

Comment 1

[Jason Smith [:jsmith]]

Aaron - What's the end-user impact here?

Comment 2

[Aaron Train [:aaronmt]]

Absolutely nothing.

Comment 4

[Jason Smith [:jsmith]]

Marking for re-triage - this apparently appears to be the cause of 1/2 second startup time slowness for web apps. I'd increase the priority here, given that startup time for web apps is a bit slow right now.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We may want to just skip the shouldRestoreSession() check for web apps.

Also note that no matter what, web apps are going to feel slower to startup than Fennec itself -- Fennec has the built-in-native awesomescreen that will come up quickly while Gecko is still launching.  Web apps need all of gecko to launch before they can display anything.

Comment 6

[(dormant account)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #5)
> We may want to just skip the shouldRestoreSession() check for web apps.
> 
> Also note that no matter what, web apps are going to feel slower to startup
> than Fennec itself -- Fennec has the built-in-native awesomescreen that will
> come up quickly while Gecko is still launching.  Web apps need all of gecko
> to launch before they can display anything.

Note we might be able to speed up gecko loading for webapps by loading less gecko via of bug 748488. Depends how similar the useful subset of gecko is between apps.

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Jason Smith [:jsmith] from comment #4)
> Marking for re-triage - this apparently appears to be the cause of 1/2
> second startup time slowness for web apps. I'd increase the priority here,
> given that startup time for web apps is a bit slow right now.

Where are we getting the 1/2 sec data from?

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #5)
> We may want to just skip the shouldRestoreSession() check for web apps.

Maybe, but restoring webapp state is something the WebApp team wants to support. Right now, Fennec does not support restoring much in the way of state, but at some point restoring cookies, session data and form data would be nice for webapps.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Mark Finkle (:mfinkle) from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > Marking for re-triage - this apparently appears to be the cause of 1/2
> > second startup time slowness for web apps. I'd increase the priority here,
> > given that startup time for web apps is a bit slow right now.
> 
> Where are we getting the 1/2 sec data from?

The dup on this bug, bug 777132.

Comment 9

[Chris Peterson [:cpeterson]]

In this bug, the StrictMode warning in logcat above says the main thread is blocked for 299 ms:

  D/StrictMode( 3625): StrictMode policy violation; ~duration=299 ms

In bug 777132, the StrictMode warnings in logcat say the main thread is blocked for about 600 ms on first launch and about 300 ms on subsequent launches. Such as:

  D/StrictMode(10845): StrictMode policy violation; ~duration=108 ms:
  ... 
  D/StrictMode(10845): StrictMode policy violation; ~duration=98 ms: 
  ...
  D/StrictMode(10845): StrictMode policy violation; ~duration=96 ms:

Comment 10

[(dormant account)]

Snappy doesn't concern non-desktop ff atm.

Comment 11

[Wesley Johnston (:wesj)]

Not working on this. Bug 886925 may help though...

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

This specific StrictMode violation is due to profile migration, which is being removed in bug 886587.

WONTFIX'ing here