936028 - [Single Variant] Hosted with cache apps shows a loading icon if are installed without internet connection

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[rafael.marquez]

Attachment: cargando.png

****Steps
1. Installing a v1.2 build on device
2. Clone the tests repository for sigle variant: https://github.com/telefonicaid/firefoxos-gaia-testsbuild.git
3. Configuring the file variant.json
4. Clone Gaia repository and select the v1.2 branch.
5. Executing the command "GAIA_DISTRIBUTION_DIR="URL"/firefoxos-gaia-testsbuild  PRODUCTION=1 make reset-gaia" to install gaia with single variant in the device
6.Complete the FTE  with a movistar SIM (in this case the configured in the file .json)without internet connection

***Expected Result
Hosted with cache apps are instaled correctly

***Actual Result
Hosted with cache apps shows a loading icon if are installed without internet connection
In the attached screenshot you can see the apps: Wikipedia and Accuweather who are hosted with cache apps 

Device Unagi
Branch 1.2
Gecko 1303dc0
Gaia 2140c98

Comment 1

[Antonio Manuel Amaya Calvo (:amac)]

I think this is actually the expected behavior. At least there's code to cause exactly this behavior. And it does make sense, since I don't think we're including the cached content with the app on the build (BTW, we used to do that and wikipedia breaks the build that way, once the directory is created on the device trying to erase it gets the device on a funny state where the partition goes back to RO and cannot get out of that state).

Comment 2

[Jason Smith [:jsmith]]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #1)
> I think this is actually the expected behavior. At least there's code to
> cause exactly this behavior. And it does make sense, since I don't think
> we're including the cached content with the app on the build (BTW, we used
> to do that and wikipedia breaks the build that way, once the directory is
> created on the device trying to erase it gets the device on a funny state
> where the partition goes back to RO and cannot get out of that state).

This is a firm content management requirement to allow preloading without a network. There isn't any room for negotiation on this one. The workflow preloading should be doing is:

1. During build time, all app related resources should preloaded into the build
2. When the SIM is known, the relevant apps should be installed into the homescreen & other apps should be deleted

There are branding requirements that require that the app be preinstalled with the right icon when no network is present. This has been a requirement since 1.01.

I think at this point I think there's confusion on what the content management requirements, which leads to believe that we need to setup a call with Karen Ward and discuss the current implementation to understand what's acceptable vs. not.

Comment 3

[Carmen Jimenez Cabezas]

I have been doing some testing and I have a proposal for v1.2 which fixes the observable problem and is low risk:
* At build time remove the appcache_path attribute from the manifest of the single variant apps.

This will cause that when the app is installed at run time the installation ends successfully and the icon is show correctly (but grey because there is not network)

* If the user try to start the application without network he will be said that he need network for the app to work.
* The first time the user start the app with network the manifest will be updated silently and the cache will be populated

Comment 4

[Albert [:albert]]

Attachment: Patch

Patch implementing fix from comment 3

Comment 5

[Jason Smith [:jsmith]]

(In reply to Carmen Jimenez Cabezas from comment #3)
> I have been doing some testing and I have a proposal for v1.2 which fixes
> the observable problem and is low risk:
> * At build time remove the appcache_path attribute from the manifest of the
> single variant apps.
> 
> This will cause that when the app is installed at run time the installation
> ends successfully and the icon is show correctly (but grey because there is
> not network)
> 
> * If the user try to start the application without network he will be said
> that he need network for the app to work.
> * The first time the user start the app with network the manifest will be
> updated silently and the cache will be populated

We really need to discuss these type of decisions with product & content management first before proposing a change here. I'm still concerned here that the implementation here isn't reflecting target content management requirements that we have to follow to ship the product.

Comment 6

[Carmen Jimenez Cabezas]

We have actually contrasted this option with our product people, which are the ones that know our own operator requisites. I don't know of any written requisites for this, but if you're so kind as to link them here, I can check to see if we fulfill them or how can we do it.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Carmen Jimenez Cabezas from comment #6)
> We have actually contrasted this option with our product people, which are
> the ones that know our own operator requisites. I don't know of any written
> requisites for this, but if you're so kind as to link them here, I can check
> to see if we fulfill them or how can we do it.

I forwarded you the email that summarized the specific areas of concern that QA is questioning in relation to content management. As for the written requisites - I'll need dig around to find the documentation.

Comment 8

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 829232 [details]
Patch

cancel review because we don't have conclusion for now.

Comment 9

[Antonio Manuel Amaya Calvo (:amac)]

Jorge, Marce, can you give a product point of view here?

Comment 10

[Marcelino Veiga Tuimil [:sonmarce]]

The solution is OK for us, as it installs hosted apps correctly, just postponing downloading of cached contents until there is Internet connection. This is not an issue as apps like Wikipedia and Accuweather also need Internet connection to work even in case apps are already cached.

I propose to land this bug as is, because it fixes the bug, and in parallel Mozilla and Telefonica product people to clarify any concern from product perspective.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Marcelino Veiga Tuimil [:sonmarce] from comment #10)
> The solution is OK for us, as it installs hosted apps correctly, just
> postponing downloading of cached contents until there is Internet
> connection. This is not an issue as apps like Wikipedia and Accuweather also
> need Internet connection to work even in case apps are already cached.

No that's not right. Wikipedia is an app that can operate purely offline if it's cached correctly. Accuweather on the other hand just reports back that "you need to be online to use the app." Although to my understanding from past content conversations, this was a requirement to have app-specific errors, not generic error handling.

> 
> I propose to land this bug as is, because it fixes the bug, and in parallel
> Mozilla and Telefonica product people to clarify any concern from product
> perspective.

I need specific clarification from the content team here. I'm not convinced that the content team is going to be alright with the proposed direction here.

Comment 12

[Karen Ward [:kward]]

Content team is expecting the same end user experience as if the build is not using the single variant option.   Therefore this needs to be fixed and I am marking as koi+ and requesting comment from Fabrice.

Comment 14

[Albert [:albert]]

After the discussion in the sprint planning of systems front-end, seems that solution proposed in comment 3 is ok.

Comment 15

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 829232 [details]
Patch

Albert, seems we don't remove it twice, could you remove line 101-105 if unnecessary? and current way looks like a workaround, we should file a follow-up bug to fully fix it. r=yurenju

Comment 16

[Preeti Raghunath(:Preeti)]

Minus, unclear why this bug needs to be a blocker. Please re-nom with a strong case

Comment 17

[Jason Smith [:jsmith]]

(In reply to Preeti Raghunath(:Preeti) from comment #16)
> Minus, unclear why this bug needs to be a blocker. Please re-nom with a
> strong case

Please read comment 12. This is a contractual requirement by our content providers.

Comment 18

[Kai-Chih Hu [:khu]]

koi+ is for 1.2. We should use 1.2 target milestone rather than 1.3 target milestone.

Comment 19

[Albert [:albert]]

(In reply to Yuren Ju [:yurenju] from comment #15)
> Comment on attachment 829232 [details]
> Patch
> 
> Albert, seems we don't remove it twice, could you remove line 101-105 if
> unnecessary? and current way looks like a workaround, we should file a
> follow-up bug to fully fix it. r=yurenju

lines 101-105 are necessary to remove cache from json when the application is first time downloaded. Lines 170-182 will remove cache from json when the manifest is downloaded to check if it has changed, so comparing the downloaded with the local copy.

Comment 20

[Albert [:albert]]

Is it ok?

Comment 21

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

makes sense!

Comment 22

[Albert [:albert]]

Master: https://github.com/mozilla-b2g/gaia/commit/82bc08983e78b4181f8c6297d01349873db30c79

Comment 23

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 82bc08983e78b4181f8c6297d01349873db30c79
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 24

[Albert [:albert]]

Merged in v1.2

https://github.com/mozilla-b2g/gaia/commit/0428cc600b6566fae53f9b6cc72b0f417078b5b7

Comment 25

[rafael.marquez]

Verified with:

Device Unagi
Branch 1.2
Gecko 5fec309
Gaia 6e66cb7