Closed Bug 991547 Opened 6 years ago Closed 6 years ago

[tarako] browser unable to load a website from top sites/history after being the browser gets killed.

Categories

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

x86
macOS
defect
Not set

Tracking

(blocking-b2g:1.3T+, b2g-v1.3T verified)

VERIFIED FIXED
1.4 S6 (25apr)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- verified

People

(Reporter: angelc04, Assigned: daleharvey)

References

Details

(Whiteboard: 1.3tarakorun2, [systemsfe][sprd296178] [partner-blocker])

Attachments

(3 files)

Attached file adb logcat
Steps to reproduce
------------------------------------------------------------------------
1. Launch Browser
2. Browse some website, wait until the webpage is fully loaded.
3. Kill Browser
4. Launch Browser again
5. Go to Topsites/History and select the same website
   --> An error msg " We tried to display this web page, but it's not responding." appears. User need to tap on "Reload" to load the web page.

Note: This issue not only can be reproduced by above steps. Sometimes even accessing a new website can get this reproduced.

Attached is the adb log. test time: 04-03 08:26:04.020

Build info
-------------------------------------------------------------------
Gaia      c418ec10d1e1d53c6757ad12b2320c204808d251
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/36b1279ef6df
BuildID   20140402164000
Version   28.1
ro.build.version.incremental=eng.cltbld.20140402.202437
ro.build.date=Wed Apr  2 20:24:44 EDT 2014
Summary: [tarako] "unable to load " → [tarako] browser sometimes unable to load a website
blocking-b2g: --- → 1.3T?
how easy is it to reproduce it? and can the symptom be recovered after user reloads the page? thanks
Flags: needinfo?(pcheng)
Hi! Peipei,

Could you provide the web side you tested with?
Thanks

--
Keven
@Joe, The reproduce rate is almost 100%. I also this error page everytime I followed the STR. If user click "Reload", webpage can be refreshed correctly.

@Keven, I used www.google.com for test. Actually, any webpage should have this problem.

Thanks.
Flags: needinfo?(pcheng)
Duplicate of this bug: 991748
ni? Gregor
Flags: needinfo?(anygregor)
It seems like killing the browser and then going to the topsites/history causes the issue.  If you type in a new url, you're not as likely to get this issue.
Summary: [tarako] browser sometimes unable to load a website → [tarako] browser unable to load a website from top sites/history after being the browser gets killed.
Whiteboard: [MP_Blocker]
triage: 1.3T+ partner blocker
blocking-b2g: 1.3T? → 1.3T+
Whiteboard: [MP_Blocker] → [priority]
ni? ehung as well
Flags: needinfo?(ehung)
I can't reproduce this issue :(
Naoki, can you reproduce?
Flags: needinfo?(anygregor) → needinfo?(nhirata.bugzilla)
Keywords: steps-wanted
I can't seem to repro on today's build:
Gaia      d9ac78148591a50356dd5a82d2d295eeb7c234a6
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/f105ec652173
BuildID   20140407004001
Version   28.1
ro.build.version.incremental=eng.cltbld.20140407.050056
ro.build.date=Mon Apr  7 05:01:03 EDT 2014
Tarako.

Peipei, can you try with today's build or more recent please?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(pcheng)
Removing steps-wanted.  Steps are from comment 0; I was able to reproduce last week.  Not in today's build.
Keywords: steps-wanted
Attached video STR Video
I can still reproduce this on latest build. Please see attached Video for steps.
Also, this is not website specific. I see this problem consistently. 

The key to reproduce this issue is: For the first time, please load website fully.


Gaia      9afe8145b5d309bdf2ef196b559e6dfd997faeeb
Gecko     https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/c2a0ee7b4d58
BuildID   20140407164002
Version   28.1
ro.build.version.incremental=eng.cltbld.20140407.202457
ro.build.date=Mon Apr  7 20:25:04 EDT 2014
Flags: needinfo?(pcheng)
Seems like we don't even try to load the page and go immediately to the crash page.
Ben, Dale, any idea?
Flags: needinfo?(dale)
Flags: needinfo?(bfrancis)
Very difficult to debug this without a device to reproduce it on. From the video it just looks like the content process is immediately getting killed due to low memory as soon as the load starts. Sorry I can't be more helpful.
Flags: needinfo?(bfrancis)
Gregor, i believe your team has received devices, are they being sent to Ben/Dale already? thanks
(In reply to Joe Cheng [:jcheng] from comment #15)
> Gregor, i believe your team has received devices, are they being sent to
> Ben/Dale already? thanks

Dale should receive one in the next 4-5 days.
I found an interesting thing which may or may not related to this issue: 

if the browser app is getting killed when it goes to background, i,e. there is no browser's process, but I still can see it shows on card view. After I remove browser app (card) to close this app, I can reproduce the problem here. Otherwise, everything goes well (the webpage starts loading after clicking on topsite/history)

I can try more times to see if I can get some useful logs.
(In reply to Evelyn Hung [:evelyn] from comment #17)
> I found an interesting thing which may or may not related to this issue: 
> 
> if the browser app is getting killed when it goes to background, i,e. there
> is no browser's process, but I still can see it shows on card view. After I
> remove browser app (card) to close this app, I can reproduce the problem
> here. Otherwise, everything goes well (the webpage starts loading after
> clicking on topsite/history)
> 
> I can try more times to see if I can get some useful logs.

BTW, the webpage I tried is tw.yahoo.com, which is a heavy website with a lot of text/images.
Flags: needinfo?(ehung)
(In reply to Evelyn Hung [:evelyn] from comment #17)
> I found an interesting thing which may or may not related to this issue: 
> 
> if the browser app is getting killed when it goes to background, i,e. there
> is no browser's process, but I still can see it shows on card view. After I
> remove browser app (card) to close this app, I can reproduce the problem
> here. Otherwise, everything goes well (the webpage starts loading after
> clicking on topsite/history)
> 
> I can try more times to see if I can get some useful logs.

Oh sorry, I misunderstood something. The "Browser" process is actually the webpage's process, so it getting killed doesn't mean the browser app is closed.
Whiteboard: [priority] → [priority] 1.3tarakorun2
Whiteboard: [priority] 1.3tarakorun2 → 1.3tarakorun2
(In reply to Ben Francis [:benfrancis] from comment #14)
> Very difficult to debug this without a device to reproduce it on. From the
> video it just looks like the content process is immediately getting killed
> due to low memory as soon as the load starts. Sorry I can't be more helpful.

Not sure if the content process is launched or not, but I see |this.currentTab.crashed| is true in |showPageScreen()| function when the problem occurs. I also noticed one more thing - in function |showPageScreen()|, this line:

  this.setUrlBar(this.currentTab.title || this.currentTab.url);

|this.currentTab.url| will always be the previous value if I use the same tab to navigate different sites. So in this case, because it's the first page we try to load, |this.currentTab.url| is always null, and |this.currentTab.crashed| sometimes true and sometimes undefined. I haven't figure out how the both values is set. 

Ben, can you provide more hints according to my observation? (you can ignore comment 17, it's not so relevant).
Flags: needinfo?(bfrancis)
I'm sorry I'm not sure I can help.

I would expect this.currentTab.crashed to be true if the crashed screen is being displayed, so that is correct.

What do you mean that this.currentTab.url will always be the URL of the first page we try to load? It should be updating for each mozbrowserlocationchange event. this.currentTab.crashed is set when a mozbrowsererror event is received in handleCrashedTab() and is reset by reviveCrashedTab() when you select or reload a tab.
Flags: needinfo?(bfrancis)
Dale should have a device to see whats going on.
Assignee: nobody → dale
Yup got my tarako and other bug landed, will take a look when I get back from my run
Flags: needinfo?(dale)
I reproduced this then proceeded to brick my device when debugging

the crash screen came up immediately, it looked somewhat like the preloaded browser tab was oom'd before we set the page to load, we may not want to preload that, or at least jut reload it when the user visits a page

In the browser we decided a while ago to show the use when we crash backgrounded tabs, we definitely shouldnt do it on initial page load, but not sure its a good idea at all, even on high spec devices like the nexus the browser are fairly aggressive about killing background tabs and I often see page reloads when switching back to previously open tabs, I think that should likely be our behaviour
Whiteboard: 1.3tarakorun2 → 1.3tarakorun2, [systemsfe]
Target Milestone: --- → 1.4 S6 (25apr)
Whiteboard: 1.3tarakorun2, [systemsfe] → 1.3tarakorun2, [systemsfe][sprd296178]
We'd better fix the issue before 4.25 -- spreadtrum PTR2 test cycle.
Flags: needinfo?(fabrice)
(In reply to Dale Harvey (:daleharvey) from comment #24)
> I reproduced this then proceeded to brick my device when debugging
> 
> the crash screen came up immediately, it looked somewhat like the preloaded
> browser tab was oom'd before we set the page to load, we may not want to
> preload that, or at least jut reload it when the user visits a page
> 
> In the browser we decided a while ago to show the use when we crash
> backgrounded tabs, we definitely shouldnt do it on initial page load, but
> not sure its a good idea at all, even on high spec devices like the nexus
> the browser are fairly aggressive about killing background tabs and I often
> see page reloads when switching back to previously open tabs, I think that
> should likely be our behaviour

Hi Dale,
Are you still working on this? what's the next step here? thanks.
Flags: needinfo?(fabrice) → needinfo?(dale)
Dale,

This is what I found with help from Evelyn.

STR:

1. Launch Browser. See start screen. See an non-visible mozbrowser iframe with App Manager.
2. check |adb shell b2g-ps| and verify browser process is alive.
3. kill the browser process with |adb shell kill|. Verify the iframe is removed in App Manager.
4. Click any link on the start screen.
5. See the crash screen
6. Hi reload
7. See the page loads in the newly created mozbrowser iframe, and visible.

I don't know why an empty mozbrowser iframe can get killed on Tarako (nor I know it's setVisible() status), but it seems that we could do better in Gaia Browser in step (5). Would you be able to modify the Browser app so that when the iframe is killed under the start screen/awsomescreen etc, it loads the content right away when url changes, instead of showing the crash screen?

That should be a valid fix fir the purpose of this bug.
Whiteboard: 1.3tarakorun2, [systemsfe][sprd296178] → 1.3tarakorun2, [systemsfe][sprd296178] [partner-blocker]
Yup sorry just got a bunch on my plate (and its a holiday), will get to this later tonight

Tim, yup that was what I seen to, will fix
Flags: needinfo?(dale)
We reload background tabs that have crashed when we switch between them via selectTab, but if the background process is killed before its loaded it showed the crashscreen
Attachment #8410096 - Flags: review?(bfrancis)
Attachment #8410096 - Flags: review?(bfrancis) → review+
Merged into master https://github.com/mozilla-b2g/gaia/commit/dbbedd999a98a231344f19aa1c41fd094a73acf2

Needs uplift.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Comment on attachment 8410096 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/18513

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): not a regression
[User impact] if declined: user may see the browser crash screen excessively
[Testing completed]: manual testing
[Risk to taking this patch] (and alternatives if risky): relatively minor, its a small change thats on master
[String changes made]:
Attachment #8410096 - Flags: approval-gaia-v1.4?
Duplicate of this bug: 998152
Comment on attachment 8410096 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/18513

This bug is only prominent on Tarako, not really on other devices with > 256 MB. On that regard, I don't think we need this on 1.4.
Attachment #8410096 - Flags: approval-gaia-v1.4? → approval-gaia-v1.4-
Verified that this no longer occurs using the steps in comment 27.

1.3T Environmental Variables:
Device: Tarako 1.3T MOZ
BuildID: 20140430014008
Gaia: f9b62bd1135f4edf8317fff1c2947b9d99438d79
Gecko: ba50f734b815
Version: 28.1
Firmware Version: sp6821a-Gonk-4.0-4-29
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.