STR (1) Run FTU (2) Configure wifi network The experience goes to crap. The UI can stop responding for seconds at a time. Filing this separately from bug 813765 because I suspect this is going to start being a common complaint. The underlying cause is that configuring a wifi network takes the device online, which initiates an update poll that FTU's force-update-check queues. We only get one chance to make a first impression, and if a user configures a network ours will be "barely usable junk". Putting it mildly.

Triage: Reluctant to block on this until we can see the experience following the fix to bug 813765.

(In reply to Dylan Oliver [:doliver] from comment #1) > Triage: Reluctant to block on this until we can see the experience following > the fix to bug 813765. I disagree with this. We may not be able to fix bug 813765. In that unfortunate eventuality, I think this bug should be bb+ on its own for FTU-specific workarounds. I really can't emphasize enough how ridiculously bad it is right now :(.

BB+, P2 - severe usability issue

So, if this is really dependant on update polls as said before, and we are not sure we will be able to fix it on time, my workaround proposal on this specific bug is to disable the update process during the ftu, if possible. We could enable it after finishing it (or skipping it)

I agree, and probably even then only off a user-idle timer.

During the Taipei triage today, Thinker will provide some comments in bug 813765.

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Is there any updates on this? cause I've been trying today before applying my patch (just turning off gaia.system.checkForUpdates flag on settings when entering ftu), and didn't noticed any change on performance on my tests (no SIM inserted, just connecting to wifi).

Bug 809947 made us do a lot less disk I/O for update checks. This definitely improves performance a lot. Actual updates still involve writing lots of cache metadata to disk (which happens synchronously on the main thread, unfortunately). There is a WIP by Thinker (bug 771420) to avoid those as much as possible, but it's bitrotted and not a patch Honza would like to take. It's unlikely we can do anything right now at the appcache level code (see discussion in bug 813765).

Fernando, if your patch is ready, I'd say this is still something nice to have; it makes sense to me to not check updates before FTU is finished anyway.

assigning to fcampo as he's already begun some work on this.

Yup, sorry for delay, I'll upload the patch asap.

Patch is simple, only set the update flag to false, and it gets enabled again after FTU with code on bootstrap. But I still feel no improve on performance with this, so I wouldn't say it's fixed entirely with this, I think is more a gecko thing.

I'm backing out the patch, as the settings app already default the value to false, so as Etienne points out in https://github.com/mozilla-b2g/gaia/pull/7069#issuecomment-11496834, the workaround only fixes not updated dogfooding phones (which I guess should be updated eventually). Still think this has to be fixed on lower level

Since the update flag is configured as false already, and it looks like we cannot reproduce this issue anymore, should we close this issue?

can't reproduce it either.

(In reply to Julien Wajsberg [:julienw] from comment #16) > can't reproduce it either. Tried this yesterday and couldn't reproduce either with a wifi network requiring a password. Resolving as a worksforme.