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

Status: VERIFIED FIXED

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

Description

[Peipei Cheng (needinfo if you need my action)]

Attachment: 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

Comment 1

[Joe Cheng [:jcheng] (please needinfo)]

how easy is it to reproduce it? and can the symptom be recovered after user reloads the page? thanks

Comment 2

[Keven Kuo [:kkuo]]

Hi! Peipei,

Could you provide the web side you tested with?
Thanks

--
Keven

Comment 3

[Peipei Cheng (needinfo if you need my action)]

@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.

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

ni? Gregor

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3T+ partner blocker

Comment 8

[Joe Cheng [:jcheng] (please needinfo)]

ni? ehung as well

Comment 9

[Gregor Wagner [:gwagner]]

I can't reproduce this issue :(
Naoki, can you reproduce?

Comment 10

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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?

Comment 11

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Removing steps-wanted.  Steps are from comment 0; I was able to reproduce last week.  Not in today's build.

Comment 12

[Peipei Cheng (needinfo if you need my action)]

Attachment: 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

Comment 13

[Gregor Wagner [:gwagner]]

Seems like we don't even try to load the page and go immediately to the crash page.
Ben, Dale, any idea?

Comment 14

[Ben Francis [:benfrancis]]

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.

Comment 15

[Joe Cheng [:jcheng] (please needinfo)]

Gregor, i believe your team has received devices, are they being sent to Ben/Dale already? thanks

Comment 16

[Gregor Wagner [:gwagner]]

(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.

Comment 17

[Evelyn Hung]

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.

Comment 18

[Evelyn Hung]

(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.

Comment 19

[Evelyn Hung]

(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.

Comment 20

[Evelyn Hung]

(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).

Comment 21

[Ben Francis [:benfrancis]]

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.

Comment 22

[Gregor Wagner [:gwagner]]

Dale should have a device to see whats going on.

Comment 23

[Dale Harvey (:daleharvey)]

Yup got my tarako and other bug landed, will take a look when I get back from my run

Comment 24

[Dale Harvey (:daleharvey)]

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

Comment 25

[James Zhang (Spreadtrum)]

We'd better fix the issue before 4.25 -- spreadtrum PTR2 test cycle.

Comment 26

[Steven Yang [:styang]]

(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.

Comment 27

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

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.

Comment 28

[Dale Harvey (:daleharvey)]

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

Comment 29

[Dale Harvey (:daleharvey)]

Attachment: https://github.com/mozilla-b2g/gaia/pull/18513

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

Comment 30

[Ben Francis [:benfrancis]]

Merged into master https://github.com/mozilla-b2g/gaia/commit/dbbedd999a98a231344f19aa1c41fd094a73acf2

Needs uplift.

Comment 31

[Dale Harvey (:daleharvey)]

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]:

Comment 32

[Dale Harvey (:daleharvey)]

upilfted to v1.3t

https://github.com/mozilla-b2g/gaia/commit/bfdf93ec79dc39c7db456af2998284349ba5eb48

Comment 34

[Jason Smith [:jsmith]]

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.

Comment 35

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

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