405277 - Go button fails to appear when plain text dragged to location bar

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Ian Pottinger]

Dragging plain text to the location bar fails to make the Go button appear.  This makes it impossible to navigate to plain text URLs or preform a "I feel Lucky" search without additional keyboard manipulation.

Comment 1

[RenegadeX]

While this Bug is not exactly the end of the world, dragging and dropping text into the Location Bar is something that I would think is a fairly common task as like Ian said in Comment #0, Firefox features the very handy Location Bar Google "I feel lucky" search function. Personally, I have the Enter button mapped to a mouse thumb button so never ever click the 'Go' Button anyway, but then again I realize that >98% of the world is nowhere as near as intelligent as me and wastes time by having to move their mouse pointer all the way over to the 'Go' Button so that they can submit whatever the heck it is they're wanting to search for.

Having no 'Go' Button in this situation is problematic, and I have great sympathy for all those users who will potential freak out and not know what to do next. So, I looked into the code to see if a simple hack was possible, but then after trying 1 or 2 changes unsuccessfully, realized that I was in over my head. So I did the next best thing - and came up with this:

I think this Bug depends on this ancient Bug: Bug 128066, "DragNDrop: Drop into a textbox (input field) doesn't trigger 'oninput' or 'onchange' event" - https://bugzilla.mozilla.org/show_bug.cgi?id=128066

.. or perhaps this very similar one: Bug 280635, "Text box receiving text via drag-and-drop does not get focus" - https://bugzilla.mozilla.org/show_bug.cgi?id=280635

There is a nice little testcase in the 280635 thread, here: https://bugzilla.mozilla.org/attachment.cgi?id=173060
.. which if run in Firefox, then repeated using IE or Safari (Windows version, anyhow), does a fantastic job of showing that Firefox fails to set focus on drops.

Perhaps worthy of mention: this problem was fixed/worked-around(I'm not sure which) on the Find Bar some time ago (Bug 296827).

Comment 2

[RenegadeX]

Scratch that, it's not 280635 because even when the Location Bar is clicked-on after dropping text, the 'Go' Button does not appear. It only changes from 'Star' to 'Go' upon a keyboard input event.

Comment 4

[Ian Pottinger]

*PING*

Still not fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008012804 Minefield/3.0b3pre

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #4)
> *PING*
> 
> Still not fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre)
> Gecko/2008012804 Minefield/3.0b3pre

Not sure why you think it would be, since it's still marked "New".

Comment 6

[Ian Pottinger]

I just noticed that other related work was recently completed and wanted to make sure that this was not overlooked.  The ping was to get the bug some attention since it is quite clear that no one is working on this.

Comment 7

[Dão Gottwald [:dao]]

Attachment: patch

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 300048 [details] [diff] [review]
patch

>Index: browser/base/content/urlbarBindings.xml

>             this.value = url;
>             try {
>               urlSecurityCheck(this.value,
>                                gBrowser.contentPrincipal,
>                                Ci.nsIScriptSecurityManager.DISALLOW_INHERIT_PRINCIPAL);
>             } catch (ex) {
>+              SetPageProxyState("invalid");
>               return;
>             }
>             handleURLBarCommand();

Don't we want to call SetPageProxyState("invalid") unconditionally after setting the value?

Comment 9

[Dão Gottwald [:dao]]

There's no point in being in the "invalid" state for a split second. It would be more correct, but that doesn't really help us since we use the pageproxystate for visual feedback mainly.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Well, ok, but why does it hurt? Just to avoid doing it twice? I guess I don't really care either way, I'll r+ if you re-request.

Comment 11

[Dão Gottwald [:dao]]

Dropping a secure address while you're on a secure site would make the location bar white for a split second, which is a little bit disturbing compared to the current situation.

On the other hand, trying to connect to the other site can actually take longer or even time out, in which case it would be better to be in the "invalid" state while connecting.

Comment 12

[Dão Gottwald [:dao]]

Attachment: always invalidate when dropping text

Comment 13

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 300551 [details] [diff] [review]
always invalidate when dropping text

Seems like we should probably also call SetPageProxyState("invalid") when setting the value from the copyCutController, so that it gets invalidated when you Cut text.

Comment 14

[Reed Loden [:reed]]

Checking in browser/base/content/urlbarBindings.xml;
/cvsroot/mozilla/browser/base/content/urlbarBindings.xml,v  <--  urlbarBindings.xml
new revision: 1.54; previous revision: 1.53
done

Leaving this open to address comment #13.

Comment 15

[Dão Gottwald [:dao]]

comment 13 has been addressed in another bug

Comment 16

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008020704 Minefield/3.0b4pre.

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

in-litmus+

https://litmus.mozilla.org/show_test.cgi?id=5169