Closed Bug 794108 Opened 10 years ago Closed 9 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:-)

RESOLVED WONTFIX
blocking-basecamp -

People

(Reporter: nhirata, Unassigned)

References

Details

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
Keywords: perf
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?
Assignee: nobody → jmuizelaar
blocking-basecamp: ? → +
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.
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?
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.
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.)
Duplicate of this bug: 796010
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.
blocking-basecamp: + → ?
Josh, how do you feel about what I changed the summary to?
Assignee: jmuizelaar → nobody
Component: General → Gaia::Browser
Summary: [browser] responsiveness of stopping a web page from loading is slow → [browser] stop throbber when page loading stopped even if platform still working
Whiteboard: [blocked-on-input Josh Carpenter]
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.
blocking-basecamp: ? → -
> 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.
cc'ing Larissa, who owns UX for Browser.
> 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!
> Just to be clear, that impression may in fact be correct!

Thanks Justin, good to know. Can you estimate the frequency?
(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.
(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
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.
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.
Yeah, I don't think we want to do that in the browser since it'll often bring down other pages too.
(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.
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.
OK, taking this. I'm going to need a "greyed out stop button" Patryk.
Keywords: perf
QA Contact: ben
Whiteboard: [blocked-on-input Josh Carpenter] → [label:needsVisualInput]
Assignee: nobody → ben
QA Contact: ben
(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 :)
Re-nominating for blocking-basecamp as we have a proposed (hacky) workaround we could apply in Gaia.
blocking-basecamp: - → ?
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.
blocking-basecamp: ? → -
Assignee: ben → nobody
Priority: -- → P4
Duplicate of this bug: 796426
UCID browser-007
Testcase found here https://moztrap.mozilla.org/results/case/61159/
Whiteboard: [label:needsVisualInput] → [label:needsVisualInput], testrun 2
Issue repros on unagi build 20130115070201 Kernel from Dec 5th
Duplicate of this bug: 847500
Closing as per comment 7 and comment 10, Gaia gives the best indication it can to the user based on the information it receives.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [label:needsVisualInput], testrun 2 → [label:needsVisualInput], testrun 2, inarirun2
Blocks: 882445
Duplicate of this bug: 882445
Whiteboard: [label:needsVisualInput], testrun 2, inarirun2 → [label:needsVisualInput], testrun 2, inarirun2, leorun3
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.
Whiteboard: [label:needsVisualInput], testrun 2, inarirun2, leorun3 → [label:needsVisualInput], testrun 2, inarirun2, leorun3, leorun4
Whiteboard: [label:needsVisualInput], testrun 2, inarirun2, leorun3, leorun4
You need to log in before you can comment on or make changes to this bug.