Closed Bug 1042201 Opened 6 years ago Closed 4 years ago
Search provider suggestions widget for error pages
When the user hits an error page for a 404, we can provide some suggestions for them on thing they meant to type. One way to do that would be to ping the search suggestions provider (if they have it enabled). They may have some quick fixup opportunities.
The last of this set. This contains some tweaks to other pieces, and there are some bugs to work out, but its a start.
Screenshot of these right now. The error pages are getting a little cluttered. We may have to only show one widget or something... but neat and fun :)
Updated. This actually does both local searches of your browser.db and remote searches via your search provider (if you've enabled suggestions from them). i.e. I'm merging this and bug 1042205 a bit. I filtered the search provider results to return things that look like urls, but we don't have to do that.
Yuan, can you comment/put someone on this? The change here is the list of links in the middle. One of those (the one that's been visited before so its purple) is from your history. The other are google "suggestions". I don't think that's incredibly clear from the UI, so ideas for making it better would be great.
Great talked to yuan a bit. I think that the suggestions from search providers often turn out to be less than useful. i.e. If I type google.cAm I would like to get things like google.ca, but instead get things like google.com/campaigns. It seems unlikely to me that you typed google.cam meaning to go to a google campaigns site. Search results seem better if you were typing something you meant as a search term but we treated as a url. i.e. window.open. In that case, you wanted to search anyway (and likely didn't mis-spell anything), so the search bar from bug 1042199 is more useful. We're going to move forward with just the history suggestions here, and bump up bug 1042199 as something to get done sooner. If we want, we can continue to ping search providers (in a follow up) and try to do a better job filtering out good/bad matches. Or maybe present all of them differently (like they are in the Awesome bar)?
(In reply to Wesley Johnston (:wesj) from comment #7) > Great talked to yuan a bit. I think that the suggestions from search > providers often turn out to be less than useful. i.e. If I type google.cAm I > would like to get things like google.ca, but instead get things like > google.com/campaigns. It seems unlikely to me that you typed google.cam > meaning to go to a google campaigns site. > > Search results seem better if you were typing something you meant as a > search term but we treated as a url. i.e. window.open. In that case, you > wanted to search anyway (and likely didn't mis-spell anything), so the > search bar from bug 1042199 is more useful. We're going to move forward with > just the history suggestions here, and bump up bug 1042199 as something to > get done sooner. > > If we want, we can continue to ping search providers (in a follow up) and > try to do a better job filtering out good/bad matches. Or maybe present all > of them differently (like they are in the Awesome bar)? Hi Wes, I am still on the same page with surfacing search and having history integrated on error page. But I just gave search suggestions a few more thoughts. And I think the reason that current search suggestions are not helpful, because they are not given based on the level of domain. For example, if a user types "Google.cam", instead of getting suggestions like "Google.com/campaigns", but getting "google.com" or "google.ca". I could see that being more valuable, more likely to match the results people wanted. I guess the question is whether Fennec can have the control on what search suggestions to show in the browser. Thoughts?
I agree it would be neat if we could filter the list down to get some good results. We could use something similar to what we do with history and require the the result be within some Levenshtein distance  of what you typed. Its a little helpful to just type things into the desktop search box and see what comes back. I noticed a bug with this by doing that. Sending "google.cam" sends back some useful results. Here I was actually sending "http://google.cam" which returns much less useful things. I should make sure we're using what you typed here instead of the cleaned up version.  http://en.wikipedia.org/wiki/Levenshtein_distance I'll still go back to splitting this up and prioritize the search box.
Moved this history stuff back over to bug 1042205. This is the search provider piece here from before, without any changes. I'll try to come back and fix it up. We'll need the user-typed search term for the search box as well, so I'm going to deal with getting it there.
(In reply to Wesley Johnston (:wesj) from comment #5) > [Tracking Requested - why for this release]: Happy to track this but in the future can you provide even a short blurb justification for the nom.
I'm dropping tracking as this isn't necessary for 34 and hasn't had any action since Aug.
That is fine. The search widget for error pages is in Fx35.
Unassigning, but this might be a good bug for a newbie to finish up. i.e. The patch here is mostly working but would need to be updated for the new error page widget code.
Assignee: wjohnston → nobody
Whiteboard: [good first bug][lang=js]
Margaret, do you know who would be an appropriate mentor for this bug? crazyprodigy on irc is interested in picking it up.
(In reply to Michael Comella (:mcomella) from comment #15) > Margaret, do you know who would be an appropriate mentor for this bug? > crazyprodigy on irc is interested in picking it up. I can help. You want to look at code in here: http://mxr.mozilla.org/mozilla-central/source/mobile/android/modules/NetErrorHelper.jsm#67 I see that we create the HTML for this in .dtd files, which seems pretty awful :( http://mxr.mozilla.org/mozilla-central/source/mobile/locales/en-US/overrides/netError.dtd#20 But that would be an issue for another day. Barbara and I have also been talking with the security team about potentially un-forking our neterror pages, but that wouldn't happen any time soon, so we shouldn't worry about that for now.
Mentor: wjohnston2000 → margaret.leibovic
Hi Margaret, this is very good bug for newbie.I want to resolve this bug.Sorry but I'm not sure I understand.In this bug we want more "suggestion" when we type "Google.cam" but it will only be possible through the history of user. Could you provide some more information so that I can easily understand this bug.I have read all the comments but not sure that I have understand correctly or not.
I think we should check with bram and antlam for some UX direction here. Since the screenshot wesj posted, we now have a search box in the error page, so I'm not sure that we actually need to provide suggestions like this. I'm tempted to WONTFIX this.
(In reply to :Margaret Leibovic from comment #18) > Since the screenshot wesj posted, we now have a search box in the error > page For what it’s worth, I don’t see a search box in my “Server Not Found” page. However, some time ago, Philipp has mocked up what this design could look like: http://phlsa.github.io/fx-server-not-found/ If we’re looking to implement a search box (or already implement one), then perhaps this bug can be WONTFIXed.
I agree, this seems to be a bit much. I don't think we need suggestions here right now... Marking as WONTFIX
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.