Closed Bug 1105560 Opened 9 years ago Closed 9 years ago

Autophone - webappstartup Throbber stop regression 2014-11-24

Categories

(Firefox for Android Graveyard :: Web Apps (PWAs), defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox36 fixed, firefox37 fixed, fennec36+)

RESOLVED FIXED
Firefox 37
Tracking Status
firefox36 --- fixed
firefox37 --- fixed
fennec 36+ ---

People

(Reporter: bc, Assigned: amac)

References

Details

(Keywords: regression)

Attachments

(2 files)

mozilla inbound began having problems with Autophone Webappstartup Test on 2014-11-24:

http://phonedash.mozilla.org/#/org.mozilla.fennec/throbberstart/webappstartup/norejected/2014-11-23/2014-11-24/notcached/noerrorbars/standarderror

If you do not include the rejected results, you will see no data after the 2014-11-23 23:40:06 build.

If you do include the rejected results, you will see there is data but instead of data for 8 iterations there is only data for one iteration. The issue is that the WEBAPP STARTUP COMPLETE is seen during the first iteration, but not on the second through eighth. Each iteration consists of starting the app, analyzing logcat, then killing the app via the shell command kill.

This wasn't flagged as an error through treeherder or email notification since there was at least one data point measured. Autophone will need to be fixed to note an error in situations such as this.

I have not yet gotten reproducible manual steps. I'll update the bug when I have figured out how to reproduce this.

The web app is available at https://github.com/mozilla/autophone/blob/master/tests/webapp-startup-test.apk

You can run the web app via:

adb shell 'am start  -n com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a
542101851c47a670b9c8c/org.mozilla.android.synthapk.LauncherActivity -a android.intent.action.MAIN --es env0 MOZ_CRASHREPORTER_NO_REPORT=1'

Note you will have to deal with the line break. I'll attach the command as a text file so you have the full unbroken command line.

The webapp dumps WEBAPP STARTUP COMPLETE to logcat when it finishes loading.

The regression range is:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c9a0d4535544&tochange=4ad7f3e41256

The corresponding build is:

http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-inbound-android/1416817926/

It appears to be related to Bug 1096971. I'll wait until I can reproduce this locally before marking it as the regressor.
Steps to reproduce:

open a different command window and execute:
adb logcat -c; while true; do adb wait-for-device logcat | grep WEBAPP; sleep 5; done

This will display WEBAPP STARTUP COMPLETE each time it is output to logcat.

Then

adb install fennec-36.0a1.en-US.android-arm.apk 

adb install webapp-startup-test.apk

adb shell am start  -n com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a542101851c47a670b9c8c/org.mozilla.android.synthapk.LauncherActivity -a android.intent.action.MAIN --es env0 MOZ_CRASHREPORTER_NO_REPORT=1

# displays WEBAPP STARTUP COMPLETE

# get pid from running fennec/webapp processes
adb shell ps | grep mozilla

adb shell 'LD_LIBRARY_PATH=/vendor/lib:/system/lib kill -9 <enter the pids here>'

adb shell am start  -n com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a542101851c47a670b9c8c/org.mozilla.android.synthapk.LauncherActivity -a android.intent.action.MAIN --es env0 MOZ_CRASHREPORTER_NO_REPORT=1

# displays WEBAPP STARTUP COMPLETE

adb uninstall com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a542101851c47a670b9c8c

adb install /mozilla/projects/autophone/src/autophone/tests/webapp-startup-test.apk

adb shell am start  -n com.firefox.cli.apk.webappstartupperformancetestbclary.pc91282b8e6a542101851c47a670b9c8c/org.mozilla.android.synthapk.LauncherActivity -a android.intent.action.MAIN --es env0 MOZ_CRASHREPORTER_NO_REPORT=1

# *Does not* display WEBAPP STARTUP COMPLETE

To get this to work after Bug 1096971, I have to uninstall the webapp, then uninstall fennec, then install fennec, then install the webapp. Is this new behavior intended or is it a regression?

FYI, I am going to reduce the number of iterations for the webappstartup test to 1 until this bugs is fixed/resolved so that it is not wasting time attempting to get 8 iterations.
Blocks: 1096971
Flags: needinfo?(snorp)
Flags: needinfo?(amac.bug)
(In reply to Bob Clary [:bc:] from comment #1)
> To get this to work after Bug 1096971, I have to uninstall the webapp, then
> uninstall fennec, then install fennec, then install the webapp. Is this new
> behavior intended or is it a regression?

No, it's not intended. I don't understand how or why Bug 1096971 should affect this. That bug adds two small fixes... one that should only affect you if you were updating an app, and the other that should only affect you when the installation fires a non fatal error. From your STR, you should not even be passing through that code!

I'm going to try and find an Android phone to test this (although the last time I tried compiling Fennec it didn't went that well :) ) 

> 
> FYI, I am going to reduce the number of iterations for the webappstartup
> test to 1 until this bugs is fixed/resolved so that it is not wasting time
> attempting to get 8 iterations.
Flags: needinfo?(amac.bug)
Assignee: nobody → amac.bug
Ok, turns out that code was being hit because
adb uninstall whateverpackage 

doesn't really uninstall the webapp. For all practical extents, Gecko stills thinks that the app is installed. So the next time it's installed/launched the webapps manager does an 'autoupdate' (which doesn't really do anything).

And to keep a long story short, bug 1096971 changed the exception type for PACKAGE_UNCHANGED to be a text instead of an Error (to make it consistent with the rest of the exceptions launch there). And WebappManager doesn't like that. 

I'm trying to make a fennec build using the attached patch, but since the last time it didn't went that well, could you try to test this, Bob?
Attachment #8529645 - Flags: feedback?(bob)
Comment on attachment 8529645 [details] [diff] [review]
V1. Change the captured ex to a text

Ok, I finally managed to find an Android device and to build Fennec. And this fixes the problem, so asking for review :)
Attachment #8529645 - Flags: review?(myk)
Antonio, Can you submit a try build and I can test that. Thanks for so quickly checking on this!
Sorry it took so long. Treeherder didn't update the display and I had to go to the directory directly: http://ftp.mozilla.org/pub/mozilla.org/mobile/try-builds/amac@tid.es-ad64dc8e1891/try-android/

The patch fixes the issue for me. Thanks Antonio!
Flags: needinfo?(snorp)
Attachment #8529645 - Flags: feedback?(bob) → feedback+
Thanks for the quick action, Antonio! Much appreciated.
Comment on attachment 8529645 [details] [diff] [review]
V1. Change the captured ex to a text

(In reply to Mark Finkle (:mfinkle) from comment #8)
> Thanks for the quick action, Antonio! Much appreciated.

Ditto, and sorry for the delayed review!
Attachment #8529645 - Flags: review?(myk) → review+
Antonio, do you think we can get this landed today? I'd like to re-enable the full webappstart test iterations as soon as we can.
Ups, totally forgot about requesting checkin. Requested now :)
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/a064f583dd74
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
I think we need to uplift this to Fx36
tracking-fennec: ? → 36+
Flags: needinfo?(amac.bug)
If bug 1096971 landed on 36, then yeah, it does.
Flags: needinfo?(amac.bug)
(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #15)
> If bug 1096971 landed on 36, then yeah, it does.

looks like it:
Target Milestone: mozilla36

Can you request an approval for aurora?
Comment on attachment 8529645 [details] [diff] [review]
V1. Change the captured ex to a text

Approval Request Comment
[Feature/regressing bug #]: 1105560
[User impact if declined]: On Fennec whenever there's an update for an app that hasn't really changed (which will happen if the app is installed via sideload always, and dunno about the normal removal/uninstall mechanism) the app won't install correctly.
[Describe test coverage new/current, TBPL]: Tested as part of the autophone set
[Risks and why]: Low, the change is just fixing an error check whose type changed
[String/UUID change made/needed]: None
Attachment #8529645 - Flags: approval-mozilla-aurora?
Attachment #8529645 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.