Closed Bug 914412 Opened 6 years ago Closed 6 years ago
[browser] browser is unresponsive when view activity returns
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.
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()?)
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.
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.
Looking this right now.
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.
* 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.
(In reply to Alive Kuo [:alive] from comment #6) > * Screen off -> on does repro this. It's a little strange. s/repro/resolve/
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.
(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.
The redundant mozContentEvent is https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/list_menu.js#L147 I think. Exactly my bug..
I have a patch for this issue now.
Assignee: nobody → alive
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.
Attachment #802203 - Flags: review?(timdream)
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.
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.
(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.
Bug 822325 does take time to land. The alternative maybe: set "only" browser app's visibility to false.
David, I couldn't access 887071. If it's koi+, please help to nom this bug to koi?.
Flags: needinfo?(bfrancis) → needinfo?(dflanagan)
Component: Gaia::Browser → Gaia::System
Comment on attachment 802203 [details] 914412.patch It's sad that we need to make workaround like this :'(
Attachment #802203 - Flags: review?(timdream) → review+
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.