Closed Bug 1227019 Opened 7 years ago Closed 2 years ago
[meta] Decorate Search History entries with actual search terms
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.
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?
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.
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!
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
(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.
(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.
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.
Summary: Decorate Search History entries with search terms in Firefox for Android → [meta] Decorate Search History entries with search terms in Firefox for Android
Talked to Nalexander about renaming this and using it to clearly scope this (attached) design.
Summary: [meta] Decorate Search History entries with search terms in Firefox for Android → [meta] Decorate Search History entries with actual search terms
Will this be a good next bug to work on? If yes, I'd like to take this up.
(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
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.