Closed Bug 186964 Opened 22 years ago Closed 18 years ago

Allow (and parse) keywords in "Home Page" and "Search Page" preferences

Categories

(Camino Graveyard :: Preferences, enhancement, P3)

Product:
Camino Graveyard
Component:
Preferences
Platform:
PowerPC
macOS
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX
Milestone:
Camino1.5

People

(Reporter: bugzilla, Assigned: sfraser_bugs)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021225 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021225 Chimera/0.6+

Please allow the Home and Search pages to contain keywords. 

This would allow:

*) The use of bookmarked tabsets for homepages

*) Using a search for the contents of the location bar by simply clicking the
Search button.


The preferences currently allow URLs. By simply passing the contents of these
two boxes to the same routine that is processed upon pressing enter in the
Location bar, it should be easy to allow the interpretation of keywords. In
addition, please be sure to pass the contents of the Location bar to the keyword
so that it can be used in %s substitution.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
It's worth noting that implementing this feature will also allow for the
behavior desired in bug #186965
I was asked to respond to this bug, and I must admit that it got me all confused.

bug 186965 is about allowing the %s identifier for url keywords known from
bookmark keywords, so that a search page of "http://www.google.com/search?q=%s"
will allow you to enter "Chimera" into the location bar and click on the "Search
Homepage" button, and it'll translate into
"http://www.google.com/search?q=Chimera". I do understand that, and I did
confirm the bug.

What is *this* bug about, then?

"This would allow:

*) The use of bookmarked tabsets for homepages"

Howso? There is currently no way I know of to access entries from the bookmarks
file through a URL, especially considering that Chimera has its own proprietary
bookmarks format for whatever reason.

"*) Using a search for the contents of the location bar by simply clicking the
Search button."

Isn't that what bug 186965 is already about?

Please explain the difference of these two bugs to me. Thanks.
Sorry for any lack of clarity.

> Howso? There is currently no way I know of to access entries from the 
> bookmarks file through a URL, especially considering that Chimera has its own
> proprietary bookmarks format for whatever reason.

You wouldn't have to access the bookmark file itself. Basically what I am
looking for is the ability to have a keyword in the Search or Home Page box
within Preferences and have Chimera interpret it the same way as if I'd entered
it in the Location bar.

Example:

I have a bookmark to "http://www.cnn.com" and I give it the keyword "home". In
Chimera's Preferences I enter the keyword "home" in the Home Page box instead of
a full URL. When I click the Home button in the toolbar, Chimera would examine
the preference, realize it's a keyword, and then execute it through the keyword
engine, thus bringing up "http://www.cnn.com". Seems a bit redundant for only
one page, but if you have a bookmarked tabset (i.e. four different pages you
view every morning) with the keyword "home", then Chimera interprets the keyword
and opens up the four pages on four tabs whenever you click the Home button,
which would be pretty cool and something I'd requested in the past (the ability
to have a bookmark or a bookmarked tabset as my homepage), but seemed like a
large technical hurdle (in the past). Now we have keywords and it should be
pretty easy to implement.

/* 
It's worth noting here that if you had a bookmarked tabset as your homepage, you
should not enable the preference "Load the homepage when opening New Tabs" 
*/

Taking this a step further, it should be possible to pass the contents of the
Location bar for %s expansion by the keyword for the Search Page entry.

Example:

I have a bookmark for "http://www.google.com?q=%s" with a keyword of "?". In
Chimera's preferences I set my Search Page to "?". Upon clicking the Search
button, Chimera examines the preference, realizes it's a keyword, sends it to
the keyword engine, which in turn would expand the URL and use the contents of
the Location bar to replace the %s in the URL. So if I had "test" in my Location
bar and then clicked the Search button, Chimera would open
"http://www.google.com?q=test".

Hope that cleared it up for you.
> Isn't that what bug 186965 is already about?
> 
> Please explain the difference of these two bugs to me. Thanks.


Bug #186965 is for allowing %s expansion in URLs entered into the Search or Home
Page preferences. The bug wants to bring the ability to enter information into
the Location bar and have it replace the %s in a URL entered into the Search or
Home Page preference.

Example:

In the Search Page preference you type "http://www.google.com?q=%s". Later, you
want to search for something, you type "taco" in the Location bar and click the
Search button. Chimera would replace the %s in the URL with the contents of the
Location bar ("taco"), resulting in a URL of "http://www.google.com?q=taco". It
would then enter this URL. The final result is that you used the Search button
to actually search for the contents of the Location bar, instead of opening up a
search page and entering some criteria to search for (or using a keyword).


This bug is for allowing keyword use in these same places. By allowing the use
of keywords, you gain the ability to have a bookmarked tabset as your homepage
(as described in my last entry). You'd also gain the behavior desired in the
other bug (as described in my last entry).


As far as searching goes, both bugs would have the same end result. Mine would
require a little more initial work to configure (you'd have to know how to setup
a keyword), but would also bring the potential for bookmarked tabsets to the
table. I explained the potential for the Home page entry, let me go a step
further for the Search entry:

I have a bookmarked tabset with three search engines' URLs in it
(http://www.google.com?q=%s, http://search.yahoo.com/bin/search?p=%s,
http://search.msn.com/results.asp?RS=CHECKED&FORM=MSNH&v=1&q=%s). The bookmarked
tabset has a keyword of "?". In Chimera's preferences, I enter my Search Page as
"?". Upon clicking the Search button, Chimera would examine the preference,
realize it is a keyword and forward it to the keyword engine. The keyword engine
would take the contents of the Location bar and use it to replace %s in each of
the three URLs. It would then open the three URLs on separate tabs within a
single window. I have effectively used the contents of the Location bar to enter
my query criteria and then clicked the Search button to have it do the work.
Yes, I understand now. I'm not sure if this isn't too complicated for Chimera.
I'll let someone else decide.
> Yes, I understand now. I'm not sure if this isn't too complicated for Chimera.
> I'll let someone else decide.

I don't know that it's particularly complicated... We have keywords now; it's
allowing the use of a keyword instead of a URL in the preferences. I'm honestly
surprised it didn't work the first time I tried it. Maybe it could be phrased as
"Why does the Location bar interpret keywords, but I can't enter a keyword as my
Home or Search Page in the preferences?" Perhaps I'm just not explaining myself
well...
See bug 185985.
I think all URL fields must react in the same way, no matter where they are.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Allow the "Home Page" and "Search Page" preferences to contain keywords → Allow (and parse) keywords in "Home Page" and "Search Page" preferences
So, 

1.
a) iff (if and only if) the user puts a keyword into the home/search page pref,
then they can gain the benefit of using a tabset as their home/search page.

and

2.
a) iff they put a keyword in there, 
b) and iff there is a %s in the URL of the home/search page, 
c) and iff there is content in the URL bar when "Go Home" or "Go Search"
then the URL bar content will be used for the %s in loading the keyword

Correct?
I agree with comment #7, this changes the behaviour of text in the URL bar, even
if it's only in a very rare and user-intentional way, I think that's a Bad Thing.
Comment 8: yes, that's what I understand.
To Comment #8: Yes, that is what I'm looking for.
i agree that we should probably do this for completeness sake since we allow
this in other parts of the UI. however, it shouldn't be high priority or
complicate the already convoluted url dispatch logic.

if someone can make a nice clean patch (emphasis on clean), i think it's worth
taking this to round out the keyword support we already offer. if we're gonna do
it at all, why only go part way? of course, i really don't think we should be
doing keywords at all, but i'm easily beaten down.
> i agree that we should probably do this for completeness sake since we allow
> this in other parts of the UI. however, it shouldn't be high priority or
> complicate the already convoluted url dispatch logic.

I actually have a side question on this. I've noticed that Chimera can open a 
URL based on entry into the URL field on the toolbar, through command line, as 
well as dispatch through bookmarks. From what I saw, each of these has a fairly 
similar chunk of code. Why not create a single function for all interface 
elements to use to open URLs and just code keyword support right into that? 
Let's clear up the convolusions...

> if someone can make a nice clean patch (emphasis on clean), i think it's worth
> taking this to round out the keyword support we already offer. if we're
> gonna do it at all, why only go part way? of course, i really don't think we 
> should be doing keywords at all, but i'm easily beaten down.

I have this implemented for the Home portion as follows:

*) In the home: method (the one run when clicking the Home button) I have 
copied some of the code out of the goToLocationFromURLField method. I have 
keyword support working. It pulls the contents of homePage from 
PreferencesManager and then passes it to the resolveBookmarksKeyword method of 
BookmarksManager. It then displays the resulting URL. If the result is a series 
of URLs, it will break them out onto tabs. Thus allowing for a bookmarked 
tabset as your homepage. In addition, previous functionality remains, so a 
standard URL can be entered in the Preferences.

*) In the createNewTab method, I have it working similar to above. The main 
difference is that on creating a new tab the last page of a bookmarked tabset 
is displayed. This prevents overwriting existing tabs with the contents of the 
Home button (This is only handled if the browser is set to load the homepage on 
creating a new Tab anyway).

I am currently working on getting it to work upon creating a new window as 
well. It will load a complete tabset in new windows.

My main problem with implementing the Search button's functionality is that I 
am unsure of how to pull the contents of the Location bar into a variable (I'm 
pretty new to Objective C, but I understand enough to copy and paste the above. 
I've coded in other languages and am now just learning ObjC). Once I have the 
contents it will be easy to append it to the results of searchPage (in 
PreferencesManager) and sending the whole thing to resolveBookmarksKeyword.
I could probably nail bug #185985 while I'm in there.
Priority: -- → P3
Target Milestone: --- → Camino1.1
This is waaay too geeky for even 90% of Camino users, and likely very difficult to do cleanly.

Home page as tab group is bug 189930.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Verified WONTFIX.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.