Closed Bug 677027 Opened 13 years ago Closed 13 years ago

Implement conditional forward button for gnomestripe

Categories

(Firefox :: Theme, enhancement)

All
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 10

People

(Reporter: dao, Assigned: dao)

References

Details

(Keywords: ux-minimalism)

Attachments

(1 file)

Attached patch patch (deleted) — Splinter Review
I was just playing with this and it works surprisingly well even without the keyhole, so I figured I may as well put it up for review. The button shifts the location bar when it appears, as does the keyhole-dependent implementation for windows and mac in bug 674744. I would normally be concerned about this kind of movement being distracting, but it turns out this isn't a big deal here, since it happens while the page is also changing.
Attachment #551255 - Flags: review?(shorlander)
pushed to ux
Comment on attachment 551255 [details] [diff] [review] patch Review of attachment 551255 [details] [diff] [review]: ----------------------------------------------------------------- Looks good although 300 or 250ms feels a little snappier to me. I guess there is no way with this approach to avoid shifting the searchBar and the locationBar? Right now that is the only jarring part. Something Jared and I were talking about in regards to bug 674744 was minimizing the shifting as much as possible. Ideally only the locationBar would slide over to keep the transition as subtle as possible.
Attachment #551255 - Flags: review?(shorlander) → review+
> I guess there is no way with this approach to avoid shifting the searchBar > and the locationBar? Right now that is the only jarring part. Well, there is a way: Let the back button consume more space and shrink that to make room for the forward button. I'm not sure at all if that's a better approach, though.
(In reply to Dão Gottwald [:dao] from comment #3) > I'm not sure at all if that's a better approach, though. Probably not :)
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 9
Flags: in-testsuite? → in-testsuite-
Why do we *can't*? test this?
Flags: in-testsuite- → in-testsuite?
Why do we just have this for Linux and not on all platforms? (Bug 674744)
(In reply to Mounir Lamouri (:volkmar) from comment #6) > Why do we *can't*? test this? This code is doing nothing that we'd need or want to test.
Flags: in-testsuite? → in-testsuite-
(In reply to Dão Gottwald [:dao] from comment #0) > The button shifts the location bar when it appears, as does the > keyhole-dependent implementation for windows and mac in bug 674744. I would > normally be concerned about this kind of movement being distracting, but it > turns out this isn't a big deal here, since it happens while the page is > also changing. Just for the record, this *is* distracting, and can be somewhat problematic. * Every time it pops in or out, it draws my attention to it. As such, it's constantly drawing my attention away from the content area, which, for a browser, seems counter productive. Yes, the page content is changing, but it's still disruptive to the browsing 'flow', as you (I) now refocus/context-switch twice instead of maybe once. * When I open a blank tab to enter something in the location bar, I usually have already focused on the location bar (or I'm already in the process of doing so). So having it jump to the left is, again, disruptive. * If, say, you've gone back a few pages to check something, then want to go back to the most recent page, click-spaming the forward button will often result in clicking the identity button (or, in my case, reload). I can see how this makes sense on a mobile device, but is this necessary, or even useful, on a desktop?
Depends on: 682536
FWIW, this is rather distracting when reading a Web forum where you open a thread (forward button goes away), go back to list of threads (forward button comes back), open the next thread (forward button goes away), etc.
Backed out in preparation for the aurora merge, since the followup bugs didn't make it (blocked by bug 682534).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 9 → ---
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Depends on: 694084
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: