Closed Bug 789867 Opened 12 years ago Closed 12 years ago

On startup when loading page from last session, stop button does not respond to touch

Categories

(Firefox for Android Graveyard :: General, defect)

18 Branch
ARM
Android
defect
Not set
normal

Tracking

(firefox20 verified, fennec+)

VERIFIED FIXED
Firefox 20
Tracking Status
firefox20 --- verified
fennec + ---

People

(Reporter: geeknik, Assigned: bnicholson)

References

Details

Attachments

(1 file, 1 obsolete file)

I'm using the latest nightly build of Firefox for Android on my Nexus 7 and I've noticed that when I start the browser up and it's load a page from a previous session, the stop button doesn't respond to my touches. In fact, I touched it about a dozen times and then Firefox crashed (which I guess counts as stopping the page load). 

Crash Report: https://crash-stats.mozilla.com/report/index/bp-86a43c8e-219c-4725-9704-7603a2120910
Is this a regression?
tracking-fennec: --- → ?
I'm able to reproduce on Nightly (09/12), Galaxy Nexus (Android 4.1.1)
I haven't looked into the code, but I suspect this could be an issue if gecko hasn't started yet, since there would be nothing to handle the stop message we're trying to send. If that's the case, maybe we can just make sure we kill the throbber right away, then kill the attempt to load the page once gecko gets going.
Brian - Can you confirm Margaret's theory?
Assignee: nobody → bnicholson
tracking-fennec: ? → +
Mark, I agree with that. Probably the same reason everything is grayed out in the Settings menu right after start up.
Attached patch band-aid patch (obsolete) — Splinter Review
Yes, this is what's happening. Gecko hasn't started yet, so the tab is null, so the Session:Stop message gets aborted at [1].

There's two problems here. First we actually don't send the message in the first place, so Gecko has nothing to handle once it's loaded. Second, we don't stop the throbber until we get a response back from Gecko, so even if we add the stop message to the queue before Gecko is loaded, the throbber won't stop until Gecko has processed it.

Here's a simple fix that addresses these problems, but there's a number of side effects:
1) setProgressVisibility checks to see if the selected tab is null when setting the favicon [2]. Since we have no tab yet, this means we don't have a favicon to use. As a result, clicking stop with this patch just freezes the throbber without updating the favicon (normally, clicking stop will hide the throbber and show the blank favicon placeholder).
2) We don't draw a blank canvas until Gecko is ready. This means that after clicking stop, the user still sees a blue background for a few seconds. We might want to fix this by immediately drawing a white surface if we aren't loading about:home.
3) After stopping, clicking the reload button loads about:blank instead of the URL that was loading.

A more proper fix that should address issue #1 would be to stub the tabs at startup (bug 722661).

[1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserToolbar.java#218
[2] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/BrowserToolbar.java#489
The most common session restore case, OOM restores, will be fixed by bug 722661 since we'll have a tab that we can call doStop() on.
Depends on: 722661
Happens to me as well. I usually kill firefox since it just freezes on my SGS2 (GT-I9100, Android 4.0.4, branded OrangeRO, build number IMM76D.BVLPH). In less than 5 minutes the battery drops 15 percent, and there is a lot of heat dissipated below the camera (CPU). After I kill firefox, once I start it again, the last page it remembers (anyway, I had 3/4 pages opened, its opened tabs checkpoint is far from what I had opened) starts loading and I cannot cancel its loading (the X button next to it).

Also, 645340 is current. I don`t know why it`s closed. It kills my day each time I use firefox.

PS: does someone have any hint on a reliable bookmarks/password sync utility with plugins for other browsers both on android and desktop? I am willing to migrate away from firefox as it started to be sh,..,.,.,itty. Not proud of what I say, but this is the bare truth and it`s really bad.
This was fixed almost entirely by bug 722661. The only remaining change that needs to be made is stopping the throbber immediately (since we wait until we get a stop acknowledgement back from Gecko).

We still have an issue where hitting refresh after stopping the first page load will end up loading about:blank, but perhaps we can handle that in a different bug.
Attachment #660936 - Attachment is obsolete: true
Attachment #683823 - Flags: review?(mark.finkle)
Attachment #683823 - Flags: review?(mark.finkle) → review+
File a new bug for the "stop, then refresh = about:blank" issue?
Depends on: 814110
https://hg.mozilla.org/mozilla-central/rev/69f0f4812e2c
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
The Stop button works now correctly when it's pressed just after a session restore. Closing bug as verified fixed on:

Firefox 20.0a1 (2012-11-28)
Device: Galaxy Nexus
OS: Android 4.1.1
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.