Closed
Bug 294852
Opened 19 years ago
Closed 19 years ago
Canvas is too easily selected.
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: testcase)
Attachments
(1 file)
1.05 KB,
patch
|
vlad
:
review+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
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•19 years ago
|
||
*** 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.
Comment 3•19 years ago
|
||
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?
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4-
Reporter | ||
Comment 5•19 years ago
|
||
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?
Updated•19 years ago
|
Attachment #189955 -
Flags: approval1.8b4? → approval1.8b4+
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 9•19 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.
You need to log in
before you can comment on or make changes to this bug.
Description
•