Tab tear off cursor needs to be constant

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Core
Widget
P1
normal
VERIFIED FIXED
9 years ago
7 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

({dev-doc-complete, verified1.9.1})

Trunk
mozilla1.9.2a1
dev-doc-complete, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +
in-litmus +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 8 obsolete attachments)

(Assignee)

Description

9 years ago
nsNativeDragSource can handle setting the cursor in its GiveFeedback method for the special case where we are dragging a tab.
(Assignee)

Comment 1

9 years ago
Created attachment 346324 [details] [diff] [review]
GiveFeedback patch v.1
(Assignee)

Updated

9 years ago
Attachment #346324 - Flags: review?(emaijala)
(Assignee)

Comment 2

9 years ago
Comment on attachment 346324 [details] [diff] [review]
GiveFeedback patch v.1

Pretty straight forward, the patch passes in a flag when the nsNativeDragSource object is created. Within that, we set our own cursor when dragging a tab and do the default for everything else.
(Assignee)

Comment 3

9 years ago
One update, the delete object call isn't needed for shared cursors, so in the final I'll be plucking that out of the patch.
What special behaviour is this allowing? It doesn't seem like we should be hardcoding special cases like this.
(Assignee)

Comment 5

9 years ago
(In reply to comment #4)
> What special behaviour is this allowing? It doesn't seem like we should be
> hardcoding special cases like this.

Sorry I should have clarified a bit more. There was a 3.1 feature request for drag tab to new window functionality. (bug 225680) Mano got that working using some script wizardry, but there was a problem on win32 with cursors, since the cursor displayed is usually controlled by the system based on the underlying window and the contents of the drag.  The idea was that when dragging a tab, the cursor should remain an arrow at all times so as not to confuse users. The only way to get that to work was to detect a tab drag in this code, and control the cursors for that special case manually. Hence this patch.

Comment 6

9 years ago
Comment on attachment 346324 [details] [diff] [review]
GiveFeedback patch v.1

Is it ok to drop a tab anywhere? I don't think showing a cursor is appropriate if the drop target doesn't actually accept the tab. Do I need to apply the patch from bug 225680 to test this or what? If so, I'd rather have that committed before letting this in.
(Assignee)

Comment 7

9 years ago
(In reply to comment #6)
> (From update of attachment 346324 [details] [diff] [review])
> Is it ok to drop a tab anywhere? I don't think showing a cursor is appropriate
> if the drop target doesn't actually accept the tab. Do I need to apply the

Yes, you can drop it anywhere and it'll create a new window. This was supposed to mimic functionality on osx. 

> patch from bug 225680 to test this or what? If so, I'd rather have that
> committed before letting this in.

Yes, it requires 225680.
(In reply to comment #5)
> The idea was that when dragging a tab, the cursor should remain an arrow at all times so as not to confuse users. The only way to get that to work was to detect a tab drag in this code, and control the cursors for that special case manually. 

So why does it require hardcoding? I'd think there might be other cases where this would be useful, so I'd go with adding an API to disable the cursor changing.
(Assignee)

Comment 9

9 years ago
Comment on attachment 346324 [details] [diff] [review]
GiveFeedback patch v.1

update coming up..
Attachment #346324 - Attachment is obsolete: true
Attachment #346324 - Flags: review?(emaijala)
(Assignee)

Comment 10

9 years ago
(In reply to comment #8)
> (In reply to comment #5)
> > The idea was that when dragging a tab, the cursor should remain an arrow at all times so as not to confuse users. The only way to get that to work was to detect a tab drag in this code, and control the cursors for that special case manually. 
> 
> So why does it require hardcoding? I'd think there might be other cases where
> this would be useful, so I'd go with adding an API to disable the cursor
> changing.

When you suggest an api, were you seeing it on something like the native data object or all the way up on something like nsIDOMDataTransfer? I'm curious if you were thinking we need to expose something people can access from script.
(Assignee)

Updated

9 years ago
Duplicate of this bug: 465153
(In reply to comment #10)

> When you suggest an api, were you seeing it on something like the native data
> object or all the way up on something like nsIDOMDataTransfer? I'm curious if
> you were thinking we need to expose something people can access from script.

The data transfer. In the future, this may be the only public api that is available.

Is the idea here to prevent the cursor feedback always, or just when the cursor is over something that isn't Firefox, or just on the desktop, or any area that doesn't accept drops?

Also, the patch here is Windows specific, whereas this would need to be implemented all platforms. (The duplicate is actually for all platforms).

For Cocoa, there's a draggingSourceOperationMaskForLocal(sameApp) method that can set the allowed drop operations differently for same-vs-different app, so we should find an api that meets the needs here plus can work on all platforms.
(Assignee)

Updated

9 years ago
Summary: Add tab drag cursor support to nsNativeDragSource's GiveFeedback → Tab tear off cursor needs to be constant
(Assignee)

Comment 13

9 years ago
(In reply to comment #12)
> (In reply to comment #10)
> 
> > When you suggest an api, were you seeing it on something like the native data
> > object or all the way up on something like nsIDOMDataTransfer? I'm curious if
> > you were thinking we need to expose something people can access from script.
> 
> The data transfer. In the future, this may be the only public api that is
> available.
> 
> Is the idea here to prevent the cursor feedback always, or just when the cursor
> is over something that isn't Firefox, or just on the desktop, or any area that
> doesn't accept drops?
> 

It should be constant - an arrow for example, throughout the entire drag operation.
(Assignee)

Updated

9 years ago
OS: Windows XP → All

Comment 14

9 years ago
A duplicate bug had request for blocking release, this bug may as well inherit the request.
Flags: blocking1.9.1?
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Jim, any update
(Assignee)

Comment 16

9 years ago
(In reply to comment #15)
> Jim, any update

Yes I was derailed from this for a bit but am back on it this week. Hope to have something by mon.
Assignee: jmathies → nobody
Component: Widget: Win32 → Widget
QA Contact: win32 → general
Hardware: PC → All
(Assignee)

Updated

9 years ago
Assignee: nobody → jmathies
(Assignee)

Comment 17

9 years ago
Created attachment 356554 [details] [diff] [review]
drag cursor behavior patch v.1
(Assignee)

Comment 18

9 years ago
Comment on attachment 356554 [details] [diff] [review]
drag cursor behavior patch v.1

Hopfully we can get this in before the freeze.
Attachment #356554 - Flags: review?(enndeakin)
Comment on attachment 356554 [details] [diff] [review]
drag cursor behavior patch v.1

>+  const short DRAG_CURSOR_NATIVE = 0;
>+  const short DRAG_CURSOR_ARROW = 1;
>+
>+  attribute short mozDragCursorBehavior;

I think this would be a better as a string than an integer, allowing the same values as the css cursor property. This would make it more forward-compatible in that we could allow other cursors in the future, and not have a different means of specifying cursors.

Also, the UUID defined for the interface should be changed.

Otherwise, this is OK.
(Assignee)

Comment 20

9 years ago
(In reply to comment #19)
> (From update of attachment 356554 [details] [diff] [review])
> >+  const short DRAG_CURSOR_NATIVE = 0;
> >+  const short DRAG_CURSOR_ARROW = 1;
> >+
> >+  attribute short mozDragCursorBehavior;
> 
> I think this would be a better as a string than an integer, allowing the same
> values as the css cursor property. This would make it more forward-compatible
> in that we could allow other cursors in the future, and not have a different
> means of specifying cursors.
> 
> Also, the UUID defined for the interface should be changed.
> 
> Otherwise, this is OK.

nsIDOMNSDataTransfer though also provides int versions of drop effect. I can work entirely with strings but them I'll need copies of those in the native drag source code. Would it be alright to create the string attribute but also keep the int version (marked as no script as with the others), and move the constants into nsIDragService?
(Assignee)

Comment 21

9 years ago
Ok, after some discussion on irc with Neil, we're going with a simple binary switch, a string attribute, and no drag constants. Strings are still up in the air a bit but for now it will be 'auto' & 'arrow'.
(Assignee)

Comment 22

9 years ago
(In reply to comment #21)
> Ok, after some discussion on irc with Neil, we're going with a simple binary
> switch, a string attribute, and no drag constants. Strings are still up in the
> air a bit but for now it will be 'auto' & 'arrow'.

Actually, I think I'll go with 'auto' and 'locked', and touch up the method names to reflect the more generic switch.
(Assignee)

Comment 23

9 years ago
Created attachment 357031 [details] [diff] [review]
drag cursor behavior patch v.2
Attachment #356554 - Attachment is obsolete: true
Attachment #356554 - Flags: review?(enndeakin)
(Assignee)

Updated

9 years ago
Attachment #357031 - Attachment is patch: true
Attachment #357031 - Flags: review?(enndeakin)
(Assignee)

Updated

9 years ago
Attachment #357031 - Flags: superreview?(roc)
(Assignee)

Comment 24

9 years ago
Comment on attachment 357031 [details] [diff] [review]
drag cursor behavior patch v.2

requesting an sr on the way this attrib. was implemented.
Why don't we just call it mozCursor and let it take a CSS3 cursor value, as Neil suggested? For now we could just support "auto" (not locked) and "default" (locked). I don't think we need "locked" as a value.
(Assignee)

Updated

9 years ago
Attachment #357031 - Flags: superreview?(roc)
Attachment #357031 - Flags: review?(enndeakin)
So, fwiw, ideally I would like to be able to _alter_ the cursor on dragover and on dragleave.
(Assignee)

Comment 27

9 years ago
(In reply to comment #26)
> So, fwiw, ideally I would like to be able to _alter_ the cursor on dragover and
> on dragleave.

Hmm, that's not the way this has shaped up. You'll be able to choose between keeping the cursor set (the set cursor is dependent on the os, on windows this will be an arrow) or falling back on default behavior where you don't have any control over it's state.
(Assignee)

Comment 28

9 years ago
Created attachment 357407 [details] [diff] [review]
drag cursor behavior patch v.3
Attachment #357031 - Attachment is obsolete: true
(Assignee)

Updated

9 years ago
Attachment #357407 - Flags: review?(enndeakin)
(In reply to comment #26)
> So, fwiw, ideally I would like to be able to _alter_ the cursor on dragover and
> on dragleave.

What do you want to change it to? If you mean just change to 'copy' or 'move', etc, then that should be happening automatically (although there's a bug on Mac for it not working there) 

Can we get some requirements here? If this patch doesn't do what is desired, we shouldn't be doing it.
(Assignee)

Comment 30

8 years ago
(In reply to comment #29)
> (In reply to comment #26)
> > So, fwiw, ideally I would like to be able to _alter_ the cursor on dragover and
> > on dragleave.
> 
> What do you want to change it to? If you mean just change to 'copy' or 'move',
> etc, then that should be happening automatically (although there's a bug on Mac
> for it not working there) 
> 
> Can we get some requirements here? If this patch doesn't do what is desired, we
> shouldn't be doing it.

The original requirement I had was to give us the ability enable/disable the native cursor changes for drag and drop. I think down the road, if there's a need, we could expand that to allow the setting of different cursors. I'm not aware of a need for that functionality at this point.

This came out of the tab drag stuff - on Windows when you drag a tab the cursor changes based on what the underlying window accepts based on the data in the drag object. Each window accepts different types of data so there were a lot of cursor changes as you moved the tab across the desktop. Originally we just wanted to stop that, and keep the cursor constant. Hence this patch and the first quick fix I posted a while back.

As far as I know we don't need to control the type of cursor, we just wanted to clean up the native cursor changes which are confusing to the user.
(Assignee)

Comment 31

8 years ago
Hey Mano, any feedback on this?
Whiteboard: [needs feedback mano]
Let me explain first the way things are implement right now

Case 1: Drop on "plan" browser chrome -> nothing happens, dropaction is none.
Case 2: Drop on text fields within the browser window, on the bookmarks toolbar and on other chrome elements -> as in Fx3 (not detach).
Case 3: Drop on content area -> detach - happens in the DROP event. dropaction is probably set to move (maybe link, but not to _none_)
Case 4: Drop outside the browser window -> If the dropaction is none (and that will always be the case once I remove the text/plain data), deatach happens on DRAGEND.

For first couple of cases, the automated behavior is desired, meaning either the move, copy, link or no-drop icon. For the other cases, It would be nice to set a custom icon for "detach" and not just the normal pointer.

Differentiating between the first case to the last case in the back-end seems wrong to me, and so is differentiating between the two other case. Thus, ideally, I would be able to set the cursor to either "auto" or a custom image in both the dragover and dragleave events.
Whiteboard: [needs feedback mano]
(Assignee)

Comment 33

8 years ago
Are we sure we want to be implementing custom drag cursors this close to 3.1? Maybe a better solution would be to stick with arrows for the 3.1 release and spin a mozCursor="custom" enhancement off for 3.2?
That's why I said "it would be nice". There will still be two modes: "auto" and "default-pointer", which may be set anytime during the drag operation.
(Assignee)

Comment 35

8 years ago
(In reply to comment #34)
> That's why I said "it would be nice". There will still be two modes: "auto" and
> "default-pointer", which may be set anytime during the drag operation.

Cool, I can split that off. Do you see any issues with the "drag cursor behavior patch v.3" patch as it stands now based on what you want to do?
As long as you can set mozCursor within both dragover and dragleave, it seems fine.
(Assignee)

Comment 37

8 years ago
(In reply to comment #36)
> As long as you can set mozCursor within both dragover and dragleave, it seems
> fine.

Hmm, then this isn't going to work then. I'll need to see if there's a way to get information to the nsNativeDragSource object during the drag operation. Currently this patch sets the value at the beginning of the drag.
(Assignee)

Updated

8 years ago
Attachment #357407 - Flags: review?(enndeakin)
Jim, what's up?
(Assignee)

Comment 39

8 years ago
(In reply to comment #38)
> Jim, what's up?

I haven't worked on this since that last patch I posted. I'll see what I can do this week.
(Assignee)

Updated

8 years ago
Attachment #357407 - Attachment is obsolete: true
If we're going to do this in 1.9.1, the api must land before b3.
(Assignee)

Comment 41

8 years ago
(In reply to comment #40)
> If we're going to do this in 1.9.1, the api must land before b3.

What is the rush for beta 3 if we are planning a beta 4 with other fixes 6 weeks out? I might be able to land this this week as I'm looking at it starting tomorrow, but if I don't make that I would think beta 4 would work just as well?
(Assignee)

Comment 42

8 years ago
Created attachment 365250 [details] [diff] [review]
 drag cursor behavior patch v.4

Ok, updated.
Attachment #365250 - Flags: review?(enndeakin)
Comment on attachment 365250 [details] [diff] [review]
 drag cursor behavior patch v.4

>+NS_IMETHODIMP
>+nsDOMDataTransfer::GetMozCursor(nsAString& aCursorState)
>+{
>+  if (!mCursorState)
>+    aCursorState.AssignASCII("auto");
>+  else
>+    aCursorState.AssignASCII("default");

Flip the two lines so you don't have to negate the condition.
 
>+NS_IMETHODIMP
>+nsDOMDataTransfer::SetMozCursor(const nsAString& aCursorState)
>+{
>+  if (aCursorState.EqualsASCII("default")) {
>+    // Lock the cursor to an arrow during the drag.
>+    mCursorState = PR_TRUE;
>+  }
>+

Here, you really want:

mCursorState = aCursorState.EqualsASCII("default");


+   *  auto - use default sytem behavior.

'system behaviour'


Is GiveFeedback called repeatedly during a drag? Does it matter that the cursor is being set every time?

Also, do we want to be able to change mozCursor during a drag, or just during dragstart?
(Assignee)

Comment 44

8 years ago
(In reply to comment #43)
> (From update of attachment 365250 [details] [diff] [review])
> >+NS_IMETHODIMP
> >+nsDOMDataTransfer::GetMozCursor(nsAString& aCursorState)
> >+{
> >+  if (!mCursorState)
> >+    aCursorState.AssignASCII("auto");
> >+  else
> >+    aCursorState.AssignASCII("default");
> 
> Flip the two lines so you don't have to negate the condition.
> 
> >+NS_IMETHODIMP
> >+nsDOMDataTransfer::SetMozCursor(const nsAString& aCursorState)
> >+{
> >+  if (aCursorState.EqualsASCII("default")) {
> >+    // Lock the cursor to an arrow during the drag.
> >+    mCursorState = PR_TRUE;
> >+  }
> >+
> 
> Here, you really want:
> 
> mCursorState = aCursorState.EqualsASCII("default");
> 
> 
> +   *  auto - use default sytem behavior.
> 
> 'system behaviour'
> 

will update.

> 
> Is GiveFeedback called repeatedly during a drag?

Yes, although I didn't notice any performance issues. We could resurrect the idea of an int property though to be safe.

> Does it matter that the cursor
> is being set every time?

That's the way you're supposed to do it.

> Also, do we want to be able to change mozCursor during a drag, or just during
> dragstart?

Asaf asked for dragover and dragleave so I think covering everything makes good sense.
Yes, although I didn't notice any performance issues. We could resurrect the
idea of an int property though to be safe.

No, if setting the cursor every time is correct, then just leave it as is.
(Assignee)

Comment 46

8 years ago
Created attachment 365527 [details] [diff] [review]
drag cursor behavior patch final
Attachment #365250 - Attachment is obsolete: true
Attachment #365527 - Flags: review?(enndeakin)
Attachment #365250 - Flags: review?(enndeakin)
Comment on attachment 365527 [details] [diff] [review]
drag cursor behavior patch final

>+   *  auto - use default sytem behaviour.

Actually, I meant to correct the word 'sytem'. But if you want to be more Canadian/British, go right ahead ;)
Attachment #365527 - Flags: review?(enndeakin) → review+
(Assignee)

Comment 48

8 years ago
(In reply to comment #47)
> (From update of attachment 365527 [details] [diff] [review])
> >+   *  auto - use default sytem behaviour.
> 
> Actually, I meant to correct the word 'sytem'. But if you want to be more
> Canadian/British, go right ahead ;)

Heh, I'll update it before I land.  :)
(Assignee)

Comment 49

8 years ago
Created attachment 365928 [details] [diff] [review]
checked in

mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/37207402f983
Attachment #365527 - Attachment is obsolete: true
Attachment #365928 - Flags: approval1.9.1?
Don't you need super-review for most of this patch?
SetMozCursor should probably throw on toolkit-widgets in which this behavior is not implemented. "probably", because I have no idea how are similar cases handled.
SetMozCursor isn't in platform specific code. The documentation for mozCursor should probably just say the actual cursor used is platform dependant, or that the property has no effect on some platforms.
(Assignee)

Comment 53

8 years ago
(In reply to comment #50)
> Don't you need super-review for most of this patch?

I wasn't aware that I did but I can certainly get one and deal with it if I've miss stepped.
Yeah, this patch should have been super-reviewed. Perhaps roc can sr it after the fact?

Also, this should be marked FIXED now that it's checked in on trunk, no?
(Assignee)

Updated

8 years ago
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Attachment #365527 - Flags: superreview?(roc)
(Assignee)

Comment 55

8 years ago
Comment on attachment 365527 [details] [diff] [review]
drag cursor behavior patch final

Roc, this landed early which was was my fault. I can pull it back out if need be (although it went through quite a bit of discussion before neil gave it the ok). Can you look over what landed and let me know if I need to pull it and fix something or just update what's already landed?
(Assignee)

Comment 56

8 years ago
Also, I need to figure out if this needs to be split off into other platform bugs. From my understanding the cursor issue isn't present on osx but as mentioned previously we might want some sort of functionality, even a simple throw, on osx. As for linux I'm unsure of what's needed there. Both bugs related to this were opened due to windows issues.
+  // Indicates the behavior of the cursor during drag operations
+  PRPackedBool mCursorState;

This comment, and the variable name, aren't very helpful. It needs to say what the possible states actually mean.

+  if (mCursorState)
+    aCursorState.AssignASCII("default");
+  else
+    aCursorState.AssignASCII("auto");

These should be AssignLiteral, and also have {} around them.

+  mCursorState = aCursorState.EqualsASCII("default");

EqualsLiteral

+  /**
+   * Sets the drag cursor state. Primarily used to control the cursor during
+   * tab drags, but could be expanded to other uses.
+   *
+   * Possible values:
+   *  auto - use default system behavior.
+   *  default - set the cursor to an arrow during the drag operation.
+   */

Document that other values are treated as "auto".

+    if (cursor.EqualsASCII("default")) {

EqualsLiteral

You can fix these as a separate checkin on top of what you already landed.
(Assignee)

Comment 58

8 years ago
Created attachment 366370 [details] [diff] [review]
touchup patch
(Assignee)

Updated

8 years ago
Attachment #365527 - Flags: superreview?(roc)
(Assignee)

Updated

8 years ago
Attachment #366370 - Flags: superreview?(roc)
Comment on attachment 366370 [details] [diff] [review]
touchup patch

+  }
+  else {

One line.
Attachment #366370 - Flags: superreview?(roc) → superreview+
Reopening while it is not completely fixed...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 61

8 years ago
Created attachment 366434 [details] [diff] [review]
touchup patch
Attachment #366370 - Attachment is obsolete: true
(Assignee)

Comment 62

8 years ago
http://hg.mozilla.org/mozilla-central/rev/aac514561b0b
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090311051703
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
Attachment #365928 - Flags: approval1.9.1? → approval1.9.1-
Comment on attachment 365928 [details] [diff] [review]
checked in

Changes a scriptable interface, so we can't take this for 3.5
That interface is new in 3.5, does that make a difference?
(In reply to comment #65)
> That interface is new in 3.5, does that make a difference?

Beltzner, I believe you haven't gotten this question.
Well, it has shipped in b3, after which we promised no extension-breaking compat changes... Probably unlikely to pose a problem in practice, but I'm not sure I really understand the benefits well enough to make that call.
Marking late-compat just so we can add this to the list, but the fact that it's new for 191 and unlikely to be something that add-ons are targeting makes me feel like it's worth the user experience win here
Keywords: late-compat
Comment on attachment 365928 [details] [diff] [review]
checked in

a191=beltzner
Attachment #365928 - Flags: approval1.9.1- → approval1.9.1+
Comment on attachment 365928 [details] [diff] [review]
checked in

Sorry for the churn - Mano and I are going back and forth trying to figure out if it's worth him making a branch-safe (non changing API) patch for this or not.
Attachment #365928 - Flags: approval1.9.1+ → approval1.9.1-
Just to clarify - we still consider the scriptable usage unlikely to break due to this patch. The potential issue is with binary addons and the like.
And to be clearer yet: Mano's working up a branch patch, which Enn will review.
Created attachment 373031 [details] [diff] [review]
branch-safe version
Attachment #373031 - Flags: review?(enndeakin)
Flags: blocking1.9.1- → blocking1.9.1?
Priority: P2 → P1
Attachment #373031 - Flags: approval1.9.1?
Comment on attachment 373031 [details] [diff] [review]
branch-safe version

hrm, this doesn't seem to build. Investigating
Attachment #373031 - Flags: approval1.9.1?
Attachment #373031 - Flags: review?(enndeakin) → review-
Comment on attachment 373031 [details] [diff] [review]
branch-safe version

Well, no then, if it doesn't build.

Personally, if I didn't want to change the interface, I would have just used a hard-coded hacky patch like the very first patch for 1.9.1.
No, that won't do due to comment 26 (Yes, I need to file a follow up for the tabbrowser.xml part).
Created attachment 373172 [details] [diff] [review]
191 - builds

see previous comment
Attachment #373031 - Attachment is obsolete: true
Attachment #373172 - Flags: review?(enndeakin)
Attachment #373172 - Flags: review?(enndeakin) → review+
Attachment #373172 - Flags: approval1.9.1?
Removing late-compat keyword as we now have a 191 patch that modifies something that was added only in b3.
Keywords: late-compat
Comment on attachment 373172 [details] [diff] [review]
191 - builds

a191=beltzner
Attachment #373172 - Flags: approval1.9.1? → approval1.9.1+
Flags: blocking1.9.1? → blocking1.9.1-
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1dd773e64a93
Keywords: fixed1.9.1
Verified on 1.9.1 with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b4pre) Gecko/20090420 Shiretoko/3.5b4pre ID:20090420044915
Keywords: fixed1.9.1 → verified1.9.1
Flags: in-litmus?
https://litmus.mozilla.org/show_test.cgi?id=7578 has been updated to cover this regression.
Flags: in-litmus? → in-litmus+
Depends on: 505376
Keywords: dev-doc-needed
I'm not clear on what if anything really requires documentation here; this appears to be pretty much an internal change to an undocumented interface.
Dunno what I was smoking when I wrote comment 83, but it must have been good. I've updated the article about DataTransfer now:

https://developer.mozilla.org/En/DragDrop/DataTransfer#mozCursor
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.