294852 - Canvas is too easily selected.

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Martijn Wargers (dead)]

See url testcase.
With just mousedown, without moving the mouse, the canvas element gets selected. 
Isn't that a bit too soon? 
I would at least expect that a mousedown and a bit of mousemovement would be
necessary to trigger it's selection.

Comment 1

[Peter van der Woude [:Peter6]]

*** Bug 296624 has been marked as a duplicate of this bug. ***

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Our current code for handling this is wonky.  The reason images don't get
selected on a single click is because they're draggable, indicated by
nsContentUtils::ContentIsDraggable at
http://lxr.mozilla.org/seamonkey/source/content/base/public/nsContentUtils.h#391
.  This gets called by nsFrame::HandlePress at
http://lxr.mozilla.org/seamonkey/source/layout/generic/nsFrame.cpp#1302 .

Canvas isn't really draggable in the same sense images and links are; I think
the simplest solution here is to just never render the canvas as selected, even
if it may actually be selected.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

The other solution here would be to add a function PRBool
nsContentUtils::SingleClickSelects() and check that as well as
nsContentUtils::IsDraggable(). The downside of this approach is that I think
that we'd start getting drag feedback on canvases, which is bad because a canvas
will refuse to drag anywhere (we can't even copy it yet!).

If we decide that canvas shouldn't be selectable, we could probably just give it
a -moz-user-select: none; style somewhere...

Comment 4

[Caleb]

Requesting 1.8b4 blocking since this bug really makes canvas objects look bad
when clicking on them.

Comment 5

[Martijn Wargers (dead)]

Attachment: userselect patch

So just do something like this, for the moment?

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 189955 [details] [diff] [review]
userselect patch

I'd say yes; r=vladimir -- but should get sr from someone more in touch with
html.css.  I have a patch that does much the same at the frame C++ level, but
this is better since it lets people override it in content CSS.

Comment 7

[Caleb]

(In reply to comment #6)
> (From update of attachment 189955 [details] [diff] [review] [edit])
> I'd say yes; r=vladimir -- but should get sr from someone more in touch with
> html.css.  I have a patch that does much the same at the frame C++ level, but
> this is better since it lets people override it in content CSS.
> 

Vlad, is there a reason why the canvas element should show this behaviour? You
cannot select SVG the same way, and you shouldn't have to because it makes
interactive conent look bad.

I think it should be fixed in C++, but it's your call.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 189955 [details] [diff] [review]
userselect patch

Doing it this way is better, because this also disables drag feedback from the
canvas element.  Disabling selection rendering in C++ would also require
hacking in nsFrame or nsContentUtils to disable dragging.

Comment 9

[Grant Wohl]

(In reply to comment #2)
> Canvas isn't really draggable in the same sense images and links are; I think
> the simplest solution here is to just never render the canvas as selected, even
> if it may actually be selected.
I disagree. Although the canvas itself isn't draggable, its alternate content
(provided within the canvas tag) is draggable. So if you have alternate text
within the canvas tag, the userselect patch makes it very hard to drag that text
to, for example, the search box.