Closed
Bug 887397
Opened 8 years ago
Closed 7 years ago
Window click and drag target is too small
Categories
(Firefox :: Theme, defect)
Firefox
Theme
Tracking
()
VERIFIED
FIXED
Firefox 30
People
(Reporter: liuche, Assigned: MattN)
References
Details
(Whiteboard: [Australis:P3+])
Attachments
(2 files, 1 obsolete file)
283.77 KB,
image/png
|
Details | |
2.67 KB,
patch
|
Gijs
:
review+
MattN
:
ui-review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
The target for dragging a window is much smaller than the original, probably less than half the size. However, with the fading of the top tab, the click-drag target appears to be larger, and even after having used Australis for a while, I find myself overshooting the target ALL THE TIME because I can't see the top of the tab. A possible suggestion would be to shrink the mouse-over target for activating the tab-highlight so it is lower than the top of the tab.
Updated•8 years ago
|
Whiteboard: [Australis:M?]
Updated•8 years ago
|
Blocks: australis-tabs-osx
Assignee | ||
Updated•8 years ago
|
Hardware: x86 → All
Comment 1•8 years ago
|
||
Not sure there's much actionable here. The draggable target is overall smaller with tabs-in-titlebar, yes. Also true that the top of background tabs may look like a draggable thing until mouseover (especially when moving downwards, so there's less time for the :hover style to register). And all the arguments would apply in reverse for selecting a tab when you didn't want to drag it, if we changed this.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Assignee | ||
Comment 3•7 years ago
|
||
Reopening because there is possibly something that can be done for all tabs including selected ones as there is a pixel or two above the stroke (with a glow) that doesn't need to be clickable/draggable. We will need to evaluate the cost/benefit ratio for fixing.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [Australis:M?] → [Australis:P4]
Comment 4•7 years ago
|
||
(I wrote this before Comment 3 was posted) I disagree with wontfix. The drag area is too small and is a serious problem for people without fine motor skills. I even struggle with it. Note that the tab mouse over seems to register 1-2 pixels early. I count about 6 pixels I can use to drag which is 0.5% of my monitor height which is increasingly difficult to select reliably. Can we re-open this bug? If it's up to me I'd make the tabs shorter (A lot of wasted space above/under the tab text that I would prefer to have in the title bar).
Assignee | ||
Comment 5•7 years ago
|
||
As discussed at the Paris work week, we should reduce the pointer-event area from background tabs to increase the area to drag the titlebar in cases where we aren't trying to achieve gains from Fitts' Law (e.g. restored windows).
Status: REOPENED → NEW
OS: Mac OS X → All
Summary: [Australis] window click and drag target is much smaller than it visually appears → Window click and drag target is too small
Whiteboard: [Australis:P4] → [Australis:P3]
Comment 6•7 years ago
|
||
Adding a quick illustration of the area that should be dragable. The hover effect of the background tabs should not trigger above the line. This only applies when the window is not in full screen mode (in which case the behavior should be the same as it is today). We might need to adjust the exact threshold a little when we get to actually test this.
Comment 7•7 years ago
|
||
Also, the behavior of the currently selected tab shouldn't change at any time.
Comment 8•7 years ago
|
||
So very glad this is being looked at; my hands have developed a tremor the last few months, and the very small grab-and-drag area has been very frustrating. I've turned back on the title bar, but that's sort of a stop-gap measure, since I'm not at all convinced that ability will stick around over the long term. :)
Comment 9•7 years ago
|
||
One more thing we can do: make the area to the right of the new tab button dragable (see attachment: red area or area to the right of the line). Evidently, we already do that with the first tab.
Assignee | ||
Comment 10•7 years ago
|
||
I can give this a try. I won't know how easy it will be until I dig into it though.
Assignee: nobody → MattN+bmo
Status: NEW → ASSIGNED
Comment 11•7 years ago
|
||
(In reply to Eric Shepherd [:sheppy] from comment #8) > So very glad this is being looked at; my hands have developed a tremor the > last few months, and the very small grab-and-drag area has been very > frustrating. I've turned back on the title bar, but that's sort of a > stop-gap measure, since I'm not at all convinced that ability will stick > around over the long term. :) FWIW, on this front, there's now a toggle in the customization mode to show/hide the titlebar. This is, in part, a result of your feedback, Sheppy.
Updated•7 years ago
|
Whiteboard: [Australis:P3] → [Australis:P3+]
Comment 12•7 years ago
|
||
(In reply to Madhava Enros [:madhava] from comment #11) > FWIW, on this front, there's now a toggle in the customization mode to > show/hide the titlebar. This is, in part, a result of your feedback, Sheppy. The added options in the customization mode are a great improvement; thanks! Making it a little easier to drag while in draw-in-title mode will be an even bigger help, especially for folks that do prefer that display mode.
Assignee | ||
Comment 13•7 years ago
|
||
Waiting for talos results before requesting review. Try push for talos: Baseline: https://tbpl.mozilla.org/?tree=Try&rev=f62367b7e349 v.1: https://tbpl.mozilla.org/?tree=Try&rev=e5d8a516209f http://compare-talos.mattn.ca/?oldRevs=f62367b7e349&newRev=e5d8a516209f&submit=true
Attachment #8363689 -
Attachment is obsolete: true
Assignee | ||
Comment 14•7 years ago
|
||
Comment on attachment 8386456 [details] [diff] [review] v.1 Use a clip-path on tab-background-middle Review of attachment 8386456 [details] [diff] [review]: ----------------------------------------------------------------- Still waiting for some retriggers to come in but this seems okay so far.
Attachment #8386456 -
Flags: review?(gijskruitbosch+bugs)
Comment 15•7 years ago
|
||
Comment on attachment 8386456 [details] [diff] [review] v.1 Use a clip-path on tab-background-middle Review of attachment 8386456 [details] [diff] [review]: ----------------------------------------------------------------- Sweet!
Attachment #8386456 -
Flags: review?(gijskruitbosch+bugs) → review+
Assignee | ||
Comment 16•7 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/5bb78bdc6c5c
Whiteboard: [Australis:P3+] → [Australis:P3+][fixed-in-fx-team]
Comment 18•7 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5bb78bdc6c5c
Status: ASSIGNED → RESOLVED
Closed: 8 years ago → 7 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P3+][fixed-in-fx-team] → [Australis:P3+]
Target Milestone: --- → Firefox 30
Assignee | ||
Comment 19•7 years ago
|
||
Comment on attachment 8386456 [details] [diff] [review] v.1 Use a clip-path on tab-background-middle [Approval Request Comment] Bug caused by (feature/regressing bug #): Tabs in titlebar User impact if declined: Hard to drag the window above background tabs without accidentally dragging a tab when tabs are in the titlebar. Testing completed (on m-c, etc.): m-c and UX approved (phlsa) Risk to taking this patch (and alternatives if risky): Low risk. Potential for perf impact but it was negligible on m-c. String or IDL/UUID changes made by this patch: None
Attachment #8386456 -
Flags: ui-review+
Attachment #8386456 -
Flags: approval-mozilla-aurora?
Updated•7 years ago
|
status-firefox29:
--- → affected
status-firefox30:
--- → fixed
Updated•7 years ago
|
Attachment #8386456 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•7 years ago
|
Comment 21•7 years ago
|
||
Thank you for working on this! The draggable area is still a bit too small for my taste, so I reactivated the titlebar. However, on OSX I thought I would find the show/hide option in the View-Application Menu. I didn't expect to find it in the bottom-left corner of the customization window (I didn't know this button existed until I read the comments of this bug report).
Comment 22•7 years ago
|
||
(In reply to arminwagner2008 from comment #21) > Thank you for working on this! > > The draggable area is still a bit too small for my taste, so I reactivated > the titlebar. However, on OSX I thought I would find the show/hide option in > the View-Application Menu. I didn't expect to find it in the bottom-left > corner of the customization window (I didn't know this button existed until > I read the comments of this bug report). I do agree that this option should be listed in the main menu bar somewhere, probably in the View menu.
Comment 23•7 years ago
|
||
(In reply to Eric Shepherd [:sheppy] from comment #22) > (In reply to arminwagner2008 from comment #21) > > Thank you for working on this! > > > > The draggable area is still a bit too small for my taste, so I reactivated > > the titlebar. However, on OSX I thought I would find the show/hide option in > > the View-Application Menu. I didn't expect to find it in the bottom-left > > corner of the customization window (I didn't know this button existed until > > I read the comments of this bug report). > > I do agree that this option should be listed in the main menu bar somewhere, > probably in the View menu. Please file a new bug instead of "me too" ing in here.
You need to log in
before you can comment on or make changes to this bug.
Description
•