Closed
Bug 405277
Opened 17 years ago
Closed 17 years ago
Go button fails to appear when plain text dragged to location bar
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
VERIFIED
FIXED
Firefox 3 beta4
People
(Reporter: ipottinger, Assigned: dao)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Gavin
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
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.
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).
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.
Reporter | ||
Comment 4•17 years ago
|
||
*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•17 years ago
|
||
(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".
Reporter | ||
Comment 6•17 years ago
|
||
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.
Updated•17 years ago
|
Flags: blocking-firefox3?
Assignee | ||
Comment 7•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Keywords: regression
Comment 8•17 years ago
|
||
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?
Attachment #300048 -
Flags: review?(mano) → review-
Assignee | ||
Comment 9•17 years ago
|
||
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•17 years ago
|
||
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.
Assignee | ||
Comment 11•17 years ago
|
||
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.
Assignee | ||
Comment 12•17 years ago
|
||
Attachment #300048 -
Attachment is obsolete: true
Attachment #300551 -
Flags: review?(gavin.sharp)
Comment 13•17 years ago
|
||
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.
Attachment #300551 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Updated•17 years ago
|
Attachment #300551 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #300551 -
Flags: approval1.9? → approval1.9+
Updated•17 years ago
|
Keywords: checkin-needed
Comment 14•17 years ago
|
||
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.
Keywords: checkin-needed
Target Milestone: --- → Firefox 3 beta4
Updated•17 years ago
|
Flags: in-litmus?
Assignee | ||
Comment 15•17 years ago
|
||
comment 13 has been addressed in another bug
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 16•17 years ago
|
||
Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b4pre) Gecko/2008020704 Minefield/3.0b4pre.
Status: RESOLVED → VERIFIED
Updated•17 years ago
|
Flags: blocking-firefox3? → blocking-firefox3+
Flags: in-litmus? → in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•