[meta] Decorate Search History entries with actual search terms

NEW
Unassigned

Status

()

3 years ago
2 years ago

People

(Reporter: nalexander, Unassigned)

Tracking

(Depends on: 3 bugs, {meta})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox45 affected)

Details

Attachments

(1 attachment)

This ticket tracks the "Decorated Search History" idea that Darrin proposes in https://people.mozilla.org/~dhenein/labs/mobile-panels/#collapsiblehistorydecoratedsearchhistory

The idea is to display, in the awesome screen and approrpriate home panels,  prior searches more richly than as URLs.  That is, rather than showing an opaque URL (say to a Yahoo search), show an informative search icon (and perhaps the "past search" clock icon) and the search terms directly.  We may want to make tapping the search transfer the terms to the URL bar for amending, rather than re-launch the search.
(Reporter)

Comment 1

3 years ago
ally: this is similar to the work you did displaying previous searches in the search suggestion dropdown.  Should we be *removing* history items that are searches and trusting them to display in the search suggestion dropdown?
Flags: needinfo?(ally)
(Reporter)

Comment 2

3 years ago
mfinkle: you pointed me at some browser.js code tracking searchEngine and parameters associated to a tab.  It's quite hard to figure out what that code actually achieves.  Can you give me a few lines on this functionality?

margaret: you might have context here as well; please steal if you can.
Flags: needinfo?(mark.finkle)
Flags: needinfo?(margaret.leibovic)
(Reporter)

Comment 3

3 years ago
fluffyemily: I think you did some iOS work to achieve something like this.  Can you describe what iOS does?  We should match where feasible in Fennec.

mfinkle suggested that you use the OpenSearch XML definition to parse the URLs and extract search terms in a (mostly) future-proof manner.  Can you link to the code and the parsing test suite?  Thanks!
Flags: needinfo?(etoop)
(Reporter)

Comment 4

3 years ago
I hope to mentor this and sub-tickets after collecting some information and formulating an implementation plan.

I'm confused as to what the existing JavaScript search-term tracking code does.  It looks like the terms go into Gecko and are processed by the XUL browser, but mfinkle will enlighten us.

There's a small Java-side OpenSearch parsing library that needs implementation and testing, to back the search term extraction.  This can be produced independently, using fluffyemily's example as a model.

My expectation is that we'll want to subclass (or enrich) the existing TwoLinePageRow to handle this new data display; and then patch up the link-following implementations and the long-click context menus to do sensible things with searches in history, bookmarks, remote tabs, etc.
Mentor: nalexander, ally
:nalexander

You can find the code here: https://github.com/mozilla/firefox-ios/pull/1205

What I did was

* when working out the displayURL for the current page, grab the initial URL from the BackForwardList (to get the original search request URL, not any redirects)
* match against our search templates to find the matching template
* work out the search param from the template (only do this once & remember)
* extract search terms from the URL based on search param
* URL decode the extracted value
* return and display
Flags: needinfo?(etoop)

Comment 6

3 years ago
(In reply to Nick Alexander :nalexander from comment #2)
> mfinkle: you pointed me at some browser.js code tracking searchEngine and
> parameters associated to a tab.  It's quite hard to figure out what that
> code actually achieves.  Can you give me a few lines on this functionality?
> 
> margaret: you might have context here as well; please steal if you can.

What lines of code are you talking about here?

Right now we don't technically track search terms, but rather what the user entered. You should search the codebase for "userRequested".

This is kinda gross, but it dates back to the error page search box work that wesj did in bug 1042199. I was never really happy with this logic, so it would be nice to see it change.
Flags: needinfo?(margaret.leibovic)
(In reply to :Margaret Leibovic from comment #6)
 
> This is kinda gross, but it dates back to the error page search box work
> that wesj did in bug 1042199. I was never really happy with this logic, so
> it would be nice to see it change.

Agreed. It might be better to create a helper using the technique Emily mentions in comment 5.
Flags: needinfo?(mark.finkle)
I'm not entirely sure what you're asking.
The search suggestions are pulled out of a database and only include the term from the search box, so won't include any urls (unless the user went to the great length of actually typing www.google.com into the search itself that you have visited. I would say that prior search terms and prior history are probably separate enough things to be left alone.

I might suggest a child of TwolineRow, and you'll probably have to modify BrowserSearch a bit as well.
Flags: needinfo?(ally)
(Reporter)

Updated

3 years ago
See Also: → bug 1228654
(Reporter)

Updated

3 years ago
Depends on: 1228657
(Reporter)

Updated

3 years ago
Keywords: meta
Summary: Decorate Search History entries with search terms in Firefox for Android → [meta] Decorate Search History entries with search terms in Firefox for Android
Created attachment 8739224 [details]
Screen Shot 2016-04-07 at 2.47.34 PM.png

Talked to Nalexander about renaming this and using it to clearly scope this (attached) design.

Updated

3 years ago
Summary: [meta] Decorate Search History entries with search terms in Firefox for Android → [meta] Decorate Search History entries with actual search terms

Updated

3 years ago
Depends on: 1255048

Updated

3 years ago
Depends on: 1263013

Updated

3 years ago
Depends on: 1263014

Updated

3 years ago
Mentor: a.m.naaktgeboren, nalexander

Updated

2 years ago
No longer depends on: 1255048
Mentor: s.kaspari, margaret.leibovic

Comment 10

2 years ago
Will this be a good next bug to work on? 
If yes, I'd like to take this up.
Flags: needinfo?(s.kaspari)
(Reporter)

Comment 11

2 years ago
(In reply to Gautam Prajapati from comment #10)
> Will this be a good next bug to work on? 
> If yes, I'd like to take this up.

Probably not.  I expect we'd want updated UX guidance, and the display here has probably gotten more complicated in the face of Activity Stream.  sebastian can say more -- perhaps I've gotten it backwards and Activity Stream will make this easier!
Yeah, there's currently work underway to refresh the UI (Photon) and to rethink our home panels (Activity Stream). Our mentor bugs are currently in a bad shape - most are done and the ones left are either not good mentor bugs anymore or the mentors have left. I'll go through my bug lists and will flag you once I see something that's good. :)
Mentor: margaret.leibovic, s.kaspari
Flags: needinfo?(s.kaspari)
You need to log in before you can comment on or make changes to this bug.