Canvas is too easily selected.

RESOLVED FIXED

Status

()

Core
Canvas: 2D
RESOLVED FIXED
13 years ago
9 years ago

People

(Reporter: Martijn Wargers (dead), Unassigned)

Tracking

(Depends on: 1 bug, {testcase})

Trunk
x86
Windows XP
testcase
Points:
---
Bug Flags:
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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.
*** Bug 296624 has been marked as a duplicate of this bug. ***
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.
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

13 years ago
Requesting 1.8b4 blocking since this bug really makes canvas objects look bad
when clicking on them.
Flags: blocking1.8b4?

Updated

13 years ago
Flags: blocking1.8b4? → blocking1.8b4-
(Reporter)

Comment 5

13 years ago
Created attachment 189955 [details] [diff] [review]
userselect patch

So just do something like this, for the moment?
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.
Attachment #189955 - Flags: review+

Comment 7

13 years ago
(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 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.
Attachment #189955 - Flags: approval1.8b4?

Updated

13 years ago
Attachment #189955 - Flags: approval1.8b4? → approval1.8b4+
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 9

13 years ago
(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.
(Reporter)

Updated

9 years ago
Depends on: 497868
You need to log in before you can comment on or make changes to this bug.