Closed Bug 294852 Opened 19 years ago Closed 19 years ago

Canvas is too easily selected.

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: testcase)

Attachments

(1 file)

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...
Requesting 1.8b4 blocking since this bug really makes canvas objects look bad
when clicking on them.
Flags: blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4-
Attached patch userselect patchSplinter Review
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+
(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?
Attachment #189955 - Flags: approval1.8b4? → approval1.8b4+
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(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.
Depends on: 497868
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: