Closed Bug 782557 Opened 12 years ago Closed 4 years ago

Provide equivalent to Chrome's OpenSearch-based "Press Tab to search ..." completion behaviour

Categories

(Firefox :: Search, enhancement, P3)

Product:
Firefox
Component:
Search
Version:
16 Branch
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
83 Branch
Tracking Flags:
Tracking Status
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- verified

People

(Reporter: from_bugzilla3, Unassigned)

References

Details

(Keywords: parity-chrome, Whiteboard: [fxsearch])

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0 Build ID: 20120809071137 Steps to reproduce: I wanted to search my blog (or any other site I visit sporadically) for an old article I wrote, so I started typing a site's domain in my address bar. I then remembered that, because this is Firefox, I have to manually install a search plugin, then manually specify a keyword before I can search from the address bar. (And I only do that for sites I use ridiculously often like Wikipedia, Google, DuckDuckGo, or YouTube) Actual results: I switched to the copy of Chrome on my other monitor, typed bl<Tab> for "Search blog.ssokolow.com", typed my search, hit Enter, and then copied the URL for the desired result back into Firefox. Expected results: The AwesomeBar should have streamlined web searches in the same way it streamlines bookmark/history searches. (And, most of the time, history search works so well that I don't need Google OR manual bookmarking to re-locate articles I read) The browser should have been transparently retrieving OpenSearch definitions to be stored as part of the browser history and provided an equivalent to Chrome's "Press Tab to search <most likely domain completion>" prompt.
Blocks: 782563
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: Untriaged → Search
OS: Linux → All
Hardware: x86_64 → All
Whiteboard: [parity-chrome]
Priority: -- → P3
Whiteboard: [parity-chrome] → [parity-chrome][fxsearch]
What's the current status? I'd be willing to help on the implementation
Flags: needinfo?(from_bugzilla2)
(In reply to pascal.seitz from comment #4) > What's the current status? > > I'd be willing to help on the implementation It'll take me a few days to find time to answer your question because I'll need to temporarily install a current Firefox. I'm still on 52ESR while I work toward replacements for extensions like downThemAll. (eg. I need to turn TiddlyFox into an extension+daemon pair which maps the old XULConnect APIs to HTTP calls for TiddlyWiki classic, and, once dTA lite comes out, I'll see about modding it to prefix filenames with the domain so "don't ask where to save" combined with an inotify filesystem-watcher daemon running outside Firefox can re-create the workflow from the current downThemAll using a non-Firefox save dialog... I'm just glad I don't run a filesystem indexer which might have its thumbnailer get exploited by a malicious download before I can click "Cancel" on the out-of-Firefox save dialog.)
Okay, no problem. In the meantime here's a rough draft of my understanding of the features architecture. We have a feature which autodetects search engines on a website. We would use that feature, to store all search engines the user encouters with their urls/hosts(?) An encounter could be an open search description, or maybe anything that can be added as a keyword search (keyword searches can be more than just search https://bugzilla.mozilla.org/show_bug.cgi?id=648398#c15) When fetching suggestions from moz_places/moz_hosts, we would also check if the proposed entry has an associated search engine and enable tab to search on that entry. When tab selecting and execute a search, we should probably increase the frecency on the hit. Search engines can change, there is a update mechanism integrated for search plugins. -- I saw in places.sqlite/moz_keywords there are the keywords associated with a place id. Search engines (or search plugins) seem to be handled and stored completely differently and can be listed here resource://search-plugins/ I don't see why they are separated, I guess they should be together. (Related: https://bugzilla.mozilla.org/show_bug.cgi?id=648398)
> When fetching suggestions from moz_places/moz_hosts, we would also check if the proposed entry has an associated search engine and enable tab to search on that entry. That means there is a lookup to a website before I press enter. As far as I understand the Chrome feature, there is a database of tab-search provides that is populated by sites I have already visited. So if I visit a site, only then the search engine description lookup should happen and on success, the search engine should be added to a database that is then used to allow for this feature.
> As far as I understand the Chrome feature, there is a database of tab-search > provides that is populated by sites I have already visited. Yes that's what I meant with "We have a feature which autodetects search engines on a website. We would use that feature, to store all search engines the user encouters with their urls/hosts(?)" So we need a place where we store visited search engines. I guess, the places.sqlite database is probably the best place to store this information. (Related Bug 648398)
Blocks: 1425024
(In reply to Pascal Seitz from comment #4) > What's the current status? > > I'd be willing to help on the implementation Sorry for the ridiculous wait. Pretty much everything in my life related to Firefox Quantum got put on hold. The situation from the end-user's perspective is the same as when I reported the bug. In both Firefox and Chrome: 1. Visit http://blog.ssokolow.com/ 2. Perform a search 3. Close the tab 4. Open a fresh tab 5. Type enough of the domain name to get a match 6. Press Tab In Chromium 63, it will prefix the address bar with "Search blog.ssokolow.com |" and whatever you type will be fed into the site search. In Firefox 58, it will step through history results as if I'd never performed the search in an attempt to prime the system.
Flags: needinfo?(from_bugzilla2)
Perhaps this may be out of my business, but is there specific reason why this is left unresolved for such a long time? This feature is so practical that many people leave Firefox to Chrome simply for only this feature.
Apparently this is possible in Nightly now https://twitter.com/FirefoxNightly/status/981487275568746496
The video shows the classic behavior of Firefox, keyword search. Maybe they put a couple shortcuts on the UI to make them easier to add/edit, but this is not what is requested on this ticket.
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-chrome
Whiteboard: [parity-chrome][fxsearch] → [fxsearch]
Is there any update with this feature?
(In reply to Michal from comment #17) > Is there any update with this feature? There are many updates coming the Search Service and the Awesomebar that will make it more straightforward to implement, but we haven't committed to work on this specific feature once that's in place. So one part is indeed about adding all search engines of pages you've visited before. This is very opaque behavior and requires the user to be aware of 1) they visited the page and _know_ that it offered an OpenSearch definition and 2) what keyword it defined to use for tab-to-completion. I think we can and should do better. In Firefox 62 we're experimenting with specific keyword support for our top search engines - bug 1479806 and more specifically bug 1480503 contains all the details - so that you can start a search quickly by tying '@ddg Feeling lucky', for example. This is not yet available to all users yet, but we're working on it. It's an example of the various improvements to come. We're placing the bricks for a solid foundation today.
> 2) what keyword it defined to use for tab-to-completion. It should be noted that being able to drive this functionality from the suggested URLs is the whole point of it, and what makes it useful. I'm keeping an eye on this because this usability improvement is currently what's blocking me from migrating back to Firefox from Chrome. I had been using Firefox since the 2.x days but eventually moved over to Chrome because the user experience was far more friendly when operating it. I understand wanting the user to approve that a site can be used for searching before enabling the functionality, but after that's done, it should work seamlessly without extra input from the user. Hitting "y", having the browser guess "youtube.com" and hitting tab to search is exactly what makes the functionality powerful. (In case anyone is unfamiliar with Chrome's implementation, hitting tab again will then take you out of search mode and select the second suggestion on the list, so this does not prevent scrolling through the options with tab.)

I just had a friend say that this was preventing them from switching to Firefox.

There is an extension that does this (https://github.com/gjulianm/tabtosearch), but it uses the old XPI extension format and doesn't work with recent versions of Firefox.

doc on how Chromium adds sites to search: https://www.chromium.org/tab-to-search

Blocks: 1574990

Why is this still opened? You can manually opt into the open search. It's not automatic because of privacy reasons.
In Firefox you press space not tab like in Chrome
https://vimeo.com/276817755

(In reply to petcuandrei from comment #25)

Why is this still opened? You can manually opt into the open search. It's not automatic because of privacy reasons.
In Firefox you press space not tab like in Chrome
https://vimeo.com/276817755

Because it's not fixed?

In Chrome, if I visit my blog (blog.ssokolow.com) and then type blog.ssokolow.com<Space> in the address bar, I get "Search blog.ssokolow.com". If I do it in Firefox, I get "http://blog.ssokolow.com/ - Visit"

This bug is about making OpenSearch discoverable and convenient enough that people use it for more than their top three or four most-often searched sites.

No longer blocks: urlbar-searchshortcuts
Depends on: 1647921

With the landing of Bug 1667470, we have in Nightly something similar to tab to search, where we introduced a tabbable-to second result for autofilled origins, that have a search engine installed.
This is not exactly the same as Chromium's feature, because it requires the user to install the search engine, rather than adding it without user intervention, on the other side that gives a little bit more control to the user for now.
Bug 1119572 tracks being able to use engines without directly installing them explicitly, there has not been a decision regarding that yet.
The feature will get further improvements in the future, to get better matching for example, but it's a good base to start building upon and pretty much solves this concern.
If you find bugs or misbehaviors please file separate bugs.

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox81: --- → wontfix
status-firefox82: --- → wontfix
status-firefox83: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Tab to search was successfully implemented and working accordingly. In order for what Stephan is asking to work, the website needs to be added as a search engine.
As Marco said, that is being tracked separately (if it is decided to be implemented).

Status: RESOLVED → VERIFIED
status-firefox83: fixed → verified
You need to log in before you can comment on or make changes to this bug.