Closed Bug 314788 Opened 20 years ago Closed 20 years ago

[website] Add "hidden pref" note about search in location bar

Categories

(Camino Graveyard :: Product Site, enhancement)

Product:
Camino Graveyard
Component:
Product Site
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Camino1.0

People

(Reporter: mgelfo, Assigned: samuel.sidler+old)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1 No actual URL can have whitespace in it. As such, the presence of white space in a string entered into the location bar should be interpreted as a search request. That string should be sent to the default search engine for the browser. This could be a hard-coded default search (it's currently Google), or the user could specify keyword "default" for whatever search bookmark they would like to use as their default. Reproducible: Always This (wonderful) feature is a part of Sogudi (http://www.atamadison.com/w/kitzkikz.php?page=Sogudi), and ever since I switched from Safari to Camino I'm so sad that I can't use it anymore.
i swear we already have this filed somewhere.
(In reply to comment #1) I originally emailed it as a feature request, then read on the camino website that only submissions to bugzilla would be processed. (Thanks for paying attention!) I may end up downloading the source and adding this myself, in which case it should probably be on here anyway.
To add clarity: The decision tree for parsing a URL should be: Does it contain whitespace? If no, parse as normal URL If yes, does the first word match a search keyword? Yes: send rest of string to that search keyword. No: Send entire string to default search.
This does feel like a dupe to me, but... We'd have to be sure to allow whitespace after the tld. For example, I can have a website at http://www.anywebsite.com/test test test/test test.html. Camino would translate the whitespaces as "%20"s to be read by the interweb.
> We'd have to be sure to allow whitespace after the tld. For example, I can have > a website at http://www.anywebsite.com/test test test/test test.html. Camino > would translate the whitespaces as "%20"s to be read by the interweb. I don't think Camino should translate spaces into %20 -- that seems really weird and arbitrary to me. A well-formed URL doesn't contain any whitespace. Allowing users to type whitespace in place of %20 might lead to some serious confusion (if they ever use any other browser). If anything, Camino's behavior should probably conform to RFC 1738 (on URLS): In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. I would hate to paste a broken-up URL and get a bunch of %20's replacing the unintended spaces. But, I think that's irrelevant -- either doing things the way Camino does now (replacing spaces with %20) or following the RFC URL guidelines, I'm assuming there's still a point where the parsing procedure goes "okay, not a URL, I'll try to parse it as a keyword search", and if that doesn't work, then you get the invalid URL message. I suggest a third stage, so that you'd only get an invalid url if you typed something that matches the scheme for a URL but is somehow bad (bad characters like { and }, etc.)
Dupe... *** This bug has been marked as a duplicate of 310771 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
No. Your quoted RFC snippet refers to the representation of URLs in content, and your browser-switcher argument backfires because all other significant browsers accept spaces in the path part of a URI. This behavior can't and won't change. Camino currently behaves correctly when pasting whitespace selected from other applications by stripping newlines and leading spaces on each component line. Mid-line whitespace oughtn't be mucked with. This is ancillary to this bug, as you point out. Keyword-based searches could be cool here. (I find myself using them occasionally when in the fox.) Oh, it's a dupe.
Actually, I don't think this is a dupe. Bug 310771 is about keyword.enable, this seems to be more about what Firefox calls "smart bookmarks."
We already allow for "smart bookmarks" when they're specified correctly.
> We already allow for "smart bookmarks" when they're specified correctly. Right, and they're wonderful! This is a feature request for a default "smart bookmark" that's triggered when the text entered in the location field isn't a URL and doesn't trigger another smart bookmark. I think that would make things even better. I also think that my feature request is unique (in the bugzilla database, at least) and this should not be marked as a duplicate. Neither Firefox nor Camino does this (looks like Bug 310771 says Firefox implements the functionality requested) although Safari+Sogudi does this. Out of respect for actual members of the development community, I won't personally reopen this feature request but do ask that more consideration is given to it.
Let me make sure I understand what you're asking... User A enters "test me now" in their location bar. Camino looks to see if "test" is a smart bookmark so it can apply the "me now" to it. If it's not, it searches using the default search engine (Google) and brings up the results page. If the above is what you're requesting, that's covered in the duped bug and can be set using the hidden pref, but the devs didn't think this should be on by default (per the other bug).
> If the above is what you're requesting, that's covered in the duped bug and can > be set using the hidden pref, but the devs didn't think this should be on by > default (per the other bug). I see now, I very much didn't understand the other bug report and didn't know what the hidden preference was even called that everyone was talking about (and mis-describing). That's exactly what I want, and am happy to proclaim this thread dead (although it would be nice if this feature was documented somewhere or visible in preferences).
I can almost guarantee it won't be made into a pref in the UI. That said, you're right. It should be documented. Reopening as a Product Site bug and taking ownership.
Status: RESOLVED → UNCONFIRMED
Component: Location Bar & Autocomplete → Product Site
Resolution: DUPLICATE → ---
Assignee: mikepinkerton → bugzilla
QA Contact: bugzilla
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Whitespace in typed URL should trigger default search → [website] Add "hidden pref" note about search in location bar
For posterity (because the related bug is unclear about this): This functionality does exist in Camino, and can be manually enabled by going to about:config and setting keyword.enable to true. The default search engine can be changed by modifying the keyword.URL parameter.
Fixed. (Beneath blinking/marquee pref) http://www.caminobrowser.org/support/sup_hiddenprefs.html
URL: http://www.caminobrowser.org/support/...
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → Camino1.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.