Closed Bug 889188 Opened 7 years ago Closed 7 years ago

[Homescreen] Drop the touch event when some apps are running in the backgroud

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 verified, b2g-v1.1hd fixed)

RESOLVED FIXED
1.1 QE4 (15jul)
blocking-b2g leo+
Tracking Status
b2g18 --- verified
b2g-v1.1hd --- fixed

People

(Reporter: leo.bugzilla.gaia, Assigned: alive)

Details

(Whiteboard: [LeoVB+])

Attachments

(1 file)

1. Title : Drop the touch event when some apps are running in the backgroud

2. Precondition : Connect the wifi or data

3. Tester's Action : Launch Home Screen -> Launch the facebook app or Youtube app -> go to homescreen -> Drag homescreen 

4. Detailed Symptom (ENG.) : When user drag the homescreen, sometime doesn't move.

5. Version 
GAIA : f2d6ed54a236e6e3b94f0abad9f0dacb8a1cc7b3
GECKO : be276cf55ce160bca09f36d9ca679a2ae20ea7cc

6.Personal email id:  jjoons79@gmail.com
Attached video Attach a video
Hi,

   I need more details and the complete sequence of STR, I mean: 

* Do you open the app and close it immediately? 

* Do you think that the wifi or data is relevant to reproduce it? 

* In which branch is it reproducible? master and v1-train? both?

* If you open the task switcher and close it, is the drag functionality recover?

Thanks
Flags: needinfo?(leo.bugzilla.gaia)
Do you open the app and close it immediately? 
-> Yes. Open the facebook app and push the home button immediately to go to homescreen. 

* Do you think that the wifi or data is relevant to reproduce it? 
-> When 2G data is connected, it is reproduced better than wifi. 

* In which branch is it reproducible? master and v1-train? both?
-> It is reproduced in the latest v1-train (0d5a9a7577f16b6a72a982148c6f509ee1714ea2)
   I didn't test the master. 

* If you open the task switcher and close it, is the drag functionality recover?
-> Yes. When the facebook is closed, the drag works fine.
Flags: needinfo?(leo.bugzilla.gaia)
If you open some app with network activity like Facebook downloaded from the market and close it immediately, most of the times the touch events are not propagated to homescreen app (ONLY in the middle of the screen, if you touch on corners, panning works fine). IMHO the problem is in other part of Gaia or Gecko because the home does not receive the event under those conditions. I can reproduce it on v1-train and Unagi. Comment 3 for further information.

Maybe in system app?? When apps are closed AFAIK they are scaled to 0.6 (I don't remember the factor of scale very well and it seems to be the area not touchable on the home)

My test:

diff --git a/apps/homescreen/js/grid.js b/apps/homescreen/js/grid.js
index 667d885..0b6bd56 100644
--- a/apps/homescreen/js/grid.js
+++ b/apps/homescreen/js/grid.js
@@ -155,6 +155,7 @@ var GridManager = (function() {
   function handleEvent(evt) {
     switch (evt.type) {
       case touchstart:
+        console.log('TOUCHSTART!!')
         if (currentPage || numberOfSpecialPages === 1)
           evt.stopPropagation();
         touchStartTimestamp = evt.timeStamp;
Component: Gaia::Homescreen → Gaia::System
In this case when home key is pressed again, it works fine.
Flags: needinfo?(alive)
Flags: needinfo?(wchang)
I reproduced with latest v1-train just by:
(1) Open settings, turn on wifi and choose an AP
(2) Press home button to homescreen.

Actual:
* Cannot touch homescreen in center area.

I'm afraid this is https://bugzilla.mozilla.org/show_bug.cgi?id=876676
Flags: needinfo?(alive)
Assignee: nobody → alive
But it looks like cannot be reproduced every time ;/
Need more accurate STR.
Keywords: qawanted
Flags: needinfo?(leo.bugzilla.gaia)
(In reply to Alive Kuo [:alive] from comment #7)
> But it looks like cannot be reproduced every time ;/
> Need more accurate STR.

For me, the STR does reproduce the bug on a leo partner build, but not consistently. Then again, it doesn't take much to reproduce this - I was able to reproduce this with the STR after two tries.
Flags: needinfo?(leo.bugzilla.gaia)
Keywords: qawanted
Note - doing more testing on this, this definitely appears to be really easy to reproduce on the leo partner build, but not on unagi. Could this potentially be a POVB issue on leo's end?
Seems to be duplicate of bug 887608 ([homescreen] homescreen becomes non responsive when Poppit app is launched and put in background).

Maybe bug 887127 ([Homescreen] flicking event drop on homescreen and everything.me) is also related to them.
The first thing come to my mind is that leo build has some code difference than ours.
I say -- if this is a gaia bug -- maybe in system/window manager.

I know that leo did some patch only in their build.
I already checked the pure latest v1-train that don't merged leo's patch. Same issue is reproduced. But the latest gaia master is not reproduced.
By git bisect, it is possible to check that this issue was first introduced in v1-train by https://github.com/mozilla-b2g/gaia/commit/5e94419dd97344922e202cdebd03dc4570949c1c
(bug 842627).

I tried to simply revert this commit in our latest version, but then the device freezes after the operator's power on animation.
Yes, bug 842627 is root cause of bug 876676.
I fixed bug 876676 on v1.0.1(in confidential bug 872912) but we don't have a stable STR to reproduce on v1-train.

Briefly to say, the root cause is the window failed to be closed but stay by scale(0.6) on center of the screen. Though its visibility or z-index is not updated correctly.

I will try to figure out how to deal with this on v1-train. A mess...
Hi leo,
Could you try to cherry pick this patch to see if it's still reproducible ?

https://github.com/mozilla-b2g/gaia/pull/10032
Flags: needinfo?(leo.bugzilla.gaia)
Flags: needinfo?(andre.graziani)
After merging the patch of "https://github.com/mozilla-b2g/gaia/pull/10032", leo works fine. Let's discuss it in Taipei.
Flags: needinfo?(leo.bugzilla.gaia)
I would propose to pick the workaround since the root cause is hidden in a messup in window manager and there're big difference between master and v1-train.

(In reply to Leo from comment #16)
> After merging the patch of "https://github.com/mozilla-b2g/gaia/pull/10032",
> leo works fine. Let's discuss it in Taipei.

Uh, a new work week?
It works for me also.
Thanks Alive.
Flags: needinfo?(andre.graziani)
Talked w/ leo and decide to cherry pick the v1.0.1 patch to v1-train.

https://github.com/mozilla-b2g/gaia/commit/7cdcc46179d198cab11970964b181ede32a5b683
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Varified fix on leo 1.1 Mozilla RIL
Environmental Variables
Build ID: 20130716070204
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/629020cf576b
Gaia: fb9362d34260771d4a00b9a0e10a6bbad397bd3b
Platform Version: 18.1
RIL Version: 01.01.00.019.138 

The user can drag homescreen smoothly.
Whiteboard: [LeoVB+]
v1.1.0hd: 7cdcc46179d198cab11970964b181ede32a5b683
v1.1.0hd: ecaea98f28bd834663c2d321fb42a0bedbac557e
Flags: needinfo?(wchang)
You need to log in before you can comment on or make changes to this bug.