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

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: 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

Comment 1

[Daniel Holbert [:dholbert]]

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

[Boris Zbarsky [:bzbarsky]]

Any idea when this regressed?

Comment 3

[Giorgio Stefanoni]

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

[Robert Longson [:longsonr]]

Attachment: Any better for you?

Comment 5

[Robert Longson [:longsonr]]

Is my version an improvement or not?

Comment 6

[Daniel Holbert [:dholbert]]

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

[Robert Longson [:longsonr]]

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

[Giorgio Stefanoni]

This solution preventDefault + return false solved also my problem!

Thank you very much!
Giorgio

Comment 9

[Robert Longson [:longsonr]]

(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

[Boris Zbarsky [:bzbarsky]]

Er... if the testcase wasn't canceling the events, then this seems to be invalid, no?

Comment 11

[Daniel Holbert [:dholbert]]

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

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Robert Longson [:longsonr]]

(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.

Comment 14

[Daniel Holbert [:dholbert]]

(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.

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: 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.

Comment 16

[Daniel Holbert [:dholbert]]

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.

Comment 17

[Brian Birtles (:birtles)]

I've updated the test case at the URL for this bug (http://brian.sol1.net/svg/tests/keysplines.html) to include this fix.

Comment 18

[Jonathan Watt [:jwatt]]

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

[Boris Zbarsky [:bzbarsky]]

Neil, see comment 18?

Comment 20

[Neil Deakin]

> 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

[Robert Longson [:longsonr]]

(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.

Comment 22

[Jonathan Watt [:jwatt]]

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.

Comment 23

[Jonathan Watt [:jwatt]]

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

[Robert Longson [:longsonr]]

A short term hack might be to set -moz-user-select: none for svg elements in svg.css