MozillaZine

[Ext] QuickDrag 2.1.3: SuperDragAndGo's minimalist successor

Announce and Discuss the Latest Theme and Extension Releases.
7842.9
 
Posts: 25
Joined: April 23rd, 2008, 3:04 pm

Post Posted December 31st, 2008, 5:26 am

zeniko wrote:
Dracula wrote:Or any other similar extension that works with FF3.1b2?

Drag'n'go is an option-less version of Super DragAndGo which I actively maintain for myself. Feel free to use it (until QuickDrag or Drag de Go are updated).


*looks at dragngo.xul*

You mean the only code change needed was to change the "dragdrop" event listener to just "drop" instead? I would never have thought of that when I tried to fix it myself (in userChrome.js version).

zeniko
 
Posts: 201
Joined: October 19th, 2007, 4:50 am
Location: Swiss Confederation

Post Posted December 31st, 2008, 7:12 am

pirlouy wrote:It would be cool if we could chose the search engine.

Since it uses the default engine, you can choose it through browser.search.defaultenginename or by modifying the userChrome.js snippet to use a URL of your choice right after the line with defaultEngine.

7842.9 wrote:You mean the only code change needed was to change the "dragdrop" event listener to just "drop" instead?

Pretty much so, yes. BTW I've also update the Drag'n'go snippet if you prefer that one (the extension uses exactly the same code, just gets automatic updates).

laurel

User avatar
 
Posts: 49
Joined: October 4th, 2004, 9:50 pm
Location: Prescott

Post Posted January 7th, 2009, 10:37 am

Hi, Often this works, but then it starts opening links into pages that say things like: Your search - http://www.amazon.com/Mission-Style-Que ... 1-8Mission Style Queen Bedroom Set - did not match any documents.

What's that about, and what's the cure?

Thanks, laurel

kliu0x52

User avatar
 
Posts: 569
Joined: October 18th, 2006, 2:23 pm
Location: .us

Post Posted April 4th, 2009, 7:24 pm

2009/04/04 - 2.0.0
  • [Bug #91] Fixed a problem where drags would sometimes result in a "not allowed" cursor.
  • [Bug #93] Updated QuickDrag to work with Gecko 1.9.1.
  • [Bug #98] QuickDrag now supports SeaMonkey 2.
  • [Bug #58, #92, #99] Various improvements to the heuristics used to determine whether a string should be treated as a URI or as a search string.
  • [Bug #101] QuickDrag will now work with text that has been dragged from an outside application.
  • [Bug #104] Added 11 new translations (via BabelZilla).

My apologies for the delay. :(
My addons: NoRedirect | QuickDrag | URL Flipper | TabSubmit
Developers: Make sure to test your addons for RTL compatibility!

RNiK

User avatar
 
Posts: 561
Joined: August 9th, 2006, 6:47 am
Location: Forette City, Italy

Post Posted April 7th, 2009, 2:49 am

Great news! THANKS! =D>
MondoWin ==> Italian site for information about MS Windows tweaking

kliu0x52

User avatar
 
Posts: 569
Joined: October 18th, 2006, 2:23 pm
Location: .us

Post Posted April 7th, 2009, 6:15 pm

2009/04/07 - 2.0.1
  • [Bug #115] QuickDrag now handles e-mail addresses correctly.
  • [Bug #116] Fixed a bug where links with blank lines in the content text could become corrupted.
  • [Bug #117] Improved handling of multi-line selections.
  • [Bug #118] Added and updated translations from BabelZilla.

There is also a request for comments/suggestions in bug #102.
My addons: NoRedirect | QuickDrag | URL Flipper | TabSubmit
Developers: Make sure to test your addons for RTL compatibility!

kliu0x52

User avatar
 
Posts: 569
Joined: October 18th, 2006, 2:23 pm
Location: .us

Post Posted April 29th, 2009, 7:57 pm

2009/04/29 - 2.0.2
  • [Bug #119] Removed the search location checkbox from QuickDrag's options dialog in SeaMonkey since this option is controlled by SeaMonkey's own built-in search preferences.
  • [Bug #138] New behavior: A URL will be saved instead of opened in a new tab if the Alt key is held while dropping.
My addons: NoRedirect | QuickDrag | URL Flipper | TabSubmit
Developers: Make sure to test your addons for RTL compatibility!

JMJimmy
 
Posts: 21
Joined: April 6th, 2005, 8:22 am

Post Posted June 14th, 2009, 12:24 pm

Bug:

QuickDrag overrides expected behaviour for moving content with the mouse in form fields & contenteditable elements. Correction: input and textarea & contenteditable=true elements should not be considered valid "whitespace" when using QuickDrag.

JMJimmy

kliu0x52

User avatar
 
Posts: 569
Joined: October 18th, 2006, 2:23 pm
Location: .us

Post Posted June 14th, 2009, 12:48 pm

JMJimmy wrote:QuickDrag overrides expected behaviour for moving content with the mouse in form fields & contenteditable elements. Correction: input and textarea & contenteditable=true elements should not be considered valid "whitespace" when using QuickDrag.

I cannot reproduce this bug.

One of the design decisions of QuickDrag that sets it apart from most of the other DND extensions is that it listens to events in the bubble phase instead of the capture phase. This ensures that other DND behaviors will take precedence over QD and that QD will not interfere with built-in DND behaviors or the DND behaviors of other extensions.

So QD was designed so that it would not (and could not) interfere with drags within/into/between text boxes, contentEditable boxes, or any other DND behavior, and I just tested QD with dragging various things within/into/between a series text boxes and contentEditable boxes without encountering any problems.

Perhaps there is another extension that you have installed that is causing the problem?
My addons: NoRedirect | QuickDrag | URL Flipper | TabSubmit
Developers: Make sure to test your addons for RTL compatibility!

JMJimmy
 
Posts: 21
Joined: April 6th, 2005, 8:22 am

Post Posted June 14th, 2009, 1:11 pm

Just confirmed on clean profile (everything but the 'Default Mozilla Plugin' disabled, including flash/java/etc) with default addon settings.

Type text into this reply box, highlight a portion of the text, drag anywhere in the reply box.

JMJimmy

Edit: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)

Edit 2: Further information, I've narrowed it down. If you drag after a newline character but still within the textarea, or after the EOF equiv for the textarea the behaviour changes from Firefox default to Quickdrag. The expected is that if you drop it after a newline/EOF that the text drops in and wraps appropriately or generates the 'can't move here' symbol. This is overridden by QuickDrag to assume whitespace even though it's still within the textarea.

kliu0x52

User avatar
 
Posts: 569
Joined: October 18th, 2006, 2:23 pm
Location: .us

Post Posted June 14th, 2009, 1:51 pm

JMJimmy wrote:Edit 2: Further information, I've narrowed it down. If you drag after a newline character but still within the textarea, or after the EOF equiv for the textarea the behaviour changes from Firefox default to Quickdrag. The expected is that if you drop it after a newline/EOF that the text drops in and wraps appropriately or generates the 'can't move here' symbol. This is overridden by QuickDrag to assume whitespace even though it's still within the textarea.

Oh, okay, I see what you mean now. When you drag within/into/between an editable area (text box, text area, contenteditable), the default built-in behavior draws an insertion point (the vertical line that tells you where stuff will be dropped) if action is valid, and in that case, QD will not interfere in any way. If the action is not valid (basically, if you are dropping a selection in the same location as before), then the default built-in behavior will disable itself. If QD is not installed, then you will get the you-cannot-drop-here mouse cursor, and if QD is installed, then, since the default drag behavior has declined to handle the drag, the event will bubble up to QD.

Your "EOF" thing is actually just a special case of this. If your selection extends to the very end of the editable area, then any attempts to drop it at the end will be deemed invalid (since your selection is already at the end). If you select everything except for the last character, then dropping past the "EOF" will be valid and will work.

Anyway, I don't think that this behavior should be classified as a bug. Because the only time that QD is "overriding" the default behavior is when the default behavior has declined to handle the drag. IOW, it would have been a drag-not-allowed scenario. If the drag was legal and allowed, the event would never have bubbled up to QD, and QD would not have been involved--QD will never prevent you from drag-and-dropping text into, within, or between editable areas.

So the question is, if the drag is not a valid move operation, should it be a no-drag-allowed? On one hand, it would make it clearer to the user that this drag is not valid if the user was intending a move (you could always look to see if the insertion marker is being drawn, but that is not as obvious). On the other hand, I personally find this behavior to be useful. I sometimes need to search for some text that has been typed into a text box. I can select the text and drag it just a few pixels (so that the mouse is still over the selected text, which would make this an invalid move operation since the position's still the same) to search, whereas if QD also declined to handle it, then I would have to drag all the way out of the editable area before QD will handle it (which is annoying for big multiline boxes). So there are benefits and downsides to both approaches of handling this.

In any case, QD is only handling drags that the other handlers have all declined to handle, so this is not a bug. I can see why you might want the no-drag-allowed behavior instead, so I will give this some consideration as a potential feature request...
My addons: NoRedirect | QuickDrag | URL Flipper | TabSubmit
Developers: Make sure to test your addons for RTL compatibility!

JMJimmy
 
Posts: 21
Joined: April 6th, 2005, 8:22 am

Post Posted June 14th, 2009, 2:47 pm

Perhaps as a 5th option? The biggest drawback is contentEditable - many browser based WYSIWYG editors rely on this and QuickDrag becomes a serious irritant instead of a great tool in this case. Wiki editing is also problematic as content shifting becomes hit and miss. The other problem lies in the fact that, while the browser will display the 'not valid drop point' icon, it does allow you to drop at that location (observe change in carat position as you move up and down a series of new lines).

JMJimmy

robrob
 
Posts: 17
Joined: January 21st, 2009, 3:52 pm

Post Posted July 26th, 2009, 5:05 pm

A great rewrite of the original, thank you for your work.

I have noticed that QuickDrag passes the referrer when you drag a link. Super DragAndGo didn't do that - it that was one of the reasons I had chosen to use it. I had actually assumed that QuickDrag would have the same feature until I discovered by accident that even when you drag a clickable link instead of clicking on it, it will still pass the referrer.

Do you know of any mod that can change this behavior back? Any option or setting anywhere? Maybe a hint about the part of the code responsible for this? :)

Thanks.

lucca
 
Posts: 6
Joined: August 13th, 2009, 2:39 pm

Post Posted August 13th, 2009, 2:45 pm

Love this ext. but all of a sudden, text and URL drags just open a blank Google window instead of text searching or loading the URL. Dragging images still opens a save dialog like normal. Anyone else? I'm using FF 3.5.2 / XP

Help and thanks

lucca
 
Posts: 6
Joined: August 13th, 2009, 2:39 pm

Post Posted August 18th, 2009, 12:32 pm

lucca wrote:Love this ext. but all of a sudden, text and URL drags just open a blank Google window instead of text searching or loading the URL. Dragging images still opens a save dialog like normal. Anyone else? I'm using FF 3.5.2 / XP

Help and thanks


Anyone?

Return to Extension/Theme Releases


Who is online

Users browsing this forum: Yaron10 and 5 guests