Using Fennec, I noticed that when you scroll the URL bar offscreen, we don't provide any feedback that navigation has started if you click a link or submit a form or anything like that. I kept getting frustrated by not by being unable to distinguish between "failed to click on a link" and "clicked on a link, page is loading but current page still remains displayed". I think we need to provide some sort of feedback for this case.
The design is to float the URL toolbar when we start navigating. Obviously we need to do this much sooner.
Yeah - there's some lag right now. There's a chain of "you've done something" feedback here. 1. link "highlighting" on activation -- tells you hit the link 2. link gets a border on focus -- tells you the browser is doing something (kind of) 3. URL bar hovers in -- tells you the browser is working on loading the page Ideally, 1 and 2 could be combined because 2 would following 1 so quickly (we show both right now because 2 was taking so long and there was no feedback for 1). Possibly 3 could move in sooner than it does -- does it wait for loading to actually begin? If so, maybe we could show it even sooner?
As a user, 1 & 2 didn't seem to be providing me useful feedback. The fact that I had hit the link and the fact that navigation had started either didn't always correlate, or there was enough time delay that I fell back to wondering whether I had effectively clicked it.
Yeah - makes sense. The time intervals are definitely too long for things to seem like there's a "chain of causation."
This patch put the toolbar into locked mode as soon as long as it is in a loading state
Attachment #420079 - Flags: review?(mark.finkle)
just assigning to me to find it easily
Assignee: nobody → 21
This would be a big win for perceived performance. If the URL bar floats with a throbber a-throbbin' in quick succession after the link decoration for focus happens, the user gets the sense that the browser is being quick even if the page still takes a while to load (moves the sense of slowness from the browser to the page).
(In reply to comment #8) > This would be a big win for perceived performance. If the URL bar floats with > a throbber a-throbbin' in quick succession after the link decoration for focus > happens, the user gets the sense that the browser is being quick even if the > page still takes a while to load (moves the sense of slowness from the browser > to the page). I think the patch is still valid but we need to test that heavily, this part of the code is regression prone.
Comment on attachment 420079 [details] [diff] [review] Patch Browsing for a while and things seem to be working fine. This would be nice to get on 1.1, but let's get it on m-b first. I changed _updateToolbarButton -> _updateToolbar, since the method is doing more work now. Lastly, can we get a test or two for this? I think the main thing to test is making sure we unlock the toolbar after the load is finished. I don't know how we could test that the toolbar is locked when a page starts loading - since the load could be very fast.
Attachment #420079 - Flags: review?(mark.finkle) → review+
pushed m-b: http://hg.mozilla.org/mobile-browser/rev/64c363ad5a4d waiting to push to m-1.1 until it bakes on m-b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
verified FIXED on build: Mozilla/5.0 (X11; U; Linux armv71; Nokia N900; en-US; rv:1.9.3a5pre) Gecko/20100430 Namoroka/3.7a5pre Fennec/1.1b2pre
Status: RESOLVED → VERIFIED
this has baked a while on trunk pushed m-1.1: http://hg.mozilla.org/releases/mobile-1.1/rev/6943b0f60c58 Aakash, can you verify on mobile-1.1 (mozilla-1.9.2) builds?
You need to log in before you can comment on or make changes to this bug.