blushproof should intercept some common 'blush' searches.

[gregglind]

If I type "facebook" or "xhampster" or "online poker" I don't even want it showing up as a completed search.

This is a very common pattern of urlbar usage, for the Evergreen / Busy Bee audience most helped by this feature :)

Suggested trivial impl: regex search on substrings :) (See the initial checkin)

[gregglind]

The failcase:

if I get to Google Search Results for "xhampster" it's gone too far!

I also thing think the interception of search terms makes the demo really compelling and 'wow' for people :)

[monicachew]

I can think of two easy-ish solutions.

1. Keep a separate blushlist map for checking against the awesomebar, similar to Gregg's prototype. We could use [http://norvig.com/spell-correct.html](http://norvig.com/spell-correct.html) which is super simple and would let us clean "pr0n" if someone misspells "porn"
2. Assume that search history is not useful per se. Why would www.google.com/?q=xhamster ever be useful to show up in the awesomebar, or in the history? Either the search was useful, in which case the clicked-on result is the thing that you care about, or it's not, in which case it shouldn't even be in history.

@mozkeeler, what do you think?

[monicachew]

https://github.com/dscape/spell This one looks promising, if we go for 1). It's under the apache license.

[monicachew]

Also this one: https://github.com/past/speller

I think we can just shove in the list from Alexa minus the TLDs for it to train on.

[monicachew]

I started working on this (9755571718454c66e8dc8e4da2b727ba778283cb) but I think intercepting the query on enter then emulating the flow to search if it's not a URL is kind of fragile. Using window.openDialog("searchterm") doesn't go through that flow, it seems to append .com and go to searchterm.com (unless my resolv.conf or similar is mucking that up, but it doesn't seem so)

Instead I think we should have a separate getSearchQueryFromURL (that knows about google/bing/yahoo/etc), match on that, and use it in the content policy.

[gregglind]

FWIW, the code path is:

 window.openDialog("chrome://browser/content/browser.xul"....)    // open a blank browser window

Then you set the urlbar text to the search term. This leaves the user in exactly the same place in the UI as they were before the search.

Demangling the search string is also fragile, and search engine dependent.

[monicachew]

Demangling the search string has the advantage that it also works for people who go to google.com and type in their query -- no urlbar listener is going to be able to do that.

It's also a good thing to unify the code path for handling PB navigation.

[gregglind]

True enough! Both techniques will probably get used in the final.

This is something to hash out over in the 'what do we promise to users' bug, maybe :)

On Mon, Feb 11, 2013 at 12:00 PM, monicachew notifications@github.comwrote:

Demangling the search string has the advantage that it also works for people who go to google.com and type in their query -- no urlbar listener is going to be able to do that.

— Reply to this email directly or view it on GitHubhttps://github.com/mozilla/blushproof/issues/17#issuecomment-13393280.

[monicachew]

The call that's broken on the search term is: const BROWSERURL = "chrome://browser/content/browser.xul" aWindow.openDialog(BROWSERURL, null, "chrome,all,dialog=no,private", searchterm);

I think what will happen if I do the other (openDialog with a blank BROWSERURL plus setting the address bar) is that we'll also have to simulate hitting enter again

And we will not catch people using the search bar to look for d3.js (or its porny equivalent) because the awesomebar is not so awesome with searching for terms with "."

So, I think what's easiest, even if we have to do the other hack as well, is to implement getSearchTermFromURL for now.