Closed Bug 525591 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: dholbert, Unassigned)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

Attached image 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
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
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.
Any idea when this regressed?
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
Is my version an improvement or not?
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.
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 :-(
This solution preventDefault + return false solved also my problem!

Thank you very much!
Giorgio
(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.
Er... if the testcase wasn't canceling the events, then this seems to be invalid, no?
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?
(A) would be helped most by hunting down the regression range.
(B) is odd, yes.
(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.
(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.
(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.
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
Closed: 10 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.
> 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.
(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.
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.