794108 - [browser] stop throbber when page loading stopped even if platform still working

Status: RESOLVED WONTFIX

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

Description

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

Environment :
Otoro phone, build 2012-07-24
Taken from default.xml in b2g-distro:
    "platform_build" revision= 2163d79
    "gaia" revision= a97c4a1
    "mozilla-central" revision= d653690
    "gonk-misc" revision= c6a9a25

Repro :
1.    launch browser web app
2.    go to a http://planet.mozilla.org
3.    click on x in the URL bar

Expected :
    Should take a second at most for the browser to stop loading

Actual :
    Takes roughly 30 seconds.

Note :
*    depending on the page, it could end up taking a while for the awesome page to appear itself.
*    http://www.youtube.com/watch?v=e19I0HNiqCE
*    also sometimes the x won't appear after the first time you load.

From: https://github.com/mozilla-b2g/gaia/issues/2762
Reproducible in yesterday's build

Comment 1

[Andrew Overholt [:overholt]]

We debated this for a while in triage and it's unclear if there's anything that can be done.  Jeff, can you do us a solid and get an on-device profile of this behaviour?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure if a normal profile is what we really need here. What we need to figure out is why it takes so long to get to the stop event which is sent to the child process.

Comment 3

[Tony Chung [:tchung]]

i tried comment 0 with a 9-25-2012 daily build, and was not able to reproduce.  hitting the X will stop the pageload on planet almost immediately (~1 sec)

Gecko commmit: 1c333645ec70bfce2176876e4bfaf24bfd4bbde5
Gaia commit: 71e89d4338d59a86e8599abeda24dbfaf1c80e1a

Can someone else try and reproduce with a more recent build?

Comment 4

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

I tried with today's build and I can reproduce both on Mozilla G and Mozilla Guest:

Otoro phone, build 2012-09-26 us
Taken from default.xml in b2g-distro: 
* "platform_build" revision= 795261940c8b11fb7dddd7a8e9dd8561fdc4fb64
* "gaia" revision= 34bcd071074c4b5802195fd9173bd108e6c5891c 
* "releases-mozilla-central" revision= 35d92aa2a19da7aa89cffd7508d7d2ea40d40bc7
* "gonk-misc" revision= 1fa95341cd2bbf5d476cbcf84d03c33cd5fe66fc

Not only that the browser crashes.
https://gist.github.com/3789543  Unfortunately I don't think it shows anything useful from the browser crash.

Comment 5

[Justin Lebar (not reading bugmail)]

Can you reproduce the browser crash under GDB?

(Note that run-gdb.sh isn't what you want, since that debugs the /master/ GDB process.  But I'm sure if you ask on #b2g someone can help you attach to an existing plugin-container process.)

Comment 7

[Justin Lebar (not reading bugmail)]

basecamp+ --> basecamp?

I think all that's happening here is that the child process is freezing as it falls over on the large people.m.o page.  There's very little that we can do in this case at a platform level short of killing the process.

If that's the case, we should probably mark this bug as WONTFIX (CANTFIX, really).  We could modify Gaia to stop the throbber as soon as we press the X (even if the child doesn't acknowledge the stop command), but that could be misleading, as the page still might load.  I leave that up to the UX people.

Comment 8

[Andrew Overholt [:overholt]]

Josh, how do you feel about what I changed the summary to?

Comment 9

[Dietrich Ayala (:dietrich)]

Ben said we can't do anything better (like have timeouts that kill and restart the content process, or notice the lack of progress events and kill the content process, or otherwise detect that it's not just web content taking a long time to load/render), so can't fix for v1 until we get better platform support.

I don't think this is WONTFIX or CANTFIX, just not fixable in V1 without a lot of platform work that we don't have time for.

Comment 10

[Josh Carpenter [:jcarpenter]]

> Josh, how do you feel about what I changed the summary to?

Referring to the following? "[browser] stop throbber when page loading stopped even if platform still working" — That looks right to me.

> We could modify Gaia to stop the throbber as soon as we press the X (even if the child doesn't acknowledge the stop command), but that could be misleading, as the page still might load.  I leave that up to the UX people.

That's my preference. It's Very Bad if our browser gives target market users the impression that the page is continuing to suck down data (expensive, slow data) 30 seconds after they've hit Stop button.

Per Jutin, can we hide the throbber as soon as the user hits X? It's hacky, but I'd gladly take it over the WONTFIX alternative.

Comment 11

[Josh Carpenter [:jcarpenter]]

cc'ing Larissa, who owns UX for Browser.

Comment 12

[Justin Lebar (not reading bugmail)]

> It's Very Bad if our browser gives target market users the impression that the page is continuing 
> to suck down data (expensive, slow data) 30 seconds after they've hit Stop button.

Just to be clear, that impression may in fact be correct!

Comment 13

[Josh Carpenter [:jcarpenter]]

> Just to be clear, that impression may in fact be correct!

Thanks Justin, good to know. Can you estimate the frequency?

Comment 14

[Justin Lebar (not reading bugmail)]

(In reply to Josh Carpenter [:jcarpenter] from comment #13)
> > Just to be clear, that impression may in fact be correct!
> 
> Thanks Justin, good to know. Can you estimate the frequency?

The frequency with which that might be the case?

It entirely depends on how often users load gigantic pages that partially-OOM the device.  What frequency of giant loads which hamstring the device will result in extra data transfer after hitting stop?  I can't say; you'd have to experiment.  It's not clear to me that any would, necessarily, but it strikes me as possible that it would happen frequently.

Sorry I can't be more specific than that.

Comment 15

[Larissa Co [:lco]]

(In reply to Josh Carpenter [:jcarpenter] from comment #10)

> 
> > We could modify Gaia to stop the throbber as soon as we press the X (even if the child doesn't acknowledge the stop command), but that could be misleading, as the page still might load.  I leave that up to the UX people.
> 
> That's my preference. It's Very Bad if our browser gives target market users
> the impression that the page is continuing to suck down data (expensive,
> slow data) 30 seconds after they've hit Stop button.
> 
Well, it's still consuming data in the background even if the user doesn't see it happening, right? Simply hiding the throbber doesn't change the fact that the stop event takes a long time to have any effect on the page. I think that's just something we'll have to accept.

That being said, the user need here is to stop the page from loading once he hits the stop button. So how about this modification once the user hits the stop button:

1. The "X" icon goes into a pressed/greyed out state to indicate that it's responding to the user's actions.
2. The indeterminate progress bar disappears [I don't have a definitive stance on the progress bar's state: I think we should try this approach first and see how it feels]
3. Once the site loading is actually "stopped" the "X" icon is replaced by the "reload" icon.

This way, the user isn't surprised if new content loads even after they're pressed the stop button, and it doesn't seem like the browser is being unresponsive to pressing the stop button

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Please note that the summary of this bug is now "stop throbber when user presses stop button even if platform is still working".

I.e. as currently summarized, this bug just requires gaia changes and is most certainly fixable.

Now, we might not want to do that, because of what's pointed out in comment 12. But it's definitely doable in the v1 timeframe if we do want to do it.

Comment 17

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

It's also doable to kill content off a timeout if it doesn't stop, but defining what "stop" means is pretty hard, and that would probably require new UI and strings.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yeah, I don't think we want to do that in the browser since it'll often bring down other pages too.

Comment 19

[Ben Francis [:benfrancis]]

(In reply to Dietrich Ayala (:dietrich) from comment #9)
> Ben said we can't do anything better (like have timeouts that kill and
> restart the content process, or notice the lack of progress events and kill
> the content process, or otherwise detect that it's not just web content
> taking a long time to load/render), so can't fix for v1 until we get better
> platform support.

I don't think that's quite what I said, I don't know what can and can't be done on the platform. I just meant that Gaia can only respond to the events it gets, so if it doesn't get the callback when it requests a stop, it's still going to think the page is loading (which it might be).

However, as Larissa points out, we could introduce a new "stopping" state to this button so that the user gets feedback that their action has been recognised whilst not falsely giving the impression that the page has definitely stopped loading. This is a bit of a hack (and I'm a bit concerned about hiding the progress bar when it could be that data is still being transferred), but it may be the best the browser app can do within the constraints we have.

If that's what we want I can take this and implement the changes in the browser app.

Comment 20

[Larissa Co [:lco]]

Right, just to be clear, the ideal solution for me is to fix the bug so that it doesn't take >5 seconds for the page to actually stop loading from the time that the user hits the "X" button. But if that isn't possible, then we really need some kind of "hack" (like the one I proposed) one way or another.

And honestly, maybe we don't have to hide the progress bar. I can't say for sure. It might be that greying out the "X" button is not obvious enough without hiding the progress bar too, or it might be that hiding the progress bar is more confusing. I think we have to pick one and try it.

Comment 21

[Ben Francis [:benfrancis]]

OK, taking this. I'm going to need a "greyed out stop button" Patryk.

Comment 22

[Larissa Co [:lco]]

(In reply to Ben Francis [:benfrancis] from comment #21)
> OK, taking this. I'm going to need a "greyed out stop button" Patryk.

Thanks, Ben :)

Comment 23

[Ben Francis [:benfrancis]]

Re-nominating for blocking-basecamp as we have a proposed (hacky) workaround we could apply in Gaia.

Comment 24

[Ben Francis [:benfrancis]]

In triage this was decided to be blocking- because it's only really a workaround and doesn't fix the underlying issue, but if I get chance I will work on a patch.

Comment 26

[Cody Roesch [:croesch]]

UCID browser-007
Testcase found here https://moztrap.mozilla.org/results/case/61159/

Comment 27

[Jeni]

Issue repros on unagi build 20130115070201 Kernel from Dec 5th

Comment 29

[Ben Francis [:benfrancis]]

Closing as per comment 7 and comment 10, Gaia gives the best indication it can to the user based on the information it receives.

Comment 31

[Jeni]

Issue repros on 
Leo Build ID: 20130625070217
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/29933d1937db
Gaia: 1436e2778b90bd74635b0b94d1cf8ccb0d71b60c
Platform Version: 18.1
RIL Version: 01.01.00.019.138 

When attempting to stop a page from loading the page continues to load.