914412 - [browser] browser is unresponsive when view activity returns

Status: RESOLVED FIXED

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

Description

[David Flanagan [:djf]]

For bug 905856, I've implemented a new app to handle content of the type application/vnd.oma.dd+xml via a View activity.

When the browser starts loading a link with that content type, it correctly invokes my app. That part works fine.

But when the app is done handling the content and uses postResult() or postError() to return to the browser, I often find that the webpage I was on is unresponsive and none of the links on the page respond to my taps.  I have to reload the page before I can use it again.

This happens frequently, at least 50% of the time, but not 100%. It seems to happen more consistently when I return with postResult(), but does not happen always for postError().  Sorry that I don't have better data on that.

When I call postResult(), I just pass an empty object because I'm not sure what I'm supposed to return. View activities don't have return values, right? For my particular use case, I'd love to be able to return a URL and have the browser redirect to that URL, but I'm guessing that is not generally what the content handlers are supposed to do.

Comment 1

[David Flanagan [:djf]]

Note that this is not view activity that other apps use to open the browser. This is the view activity that Gecko uses when it finds a contentType that the browser doesn't know how to handle.

I have not checked to see if this bug reproduces with pdf.js.

To reproduce this bug you can apply the patch from https://github.com/mozilla-b2g/gaia/pull/11914 and then visit http://djf.net/t.html in the browser and click on the first link on that page. Follow the prompts and then when you return to the browser, try tapping the link again.

This blocks bug 887071, which is a must-have feature for 1.2.

Need info on Ben because he knows the browser, and on Fabrice because he knows the view activity content handler stuff. (Fabrice: is gecko expecting any particular value to be passed to postResult()?)

Comment 2

[[:fabrice] Fabrice Desré]

Gecko doesn't expect anything from these view activities: they are really "fire and forget". Your use case for a redirection is not supported (and I think that could be pretty disturbing for the user flow, on top of the implementation issues).

I'll check if I can reproduce though, because that should definitely work.

Comment 3

[David Flanagan [:djf]]

I notice that if I let the screen blank (or tap the sleep button) when the browser is unresponsive and then wake the phone back up again, the browser starts working.

This makes me think that the problem is in the system app with the code that opens and closes the activity pane. I wonder if the fact that the activity is launched by Gecko instead of by an app is confusing the window management code in the system app. On the other hand, though, the title bar of the web browser is still responsive: it seems to just be the content area that is not responding to touch events.  And that makes it seem like a browser issue.  Still, I'm going to set need info on Alive, in case he has ideas about the the activity window management code for activities launched by gecko instead of by an app.

I see this message in the console after the activity exits. I have no idea if it is relevant:

E/GeckoConsole( 7668): Could not read chrome manifest 'file:///system/b2g/chrome.manifest'.

7668 is not the process id of the browser app or of the app being launched by the activity.

Comment 4

[(inactive after 6/18) Alive Kuo [:alive]]

Looking this right now.

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

This looks to me there's a specific overlay is applied on the browser iframe only, and when it gets visibilitychange event it's not removed correctly. I will check if it's page visibility not applied correctly or not.

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

* Not a modal dialog related bug; I marked the alert in lc app and it's still reproducible.
* Calling inline activity 'test' from http://jsfiddle.net/alivedise/ML95T/ works fine. So it's not an inline activity specific issue.
* Screen off -> on does repro this. It's a little strange.

I tend to think it's an OOP issue now, still debugging.

Comment 7

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive] from comment #6)
> * Screen off -> on does repro this. It's a little strange.
s/repro/resolve/

Comment 8

[[:fabrice] Fabrice Desré]

So, when we start the activity, we get the usual:
I/GeckoDump( 6728): XXX FIXME : Got a mozContentEvent: activity-choice 

But, we also get it once again when turning on the screen after unlocking... That's really unexpected.

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fabrice Desré [:fabrice] from comment #8)
> So, when we start the activity, we get the usual:
> I/GeckoDump( 6728): XXX FIXME : Got a mozContentEvent: activity-choice 
> 
> But, we also get it once again when turning on the screen after unlocking...
> That's really unexpected.

I noticed this too but seems not the root cause of this issue..
More investigation:
* While I run http://djf.net/t.html as an app (I replace template app), it works fine.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

The redundant mozContentEvent is https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/list_menu.js#L147 I think. Exactly my bug..

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

I have a patch for this issue now.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: 914412.patch

The focusing of browser subpage is losing because we're focusing the inline activity frame. And since browser app doesn't know 'activity is finished' because activity onsuccess/oncancel is fired to the embedded mozbrowser iframe but not to the browser app itself, the only alternative here is use visibilitychange event to let browser recover the focus/blur to the mozbrowser iframe.

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Exactly...I don't remember the reason the visibility of activity caller is not correctly set. We need unit tests.
But it's really difficult to add any unit test to current window manager now, so that's why I am working on splitting it into tiny modules now.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

OK, I had fixed this long time ago in https://github.com/alivedise/gaia/blob/1679ed57c7ebae7b295635b58a784f21f99a3e42/apps/system/js/window_manager.js#L1102

But somebody removed this line.

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Alive Kuo [:alive] from comment #14)
> OK, I had fixed this long time ago in
> https://github.com/alivedise/gaia/blob/
> 1679ed57c7ebae7b295635b58a784f21f99a3e42/apps/system/js/window_manager.
> js#L1102
> 
> But somebody removed this line.

OK my memory goes bad.. the patch does only exist in my local branch.
The reason is the inline activity opener may be killed by OOM if we do send it to background.
The work in bug 822325 may avoid this.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

Bug 822325 does take time to land. The alternative maybe: set "only" browser app's visibility to false.

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

David, I couldn't access 887071. If it's koi+, please help to nom this bug to koi?.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 802203 [details]
914412.patch

It's sad that we need to make workaround like this :'(

Comment 19

[(inactive after 6/18) Alive Kuo [:alive]]

Note: we will bring side effect: browser tab may be killed by OOM since we send the whole browser app to background. But we don't have another choice right now, an unresponsive UI is not acceptable anyway IMO.

Comment 20

[(inactive after 6/18) Alive Kuo [:alive]]

https://github.com/mozilla-b2g/gaia/commit/8039a58001a6fdc8f703e9fc63e7ea1ea2f339aa