Click-and-drag in interactive SVG document sometimes switches to external "mouse-dragging-object" mode

RESOLVED INVALID

Status

()

Core
SVG
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

({regression})

Trunk
x86
Linux
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

8 years ago
Created attachment 409457 [details]
testcase 1

STR:
 1. Load URL or attached testcase
 2. Click and drag a blue circle. (URL has 2 of them, testcase has 1)

EXPECTED RESULTS:
 Circle is naturally draggable by mouse. (due to onmousedown / onmousemove / onmouseup handlers in script)

ACTUAL RESULTS:
  Most of the times that I click and drag a circle, I get a brief bit of circle-dragging -- but then, the cursor changes to a "hand-dragging-a-document" cursor, and the circle gets left behind.


I get EXPECTED RESULTS with Firefox 3.0.16pre, and ACTUAL RESULTS with mozilla-central nightlies.

Build IDs:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.16pre) Gecko/2009103004 GranParadiso/3.0.16pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20091030 Minefield/3.7a1pre
(Reporter)

Updated

8 years ago
Summary: Click-and-drag in interactive SVG document sometimes triggers "mouse-dragging-object" event → Click-and-drag in interactive SVG document sometimes switches to external "mouse-dragging-object" mode
(Reporter)

Comment 1

8 years ago
NOTE: I've noticed that, in my mozilla-central nightly, it seems like I can avoid the problem by clicking and dragging on the background, in between my drags of the circle.

Comment 2

8 years ago
Any idea when this regressed?
Keywords: regressionwindow-wanted

Comment 3

8 years ago
I'm facing this bug, too.

Here you can find a complete description: http://groups.google.com/group/mozilla.dev.tech.svg/browse_thread/thread/59618c94f21e4799#

Giorgio

Comment 4

8 years ago
Created attachment 409521 [details]
Any better for you?

Comment 5

8 years ago
Is my version an improvement or not?
(Reporter)

Comment 6

8 years ago
Yes, for me it is!  I tried your testcase for a minute or two, and I didn't hit the problem at all when dragging the circle.  I did, however, get it once or twice when dragging the background.

Comment 7

8 years ago
You can experiment to see whether it's the return false or evt.preventDefault() or both. I think I also read somewhere about some IE method that has been implemented quite recently about doing something in an event handler to make sure things keep going to the element you want them to go to. I imagine that's trunk only but I can't find the article to confirm that it would be relevant nor can I remember the syntax :-(

Comment 8

8 years ago
This solution preventDefault + return false solved also my problem!

Thank you very much!
Giorgio

Comment 9

8 years ago
(In reply to comment #6)
> Yes, for me it is!  I tried your testcase for a minute or two, and I didn't hit
> the problem at all when dragging the circle.  I did, however, get it once or
> twice when dragging the background.

      function drag(evt) {
        if (!dragging)
          return;

Maybe you just need to add the magic preventDefault/return false foo to this bit too where I missed it out.

Comment 10

8 years ago
Er... if the testcase wasn't canceling the events, then this seems to be invalid, no?
(Reporter)

Comment 11

8 years ago
If this is just the fault of the testcase not canceling events, then I'm happy to have this resolved as invalid.

However, I'm still a little confused about the following:
  (A) the testcase works in Firefox 3.0.x, as noted in comment 0
  (B) it sounds like the testcase works fine in non-Linux operating systems (at least, birtles was unable to reproduce as of a few days ago on whatever OS he's running, and it sounds like Robert Longson was unable to reproduce on Windows)

Does anyone know why those would be the case?  i.e. if the buggy behavior is what's expected, given the testcase's lack of event-canceling, why don't we get broken behavior in cases (A) and (B) above?

Comment 12

8 years ago
(A) would be helped most by hunting down the regression range.
(B) is odd, yes.

Comment 13

8 years ago
(In reply to comment #11)
> If this is just the fault of the testcase not canceling events, then I'm happy
> to have this resolved as invalid.
> 
> However, I'm still a little confused about the following:
>   (A) the testcase works in Firefox 3.0.x, as noted in comment 0
>   (B) it sounds like the testcase works fine in non-Linux operating systems (at
> least, birtles was unable to reproduce as of a few days ago on whatever OS he's
> running, and it sounds like Robert Longson was unable to reproduce on Windows)
> 

I didn't get a hand dragging a document but I did get a circle with a line through it at 45 degrees to the horizontal sometimes. That's the Windows "you can't do this" cursor.
(Reporter)

Comment 14

8 years ago
(In reply to comment #12)
> (A) would be helped most by hunting down the regression range.

Using "testcase 1", this regressed between these nighlies:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080825020949 Minefield/3.1a2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a2pre) Gecko/20080826020557 Minefield/3.1a2pre

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-25+00%3A00%3A00&enddate=2008-08-26+02%3A30%3A00

This window includes http://hg.mozilla.org/mozilla-central/rev/6958399a2eb1 (Bug 356295), "Implement HTML5 drag-drop API", which seems like the most likely candidate for having caused this change in behavior.

And from comment 13, it sounds like this isn't Linux-only after all.
Keywords: regressionwindow-wanted
(Reporter)

Comment 15

8 years ago
Created attachment 409615 [details]
testcase 1 + fix (added one "evt.preventDefault")

(In reply to comment #7)
> You can experiment to see whether it's the return false or evt.preventDefault()
> or both.

In a mozilla-central nightly, this becomes fixed by adding a single "evt.preventDefault();" in dragStart.
(Reporter)

Comment 16

8 years ago
It sounds like even before Bug 356295 landed, the drag event would bubble up, but nothing was there to handle it.  After Bug 356295 landed, the event started being handled by the higher level drag-drop API.  So, as Boris suggests in comment 10, this "bug" is just a case where the testcase's event-handler needs to prevent the event from bubbling up.

Resolving as INVALID.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
I've updated the test case at the URL for this bug (http://brian.sol1.net/svg/tests/keysplines.html) to include this fix.
So it's perfectly valid to not send any mousemove events and a corresponding mouseup after a mousedown event, unless the user calls preventDefault() to stop the UA going into...what?..."drag/drop mode"? Surely this is a breaking change in behavior.

Comment 19

8 years ago
Neil, see comment 18?
> So it's perfectly valid to not send any mousemove events and a corresponding
> mouseup after a mousedown event, unless the user calls preventDefault() to stop
> the UA going into...what?..."drag/drop mode"? Surely this is a breaking change
> in behavior.

It isn't no. If the user agent implements some default behaviour on some event, not calling preventDefault should still invoke that behaviour, whatever it may be.

In this case, what's happening is that clicking on the svg element causes it to become part of the selection. The default user agent behaviour for dragging selections is to drag them.

I can't speak as to why clicking an svg element selects it; as an aside, using -moz-user-select: none on the svg element 'fixes' the issue as well.

Either the svg element shouldn't be selected in the first place, or the drag handling shouldn't be dragging selected svg elements.

Comment 21

8 years ago
(In reply to comment #20)

> In this case, what's happening is that clicking on the svg element causes it to
> become part of the selection. The default user agent behaviour for dragging
> selections is to drag them.

If that's what happens to html elements then it should happen for SVG elements too shouldn't it?

> Either the svg element shouldn't be selected in the first place, or the drag
> handling shouldn't be dragging selected svg elements.

We do want to implement copying of SVG text to the clipboard for instance at some point. We may even wish to allow copying the whole SVG graphic to the clipboard eventually. That suggests the former option is out.
I don't think it makes much sense for SVG elements in general to be selectable by default. Short term definitely not, since we have no good mechanism to allow the user to make a useful selection, or to provide visual feedback on what is selected, or to even allow the user to do something with a selection.

Longer term I'd like to see a mechanism for authors to mark parts of the document as some sort of logical group that makes sense to select as a whole, and possibly some mechanism for selecting a subregion of an SVG for copying. Text should also be selectable as Robert says.
It also seems strange that single click causes selection. That doesn't happen in HTML, right? You need to click and drag or click multiple times to create a selection.

Comment 24

8 years ago
A short term hack might be to set -moz-user-select: none for svg elements in svg.css
You need to log in before you can comment on or make changes to this bug.