Last Comment Bug 525591 - Click-and-drag in interactive SVG document sometimes switches to external "mouse-dragging-object" mode
: Click-and-drag in interactive SVG document sometimes switches to external "mo...
Status: RESOLVED INVALID
: regression
Product: Core
Classification: Components
Component: SVG (show other bugs)
: Trunk
: x86 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://brian.sol1.net/svg/tests/keysp...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-30 17:46 PDT by Daniel Holbert [:dholbert]
Modified: 2009-11-03 14:49 PST (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase 1 (1.04 KB, image/svg+xml)
2009-10-30 17:46 PDT, Daniel Holbert [:dholbert]
no flags Details
Any better for you? (1.20 KB, image/svg+xml)
2009-10-31 10:05 PDT, Robert Longson
no flags Details
testcase 1 + fix (added one "evt.preventDefault") (1.07 KB, image/svg+xml)
2009-11-01 12:05 PST, Daniel Holbert [:dholbert]
no flags Details

Description Daniel Holbert [:dholbert] 2009-10-30 17:46:10 PDT
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
Comment 1 Daniel Holbert [:dholbert] 2009-10-30 17:48:08 PDT
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 [:bz] (still a bit busy) 2009-10-31 06:44:02 PDT
Any idea when this regressed?
Comment 3 Giorgio Stefanoni 2009-10-31 06:51:43 PDT
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 2009-10-31 10:05:13 PDT
Created attachment 409521 [details]
Any better for you?
Comment 5 Robert Longson 2009-10-31 10:05:46 PDT
Is my version an improvement or not?
Comment 6 Daniel Holbert [:dholbert] 2009-10-31 10:21:12 PDT
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 2009-10-31 11:03:33 PDT
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 2009-10-31 11:30:13 PDT
This solution preventDefault + return false solved also my problem!

Thank you very much!
Giorgio
Comment 9 Robert Longson 2009-10-31 15:34:07 PDT
(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 [:bz] (still a bit busy) 2009-10-31 17:01:06 PDT
Er... if the testcase wasn't canceling the events, then this seems to be invalid, no?
Comment 11 Daniel Holbert [:dholbert] 2009-10-31 17:20:34 PDT
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 [:bz] (still a bit busy) 2009-10-31 18:57:13 PDT
(A) would be helped most by hunting down the regression range.
(B) is odd, yes.
Comment 13 Robert Longson 2009-11-01 01:30:46 PDT
(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] 2009-11-01 12:03:11 PST
(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] 2009-11-01 12:05:44 PST
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.
Comment 16 Daniel Holbert [:dholbert] 2009-11-01 12:14:34 PST
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) 2009-11-01 13:12:30 PST
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] (back in October - email directly if necessary) 2009-11-03 06:51:37 PST
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 [:bz] (still a bit busy) 2009-11-03 08:24:24 PST
Neil, see comment 18?
Comment 20 Neil Deakin (away until Oct 3) 2009-11-03 09:11:57 PST
> 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 2009-11-03 09:49:50 PST
(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] (back in October - email directly if necessary) 2009-11-03 14:42:31 PST
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] (back in October - email directly if necessary) 2009-11-03 14:46:51 PST
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 2009-11-03 14:49:24 PST
A short term hack might be to set -moz-user-select: none for svg elements in svg.css

Note You need to log in before you can comment on or make changes to this bug.