Quickly switch searches with AwesomeBar HD

141 views
Skip to first unread message

Edward Lee

unread,
May 9, 2011, 4:06:42 PM5/9/11
to Mozilla Labs Group
Quick screencast showing off some functionality that has been in the
add-on for a while, but now optimized with more prefetching!

https://mozillalabs.com/prospector/2011/05/09/quickly-switch-searches-with-awesomebar-hd/

Ed

Patrick O'Leary

unread,
May 9, 2011, 7:48:08 PM5/9/11
to mozill...@googlegroups.com
I see from a quick Wiresharking that on hovering over the "research" link, a GET to wikipedia.org (which would normally be directed via HTTPS to secure.wikimedia.org by HTTPS Everywhere) was instead issued over HTTP.

While the prefetch is nice, since queries are issued when you so much as breathe on the search category text, there is a privacy concern. I also got (spurious) requests to Twitter (oddly enough, this one seemed to initiate over SSL, but I may have just missed the initial contact), CNN, and Flickr just in trying to gather the data for the one Wikipedia request.

Just more to think about!

Patrick

Mads IsMe

unread,
May 11, 2011, 5:47:46 PM5/11/11
to mozill...@googlegroups.com
I just tried out the AwesomeBar HD and it is really cool concept. A few details:

Typing "reference: mozilla" to look for mozilla on wikipedia is not intuitive. I am inclined to type "wikipedia: mozilla", so it would be nice if it not only recognized categories, but also search engines.

The categories dissappear too fast on some pages (namely amazon and grooveshark). I bare get a chance to study the search results and decide if I want to change search engine before the category selection dissapears.

Why does it keep opening new tabs? Just change the page, I can always click on whatever category I was on, if I want to go back. I get a ton of tabs open right now.

If I type something and hit tab, it will select the first category. Very clever. However, if I start typing now, text will be inserted at the beginning of the string. Probably the least expected behaviour. I would expect to be able to search within categories and search engines. E.g "mozilla <tab> wik" would give me the option to search wikipedia for Mozilla. "Mozilla <tab> ma" would give me the option to search maps for mozilla

Edward Lee

unread,
May 14, 2011, 2:20:53 AM5/14/11
to mozill...@googlegroups.com, Patrick O'Leary
On Mon, May 9, 2011 at 4:48 PM, Patrick O'Leary
<patrick...@gmail.com> wrote:
> GET to wikipedia.org (which would normally be directed via HTTPS to
> secure.wikimedia.org by HTTPS Everywhere) was instead issued over HTTP.
I wonder how it detects requests to redirect. It should be loading
wikipedia.org just as usual. Could you see what happens if you trigger
the search and then just copy/paste the url to a new tab?

> While the prefetch is nice, since queries are issued when you so much as
> breathe on the search category text, there is a privacy concern.

The prefetch only happens if you're already doing a search. So if
you're just typing in a term and happen to move your mouse past the
categories, it won't prefetch. Also, it only prefetches when the
category menu opens, so the fix to make the menu open not immediately
helps in this situation too.

Ed

Kai Lim

unread,
May 16, 2011, 11:25:22 AM5/16/11
to mozill...@googlegroups.com
Hey man,

Still using the awesomebar. Also loving the speed of it now (seriously, how does that pre-fetching thing work? does it rummage through the stored cache?)
One thing I noticed is that you can't change the search engines to a specific engine you want. For example, searching for music on soundcloud.com doesn't work. Is the awesomebar limited to approved partners?
Could changing (or possibly even modding the default search site choices, like adding soundcloud.com and removing Pandora.com) possibly be incorporated in the next iteration?

Cheers and keep up the good work,
Kai

P.S: The guy above me brought up the intuitive thing... might be something to look into?

Edward Lee

unread,
May 17, 2011, 5:38:47 PM5/17/11
to mozill...@googlegroups.com, Mads IsMe
On Wed, May 11, 2011 at 2:47 PM, Mads IsMe <walkingi...@gmail.com> wrote:
> I am inclined to type "wikipedia: mozilla", so it would be nice
> if it not only recognized categories, but also search engines.
One issue here is that one provider can support multiple categories,
and picking out the correct keyword would be somewhat tricky.
"googlemaps: mozilla"? But definitely, for others it does make sense
to be able to jump straight to a provider within a category like
wikipedia, youtube, twitter. Maybe for repeating providers, tabbing
could switch the category -- not sure how to indicate it though, as
it'll just show up as "[g] google: " in all cases.
https://github.com/mozilla/prospector/issues/342

> The categories dissappear too fast on some pages (namely amazon

This should be fixed in v11.

> If I type something and hit tab, it will select the first category. Very
> clever. However, if I start typing now, text will be inserted at the
> beginning of the string.

This allows you to type a term like "mozilla" then hit tab to activate
"[search: ]mozilla" ready for you to type "v<tab>" to end up with
"[videos: ]mozilla". Yes, it trades off the ease of typing part of a
topic, switch categories, then continue adding more to the topic, but
to add more now, you just need to move the cursor to the end of the
input by clicking or pressing <end>.

Ed

Patrick O'Leary

unread,
May 17, 2011, 8:18:33 PM5/17/11
to mozill...@googlegroups.com, Patrick O'Leary
Here's the observed behavior; my keypresses in curly braces:
{[CTRL+L]wi[TAB]}
* A GET with no search string is issued to text.pmtpa.wikimedia.org as plaintext (Request URI: /wiki/Special:Search?search=)
* text.pmtpa.wikimedia.org responds with a 301 Moved Permanently (Location: http://www.wikipedia.org/wiki/Special:Search?search=\r\n)
* A GET with no search string is issued to text.pmtpa.wikimedia.org as plaintext (Request URI: /wiki/Special:Search?search=)
* text.pmtpa.wikimedia.org responds with a 301 Moved Permanently (Location: http://www.wikipedia.org/wiki/Special:Search?search=\r\n)
* my system then initiates a TLSv1 session with secure.wikimedia.org
{b}
* A GET is issued in plaintext to text.pmtpa.wikimedia.org (Request URI: /wiki/Special:Search?search=b)
* text.pmtpa.wikimedia.org responds with a 301 Moved Permanently (Location: http://www.wikipedia.org/wiki/Special:Search?search=b\r\n)
* A GET is issued in plaintext to text.pmtpa.wikimedia.org (Request URI: /wiki/Special:Search?search=b)
* text.pmtpa.wikimedia.org responds with a 301 Moved Permanently (Location: http://www.wikipedia.org/wiki/Special:Search?search=b\r\n)
* my system initiates a TLSv1 session with secure.wikimedia.org
* various GETs begin to be issued in plaintext for various resources from upload.pmtpa.wikimedia.org, with the responses in plaintext
* intermingled with this is a smaller amount of encrypted communication, which I obviously cannot inspect from Wireshark

Note I haven't pressed [ENTER] yet, which should be intended behavior. However, note the following:
{[hover over "search the web" link in ABHD]}
* my system initiates a TLSv1 session with www-google-analytics.l.google.com
* encrypted communication

{eltzner}
* more of the above GET search requests sent in the clear to Wikimedia

{[ENTER]}
* final GET issued in the clear for final search term (with 301 response, repeat, 301 as above)
* TLSv1 session initiated
* encrypted communications (presumably transferring the content of the displayed page)
* FIN/ACK business with text.pmtpa.wikimedia.org

Naturally, copying and pasting the resulting URL (https://secure.wikimedia.org/wikipedia/en/wiki/Special:Search?search=beltzner) causes the session to be handled entirely over TLS/SSL. I suspect what you wanted to see was the result of entering the URL http://en.wikipedia.org/wiki/Special:Search?search=beltzner directly. In this case, HTTPS Everywhere rewrites the URL before submitting the request, and the entire session is conducted over TLS/SSL. The same is done if a link to the non-encrypted version of a supported site is clicked.

I'm not familiar enough with all the available hooks to know why ABHD is getting around the ones that HTTPS Everywhere sets up. The source for the JS component is http://is.gd/sDVPt0. Obviously in an ideal world the plaintext GETs would never happen, which is the primary issue I intended to bring up.

Thanks again for all the hard work and thought you're putting into these projects.
Message has been deleted

jr conlin

unread,
May 26, 2011, 12:50:57 PM5/26/11
to mozill...@googlegroups.com
Sadly, it looks like AwesomeBarHD is continuing a rather annoying feature. When you click in the ABHD, it clears the prior URL, and I don't see a way to get it back. Nice if you're going somewhere else, not so nice if you're trying to correct or otherwise modify the URL.

Since I'll admit that most folks aren't trying to do something like that, it'd be nice if I could easily toggle the behavior (other than going into add-ons and disabling the ABHD).

Edward Lee

unread,
May 26, 2011, 12:56:09 PM5/26/11
to mozill...@googlegroups.com, jr conlin
On Thu, May 26, 2011 at 9:50 AM, jr conlin <jrco...@gmail.com> wrote:
> When you click in the ABHD, it clears the prior URL
If you click on the URL, it'll keep it there for you to edit. Curious,
how wide is your screen? Perhaps there should be some whitespace
dedicated to click the url. The url fades or becomes more opaque
depending on where you're pointing, so having it become darker even
when in the empty area might work.

Ed

jr conlin

unread,
May 27, 2011, 11:59:58 AM5/27/11
to mozill...@googlegroups.com, jr conlin
Fairly wide, but obviously URLs don't tend to fill it. Looks like ^L also does the right thing to, so I can always use that.

I think where things broke for me is just the change in visual behavior. Clicking in the URL bar has never cleared the field (as far as I can remember), so I didn't expect the other actions to have any different effect. I'm not really sure how to better message that. It may just be one of those things like Apple interfaces; it's obvious, once you know about it.

Robert Johnston

unread,
May 30, 2011, 5:01:15 PM5/30/11
to mozill...@googlegroups.com, jr conlin
I'm getting this behaviour too. The "Regular" URL bar always selects the contents of the URL if you click anywhere within it. ABHD selects the URL if you happen to be over the URL, but if you're in a different location it wipes it out. It makes the click target considerably smaller, and much less intuitive, and I can see no reason why it has to be so. I understand you want to include the search accelerator links, so if the insertion point is to the left of them, why not show them anyway?

Sean

unread,
Oct 17, 2011, 7:01:36 PM10/17/11
to mozill...@googlegroups.com
I tried using Awesome bar hd, but one thing I noticed is that searches always open in a new tab.  When using the traditional firefox search bar pressing {enter} opens a search in the current tab, and {alt+enter} opens the search in a new tab.  It seems like it would make sense to carry this behaviour across to the awesome bar hd.
Reply all
Reply to author
Forward
Message has been deleted
0 new messages