Closed
Bug 537717
Opened 14 years ago
Closed 14 years ago
need feedback that navigation has started when url bar is offscreen
Categories
(Firefox for Android Graveyard :: General, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: ted, Assigned: vingtetun)
References
Details
Attachments
(1 file)
1.66 KB,
patch
|
mfinkle
:
review+
|
Details | Diff | Splinter Review |
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.
Comment 1•14 years ago
|
||
The design is to float the URL toolbar when we start navigating. Obviously we need to do this much sooner.
Comment 2•14 years ago
|
||
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?
Reporter | ||
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
Yeah - makes sense. The time intervals are definitely too long for things to seem like there's a "chain of causation."
Assignee | ||
Comment 5•14 years ago
|
||
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)
Comment 8•14 years ago
|
||
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).
Assignee | ||
Comment 9•14 years ago
|
||
(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 10•14 years ago
|
||
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+
Comment 11•14 years ago
|
||
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: 14 years ago
Resolution: --- → FIXED
Comment 12•14 years ago
|
||
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
Comment 13•14 years ago
|
||
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.
Description
•