To find a balance between not needlessly distracting users an letting them check the link target when they want to, we should consider delaying status updates for links further. The update currently happens when the mouse has rested for 70 ms over a link. I've been playing with 500, the same delay we use for tooltips, which felt okay to me.
I have no idea if this is average user behavior, but I find that I often time my eye movements so that my cursor mouses over a link just as my eye focuses on the lower left corner of the browser window. I think that the status bubble is also less distracting than tooltips, because they do not appear next to the cursor. FWIW, 500 ms would make us much slower than Chromium, which uses the following timeouts, and this could be interpreted by users as latency/jank: > email@example.com wrote: > kShowDelay = 80 (ms to wait before showing a bubble when hidden) > kHideDelay = 250 (ms to wait before hiding a bubble when shown) > kShowFadeDurationMS = 120 (ms to play the fade-in transition) > kHideFadeDurationMS = 200 (ms to play the fade-out transition) This is roughly equivalent to |-moz-transition-delay: 80ms; moz-transition-duration: 120ms;| for making the bubble appear. http://code.google.com/p/chromium/issues/detail?id=24495 http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/status_bubble_views.cc?view=markup
Bug 632366 added a hidden pref for this: browser.overlink-delay When changing it, you need to restart for the change to apply.
Created attachment 515440 [details] [diff] [review] patch I've been running with browser.overlink-delay = 500 for a few weeks now and it still feels right to me. However, at this point it's probably safer to just add a slight delay like Chrome. This patch changes the time you need to rest over a link from 70 to 80ms, lets the bubble fade in for 120 instead of 100ms, hide 250 instead of 150ms after leaving a link, and adds a 200ms fade out transition.
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #515440 - Flags: ui-review?(faaborg)
try builds will appear here: http://firstname.lastname@example.org
Attachment #515440 - Flags: ui-review?(faaborg) → ui-review+
Also worried about percieved jankyness of 500ms, but 80 is fine.
Attachment #515440 - Flags: review?(gavin.sharp)
Comment on attachment 515440 [details] [diff] [review] patch I would like to see no delay in displaying URL. Can you please add an about:config item to disable -moz-transition
Attachment #515440 - Flags: review?(gavin.sharp) → review+
Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/f27d8d9c8779 - it appears to have broken test_leaf_layers_partition_browser_window.xul, e.g. https://tbpl.mozilla.org/php/getParsedLog.php?id=6561652&tree=Mozilla-Inbound and https://tbpl.mozilla.org/php/getParsedLog.php?id=6562697&tree=Mozilla-Inbound
(In reply to Phil Ringnalda (:philor) from comment #8) > Backed out in > https://hg.mozilla.org/integration/mozilla-inbound/rev/f27d8d9c8779 - it > appears to have broken test_leaf_layers_partition_browser_window.xul, e.g. > https://tbpl.mozilla.org/php/getParsedLog.php?id=6561652&tree=Mozilla- > Inbound and > https://tbpl.mozilla.org/php/getParsedLog.php?id=6562697&tree=Mozilla-Inbound Fixed by setting inactive="true" on the statuspanel in browser.xul
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
You need to log in before you can comment on or make changes to this bug.