Last Comment Bug 537717 - need feedback that navigation has started when url bar is offscreen
: need feedback that navigation has started when url bar is offscreen
Status: VERIFIED FIXED
:
Product: Fennec Graveyard
Classification: Graveyard
Component: General (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
:
Mentors:
: 529099 541964 (view as bug list)
Depends on: 564075 564285
Blocks:
  Show dependency treegraph
 
Reported: 2010-01-04 08:37 PST by Ted Mielczarek [:ted.mielczarek]
Modified: 2010-12-02 17:24 PST (History)
8 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch (1.66 KB, patch)
2010-01-05 07:38 PST, Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)
mark.finkle: review+
Details | Diff | Review

Description Ted Mielczarek [:ted.mielczarek] 2010-01-04 08:37:11 PST
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 Mark Finkle (:mfinkle) (use needinfo?) 2010-01-04 08:55:37 PST
The design is to float the URL toolbar when we start navigating. Obviously we need to do this much sooner.
Comment 2 Madhava Enros [:madhava] 2010-01-04 10:39:07 PST
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?
Comment 3 Ted Mielczarek [:ted.mielczarek] 2010-01-04 10:52:38 PST
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 Madhava Enros [:madhava] 2010-01-04 11:27:41 PST
Yeah - makes sense.  The time intervals are definitely too long for things to seem like there's a "chain of causation."
Comment 5 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2010-01-05 07:38:44 PST
Created attachment 420079 [details] [diff] [review]
Patch

This patch put the toolbar into locked mode as soon as long as it is in a loading state
Comment 6 Mark Finkle (:mfinkle) (use needinfo?) 2010-01-25 07:03:55 PST
*** Bug 541964 has been marked as a duplicate of this bug. ***
Comment 7 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2010-01-26 09:03:07 PST
just assigning to me to find it easily
Comment 8 Madhava Enros [:madhava] 2010-04-26 09:25:58 PDT
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).
Comment 9 Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please) 2010-04-26 16:26:50 PDT
(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 Mark Finkle (:mfinkle) (use needinfo?) 2010-04-29 22:27:35 PDT
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.
Comment 11 Mark Finkle (:mfinkle) (use needinfo?) 2010-04-29 22:29:46 PDT
pushed m-b:
http://hg.mozilla.org/mobile-browser/rev/64c363ad5a4d

waiting to push to m-1.1 until it bakes on m-b
Comment 12 Aakash Desai [:aakashd] 2010-04-30 13:14:06 PDT
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
Comment 13 Mark Finkle (:mfinkle) (use needinfo?) 2010-05-03 21:31:28 PDT
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?
Comment 14 Matt Brubeck (:mbrubeck) 2010-12-02 17:24:52 PST
*** Bug 529099 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.