type "mozilla" into toolbar & hit return.
wait for DNS lookups of "mozilla" to fail, then see "keyword:mozilla" get sent
to the google keyword server.
keyword:mozilla is displayed in URL bar when search page loads
In mozilla, the URL of the actual search page result is displayed.
I don't really care if it does that, I'm just noting it because it is part of my
tests. I think IK is too transparent in Mozilla trunk, because that emulated
Communicator's design, and the result was a lot of confusion and
misunderstanding about how it worked.
We're actaully handing off to a search but using the keyword backend to make
that handoff. Not sure if it matters too much. Blake?
Asa and I figured this out while talking today.
I have a personal keyword server, and sometimes it would leave keyword: in the
URL bar and other times it doesn't...
In Netscape 7, the keyword server is returning a HTTP redirect, that contains
the search URL. This overwrites the URL bar, as well as causing the search query
In Phoenix, the google server is simply returning a search page result directly.
So is this a bug?
Nobody has shown me any design specs for keyword: so how about "I don't care?"
I think, from the perspective of URL bar, it should display the actual URL that
was gotten, so maybe the answer is yes?
We've dropped the keyword search as a feature and moved to Google's I'm feeling
lucky. Searching happens in the search field now. That renders this issue moot.
I'll modify my test suite to reflect this.
While updating the IK documentation for mozilla/mozilla, I realized that I
should have bugged you about one last point:
If you want searching to go on ONLY in the search bar, what you really want to
do is turn this feature OFF, by flipping the "keyword.URL" pref.
I've written the documentation to reflect the current state of affairs for now.
I finally had a chance to look at Phoenix 0.4 w/ Jag today.
I think in 0.3 or 0.4, the default got changed to google's "I got lucky" engine,
which returns a URL redirect.
I didn't realize what asa REALLY meant in his last comment, which was that he
had change the keyword.URL value to something that made this go away.
VERIFIED Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030714