Fullscreen toolbar button area should be at extreme edge of screen

NEW
Unassigned

Status

--
enhancement
17 years ago
9 years ago

People

(Reporter: horkana, Unassigned)

Tracking

({polish})

Trunk
polish

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
The selection/focus area for the buttons is not flush with the
edge of the screen.  There is a whole lot of usuability stuff about how usefull
it is to have the buttons right against the edge of the screen.   This is
especially annoying if you have bad aim (im using a touchpad) since usually when
a window is maximized you can just aim vague at the top right and overshoot and
be sure you will hit the x. 
http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html

I hope ive explained that clearly.   

Marked as OS all, as this does affect all platforms although at the time of
writing Full Screen has only been implemented on win32.  
The summary for this bug might benifit from being rephrased (but it should
always include the word Fullscreen)
(Reporter)

Updated

17 years ago
Severity: normal → enhancement
Depends on: 68136
Keywords: polish, ui
Hardware: PC → All

Comment 1

17 years ago
Mmmmm.... Fitt's Law.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

17 years ago
Yeah, IE 6 gets this right. Fitt's law actually works against us in current FS
mode, since the targets are both smaller and farther away than normal.
(Reporter)

Comment 3

17 years ago
Yeah, Fitts Law.  "I was a teenage Mac user".  
With the modern skin this problem is even worse (tiny round buttons).  Are there 
a User Interface Guidelines for Mozilla?  (more than this 
http://mozilla.org/unity-of-interface.html )
(In the modern theme I find it quite hard to hit the little arrow on the back 
button to go back many pages.  but thats a different feature/bug and i rarely 
use modern because of it).  
If someone provides directions to the necessary file(s) (in chrome?) that needs 
to be patched i might be able to figure out how to fix it.  

Comment 4

17 years ago
*** Bug 131082 has been marked as a duplicate of this bug. ***

Comment 5

17 years ago
I was just going to log this myself, especially since this is the one place the
microsoft actually leverages Fitt's Law appropriately.

Here's a start at a patch. If you remove the top borders from the toolbox and
toolbar-holder classes in chrome/classic/skin/classic/global/toolbar.css the
navigation buttons work as desired. You can click them from the top row of the
screen. Of course this change also causes cosmetic problems when not in
fullscreen mode, but I imagine that can be fixed pretty easily.

toolbox {
  -moz-appearance: toolbox;
  background-color: -moz-Dialog;
  border-left: 1px solid ThreeDShadow;
  /* border-top: 1px solid ThreeDShadow;*/
  border-right: 1px solid ThreeDHighlight;
}

...

.toolbar-holder {
  border-left: 1px solid ThreeDHighlight;
  /*border-top: 1px solid ThreeDHighlight;*/
  border-right: 1px solid ThreeDShadow;
  border-bottom: 1px solid ThreeDShadow;
}  

Comment 6

16 years ago
uid is being phased out.
Assignee: mpt → shliang
Component: User Interface Design → Themes
QA Contact: zach → pmac
Summary: Fullscreen toolbar button area should be at exteme edge of screen → Fullscreen toolbar button area should be at extreme edge of screen
(Reporter)

Comment 7

16 years ago
UID
user identification ?
user interface d______?

what do you mean?  I honestly have no idea what comment #6 is talking about

Please Always explain acronyms the first time you use them!

Comment 8

16 years ago
<Off Topic>

> what do you mean? I honestly have no idea what comment #6 is talking about

UID stands for User Interface Design, the component that this bug used to be in.
The UID component is being retired and all the bugs in it have to be moved to
different components. You can't move a bug without making a comment. See bug 167289.

</Off Topic>
(Assignee)

Updated

10 years ago
Product: Core → SeaMonkey
Assignee: shliang → nobody
QA Contact: pmac → themes

Comment 9

9 years ago
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED

Comment 10

9 years ago
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 11

9 years ago
Oops, didn't mean to do that. This appears to have been fixed at some point (looks good in Firefox 3.6), so I guess someone can set this to RESOLVED.
You need to log in before you can comment on or make changes to this bug.