837062 - Threshold for tapping defined on build time

Status: RESOLVED FIXED

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

Description

[Cristian Rodriguez (:crdlc)]

It's a parameter that will heavily depend on the hardware, we should add it as a parameter that manufacturers modify during build time

I mean, we should add this value to the build/applications-data.js file and make it configurable by specific build.

Comment 1

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Comment 2

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 708996 [details]
Patch v1

Tried on the device and working well

NOTE: If blocking-basecamp+ is set, just land it for now.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Feature needed to perform correctly in the developer phones. Moving this parameter to the build phase will allow us to adjust a better experience for the different hardware we have right now.
User impact if declined: If we don't make this configurable per device we can ship builds which homescreen could be potentially unusable
Testing completed: yes
Risk to taking this patch (and alternatives if risky):not very risky as it's moving a constant to the already working configuration by build time

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

This looks like something we'd want some testing around before uplifting.  Can you land to master and then provide build (or builds) for them to test out - put the 'qawanted, verifyme' keywords in when test builds are ready

Comment 4

[Cristian Rodriguez (:crdlc)]

This bug depends on https://bugzilla.mozilla.org/show_bug.cgi?id=829050. It uses some code implemented in 829050 so if it is not uplifted we shouldn't land this one

Comment 5

[Alex Keybl [:akeybl]]

(In reply to crdlc from comment #4)
> This bug depends on https://bugzilla.mozilla.org/show_bug.cgi?id=829050. It
> uses some code implemented in 829050 so if it is not uplifted we shouldn't
> land this one

Can this be separated from bug 829050? That bug appears to have non-zero risk, and has little benefit to 1.0.0 and 1.0.1 users.

Comment 6

[Cristian Rodriguez (:crdlc)]

I prefer wait a couple of days for the final decision before separating code. Or maybe, is the decision taken? If finally the other bug won't go in v1, I prefer remove that from master and this one will implement the common code. So we could do the uplift easier. After that, I could implement the other one based on master implementation provided for this.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

We're still waiting for product input on bug 829050, leaving this in triage for now.

Comment 8

[Peter Dolanjski [:pdol]]

What, exactly, is this threshold adjusting?
If we don't allow it to be adjusted during build time, is there another way for the OEM to adjust it?

Comment 9

[Cristian Rodriguez (:crdlc)]

Changing in JS code

https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/page.js#L517

Comment 10

[Peter Dolanjski [:pdol]]

Given that bug 829050 is blocking, is it safe to assume that this risk is minimal?

Comment 11

[Cristian Rodriguez (:crdlc)]

Here the risk is minimal based on the other bug. It was tested by me and the reviewer

Comment 12

[Cristian Rodriguez (:crdlc)]

https://github.com/mozilla-b2g/gaia/commit/3c070039c0818e8dcab45fb90e8743c52e7d8f3d

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 708996 [details]
Patch v1

Approving based on low risk assessment.

Comment 14

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

This bug is generating a lot of complaints.  Can we get it uplifted?  (Downstreams are working around it with their own patches, which isn't what anyone wants.)

Comment 15

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

v1-train: 0d1ef3c5b9a0a94bf0461c9ce70855f63cb760e7
v1.0.1: 2e646c0fe299e4b7054dac5e0e22058a4d4b23e4

Comment 16

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

(In reply to Chris Jones [:cjones] [:warhammer] from comment #14)
> This bug is generating a lot of complaints.  Can we get it uplifted? 
> (Downstreams are working around it with their own patches, which isn't what
> anyone wants.)

This bug was not showing up in the queries that I was given by release management because the the bug is still ASSIGNED and not RESOLVED/VERFIED->FIXED

Comment 17

[Cristian Rodriguez (:crdlc)]

This bug is not on v1.0.1 and v1-train if I am not wrong

Comment 18

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

Yep, I can confirm that those objects aren't on the branches, not sure how that happened.

Unfortunately, there are merge conflicts when trying to apply the diff to v1-train and v1.0.1 now.

Comment 19

[Cristian Rodriguez (:crdlc)]

Please paste here the commands and I could help you resolving conflicts

Comment 20

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

 git checkout v1-train
 git cherry-pick -x -m1 3c070039c0818e8dcab45fb90e8743c52e7d8f3d
 <RESOLVE MERGE CONFLICTS>
 git commit
 git checkout v1.0.1
 git cherry-pick -x $(git log -n1 v1-train)
 <RESOLVE MERGE CONFLICTS> # If they exist
 git commit

Comment 21

[Cristian Rodriguez (:crdlc)]

OK in v1-train

https://github.com/mozilla-b2g/gaia/commit/95d5b5125a81f14b985fd8b2d919718fb35e8933

Comment 22

[Cristian Rodriguez (:crdlc)]

resolved on v1.0.1

https://github.com/mozilla-b2g/gaia/commit/b83b1064e1578c67639ceb4e4126179721f37034

Comment 23

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

marking branch fixes per comment 21,22