Open Bug 298695 Opened 19 years ago Updated 4 years ago

Drag and drop to tab bar should use bookmark keywords for plain text

Categories

(Firefox :: Tabbed Browser, enhancement, P5)

enhancement

Tracking

()

People

(Reporter: bugzilla, Unassigned)

Details

(Keywords: blocked-ux)

Attachments

(2 obsolete files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050621 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050621 Firefox/1.0+

Typing a keyword followed by a string into the location bar and pressing enter
results in a bookmark keyword URL being generated and loaded.

Currently, dragging a URL to the location bar automatically causes it to load.
This should be expanded so that dragging a phrase which matches a bookmark
keyword query also causes a URL to be generated and loaded.

For example, someone could type the phrase "google mozilla" in a forum. 

If you have a bookmark keyword set up for google (as "google" ->
"http://www.google.com/search?&q=%s"), then dragging the whole phrase (minus the
quotes) to the location bar should cause the query to be expanded to
"http://www.google.com/search?&q=mozilla".

There are lots of situations where this would be useful, such as bugs (when
referenced in plain text) and other common repeated nouns.

Reproducible: Always

Steps to Reproduce:
Probably depends on the affects of bug 285438.
Depends on: 285438
Status: UNCONFIRMED → NEW
Component: Drag and Drop → Location Bar and Autocomplete
No longer depends on: 285438
Ever confirmed: true
Product: Core → Firefox
QA Contact: location.bar
Tweaking summary. Reassigning to Tabbed Browser since this now works for me with
the location bar.
Component: Location Bar and Autocomplete → Tabbed Browser
Summary: Drag and drop to location bar or tab bar should use bookmark keywords for plain text when applicable → Drag and drop to tab bar should use bookmark keywords for plain text
The reason that drag & drop gestures for tabs aren't respecting bookmark
keywords is that spaces in a bookmark keyword string cause Firefox to bail out
before reaching getShortcutOrURI.

This is easily fixed by removing the later calls and placing one single call
before the validity check.
Assignee: nobody → cusser.bugs
Status: NEW → ASSIGNED
Attachment #191603 - Flags: review?(mconnor)
Based on the code affected, this must be a regression from a long time ago
(before 1.0). Upgrading from enhancement to bug.
Severity: enhancement → normal
Keywords: regression
Whiteboard: [has patch, needs review]
Comment on attachment 191603 [details] [diff] [review]
Use getShortcutOrURI before validity check

ooh, bad mojo here.  Toolkit can't depend on browser stuff. (The fact that we
already do is bad, and we should fix that).
Attachment #191603 - Flags: review?(mconnor) → review-
Clearing status whiteboard. Per IRC, this needs to wait until after Firefox 1.5.
Whiteboard: [has patch, needs review]
QA Contact: location.bar → tabbed.browser
Attached patch Unbitrotten (obsolete) — Splinter Review
Resubmitting now that tabbrowser has been moved from toolkit to browser.

On a related note, dropping a bookmark keyword phrase (keyword + string) onto the location bar no longer causes automatic loading. In 2.0, you can still press the "go" button, but in 3.0, the integrated "go" button is not activated on drag/drop of text. Shall I file a bug for this?
Attachment #191603 - Attachment is obsolete: true
Attachment #299596 - Flags: review?(mconnor)
Please disregard the "related note" above, as this problem has now gone away.
Comment on attachment 299596 [details] [diff] [review]
Unbitrotten

I'll try to get to this sometime soon.  Moving it to the new review flag so it gets off the "probably obsolete" list.
Comment on attachment 299596 [details] [diff] [review]
Unbitrotten

this doesn't apply, and I don't have time to clean it up myself.  Ben, if you can attach a new patch I should be quick to review...
Attachment #299596 - Attachment is obsolete: true
Attachment #299596 - Flags: review?(mconnor)
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW

I'm not convinced we actually want this.

Severity: normal → S4
Type: defect → enhancement
Keywords: regressionblocked-ux
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: