386574 - Close tab too close to favicon causing drag'n'drop problems

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Drag & Drop, defect)

Description

[sacrat]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ru; rv:1.8.1.4) Gecko/20070509 Camino/1.5 (MultiLang)
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ru; rv:1.8.1.4) Gecko/20070509 Camino/1.5 (MultiLang)

In current Camino builds close tab button is leftmost. At the same time drag'n'drop operations (site bookmarking) are done by user dragging tab's favicon, located next to "close".
Such behavior often leads to closing tabs by accident when attempting to bookmark one.


Reproducible: Always

Steps to Reproduce:
1.Open tab
2.Try to catch favicon and drag site to the bookmark bar in order to bookmark
There's a good chance of hitting "close" instead of clicking favicon.


Expected Results:  
Possible solution: make the whole tab draggable.
For example, boorkmarks are draggable by text parts as well.

Comment 1

[Chris Lawson (gone)]

This leads to a very sticky situation when you try to figure out what part of the tab serves as a handle for dragging the tab itself, though.

Personally, I say we WONTFIX this based solely on the fact that most users seem to be able to achieve this action without any issues. (Sorry, but that's the reality of it -- this is the only bug we've ever had filed on this in my memory, and we've had zero feedback on it.)

Comment 2

[Derek Schrock]

Also to note:
Would it conflict with rearranging tabs?
https://bugzilla.mozilla.org/show_bug.cgi?id=160720

If the bug does stay alive
Severity: normal -> enhancement

Comment 3

[sacrat]

Sorry, Chris, but I just don't see the problem with handles. In 1.5 you're
unable to move tabs and even if you can...

While tabs are being dragged and dropped inside the Tab location area (don't
know exact English name) it's rearranging. If dropping tabs off the area to a
Shortcut bar – it's creating shortcuts... Am I missing something?

The problem with feedback might be simple: people, mostly affected by the issue
often belong to novice/elder groups and prefer not to mess with Bugzilla (the
only reason I'm using Bugzilla is that I had to learn using it on my work), so
you'll unlikely ever get written reports from these users.

I'm just pointing to a potential accessibility/UI-related problem which has
lots of possible solutions. As a user, relatively new to Macs I've seen people
clicking "close" many times just because this area is safe for them in
Linux/Windows/etc. So we may either need to reloccate the "close" to the right
section of the tab (Firefox/Opera solution) or try to look for some ways to
reduce the chance of losing data because of accidental clicks on the button.

I might be wrong, but being a UI designer I see nothing good in having two
small controls, one of which is destructive be placed side by side on the area
widely operated by users.

Just my opinion, though.

Comment 4

[Stuart Morgan]

(In reply to comment #3)
> While tabs are being dragged and dropped inside the Tab location area (don't
> know exact English name) it's rearranging. If dropping tabs off the area to a
> Shortcut bar – it's creating shortcuts

That's an interesting idea, and one that I don't think has been discussed. I think we'd need to actually try it out both ways once tab drag-and-drop is implemented, and see which works better. It's certainly worth trying.

> The problem with feedback might be simple: people, mostly affected by the issue
> often belong to novice/elder groups and prefer not to mess with Bugzilla

We get a lot of email feedback from novice users. That doesn't mean that this isn't a legitimate concern that's worth discussing though.

> Linux/Windows/etc. So we may either need to reloccate the "close" to the right
> section of the tab (Firefox/Opera solution)

That's a very Windows-centric approach (which is probably why Firefox and Opera do it), and it's already been discussed and rejected.

> or try to look for some ways to reduce the chance of losing data
> because of accidental clicks on the button.

Bug 316458 would cover that.

Comment 5

[sacrat]

OK, I hope it turns into a worthy solution for future Camino versions.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This doesn't seem to have become a problem in practice, and we did discuss some of the drag source area issues when we implemented tab dragging, and we persisted with the current setup.

I'm not sure there's anything else to do here that not either been WONTFIXed, discussed and rejected, or covered by existing bugs.