Closed
Bug 126961
Opened 23 years ago
Closed 1 year ago
Fullscreen toolbar button area should be at extreme edge of screen
Categories
(SeaMonkey :: Themes, enhancement)
SeaMonkey
Themes
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: horkana, Unassigned)
References
()
Details
(Keywords: polish)
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)
Comment 2•23 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.
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•23 years ago
|
||
*** Bug 131082 has been marked as a duplicate of this bug. ***
Comment 5•23 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; }
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
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•22 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•16 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Assignee: shliang → nobody
QA Contact: pmac → themes
Comment 9•16 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•15 years ago
|
||
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•15 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.
Comment 12•1 year ago
|
||
Closing per comment 11
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•