Closed Bug 961591 Opened 10 years ago Closed 10 years ago

Focus is on the last opened app when returning to the home screen

Categories

(Core :: DOM: Core & HTML, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
blocking-b2g 1.4+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- affected

People

(Reporter: cyu, Assigned: alive)

References

Details

(Keywords: regression)

This is found on m-c. STR:
- Open some app.
- While the app is still loading, press the home button to return to the homescreen. 

Repeat the above steps several times. If the problem is reproduced, you will see that the homescreen has no response to touch events.
IPC log shows that the touch events is sent to the last opened app.
Assignee: nobody → alive
blocking-b2g: --- → 1.4?
QA Wanted to check if this happens on 1.3.
Keywords: qawanted, regression
Also - is this potentially a dupe of bug 960516?
I tend to think it's not dupe.
I don't think it is a dupe. The root cause of bug 960516 is the deadlock of the Nuwa process (a gecko bug), while this bug points to the gaia system app.
Maybe we should modify summary of bug 960516 to 'App is not loading while XXXXXX' or 'Process creation is pending XXXXXX' to avoid confusion.
QA Contact: pbylenga
I'm unable to reproduce this issue on today's nightly Buri v1.3 build or on today's nightly Buri v1.4 build.

Environmental Variables
Device: Buri v1.4 Mozilla RIL
Build ID: 20140121040201
Gecko: http://hg.mozilla.org/mozilla-central/rev/cdc0ab2c0cba
Gaia: e218d17ae7d01a81d48f833cd6fafb4e11b26cd8
Platform Version: 29.0a1
Firmware Version: v1.2-device

Environmental Variables
Device: Buri v1.3 Mozilla RIL
Build ID: 20140121004137
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/6f7dfe36ab6c
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Platform Version: 28.0a2
Firmware Version: v1.2-device
We need better STR here - we can't reproduce this in house.

Can you double check the STR?
blocking-b2g: 1.4? → ---
Flags: needinfo?(cyu)
Sorry I forgot to mention that the problem is reproduce with Nuwa template process enabled on m-c. I tried to reproduce using vanilla m-c build but in vain. I tend not to think this is a dupe of bug 960516 because the problem is tracked down to system app failing to set the focus to the homescreen on returning from a launching app.

The STR is just as in the description. The key point is that we need to launch an app and then return to home while the app is loading. Without Nuwa maybe app launching is slower when there is not preallocated app process so the bug is not reproduced. The root cause might be Nuwa or the system app, we'll investigate deeper and renom if we can reproduce it more easily.
Flags: needinfo?(cyu)
In that case, this is a regression that will be present when bug 950266 lands.
blocking-b2g: --- → 1.3?
Depends on: 950266
I tried to reproduce this today using vanilla m-c and saw a problem that might be of the same root cause. The problem is that I cannot go back from the video app to the homescreen. I guess having several apps launching in background, which consumes lots of CPU cycles, triggers some timing issue. I will check if this is on 1.3 w/wo Nuwa.
blocking-b2g: 1.3? → 1.3+
Summary: Focus is on the last opened app when returning to the homescreen → [nuwa] Focus is on the last opened app when returning to the homescreen
(In reply to Cervantes Yu from comment #10)
> I tried to reproduce this today using vanilla m-c and saw a problem that
> might be of the same root cause. The problem is that I cannot go back from
> the video app to the homescreen. I guess having several apps launching in
> background, which consumes lots of CPU cycles, triggers some timing issue. I
> will check if this is on 1.3 w/wo Nuwa.

Based on this comment I wonder this bug is really 1.3+ ?
(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #11)
> (In reply to Cervantes Yu from comment #10)
> > I tried to reproduce this today using vanilla m-c and saw a problem that
> > might be of the same root cause. The problem is that I cannot go back from
> > the video app to the homescreen. I guess having several apps launching in
> > background, which consumes lots of CPU cycles, triggers some timing issue. I
> > will check if this is on 1.3 w/wo Nuwa.
> 
> Based on this comment I wonder this bug is really 1.3+ ?

Note - the severity of the bug is still pretty bad here.

Let's wait to find out from Cervantes if this reproduces without Nuwa.
I can't reproduce this problem w/o Nuwa on 1.3. I'll check if this happens with Nuwa.
I didn't see this bug on 1.3 with Nuwa. I think we can unblock 1.3.
Switching flags based on comment 13 and comment 14.

(In reply to Cervantes Yu from comment #0)
> This is found on m-c. STR:
> - Open some app.
> - While the app is still loading, press the home button to return to the
> homescreen. 
> 
> Repeat the above steps several times. If the problem is reproduced, you will
> see that the homescreen has no response to touch events.
> IPC log shows that the touch events is sent to the last opened app.

Is this really a regression on Gaia Window Management? I don't think it is responsibility for managing touch events. We should be looking at platform.
blocking-b2g: 1.3+ → 1.4?
Summary: [nuwa] Focus is on the last opened app when returning to the homescreen → Focus is on the last opened app when returning to the home screen
Component: Gaia::System::Window Mgmt → General
Andrew,

Please review from DOM perspective
Component: General → DOM
Flags: needinfo?(overholt)
Product: Firefox OS → Core
First I thought this might be a bug with http://mxr.mozilla.org/mozilla-central/source/widget/gonk/nsWindow.cpp?rev=2a082f03cd1d&mark=258-259#258 and how TabParent holds the sEventCapturer
http://mxr.mozilla.org/mozilla-central/source/dom/ipc/TabParent.cpp?rev=9f52cf83ac72&mark=855-858#839
But since touchstart should reset sEventCapturer, I doubt that is the issue.


Another option is that something somewhere ends up setting capturing content, and not release it.
calling document.releaseCapture() in the chrome code (shell.js ?) might help.
Cervantes, want to debug this a bit? You seem to be able reproduce this.
And I'd assume changes to window management could have caused this kind of capturing content issue.
Flags: needinfo?(cyu)
Flags: needinfo?(overholt)
I am on Nuwa this week and will come back to debug next week.
Flags: needinfo?(cyu)
blocking-b2g: 1.4? → 1.4+
I can't reproduce the original problem using the latest trunk:
gecko (hg): 7010ab83a06e
gaia (git): c6d6c106494745b54d562434936689419b4c5996
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.