#7596 closed bug (fixed)
entering URLs manually for local files yields a google search
Reported by: | ribbonz | Owned by: | leavengood |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
open Terminal
echo "file one" > ~/Desktop/file1
echo "file two" > ~/Desktop/file2
you now have two small text files on the desktop
open WebPositive
place the icons for the two new files so that they can be
seen while the browser window is up
drag file1 into the Web+ window -- its contents are displayed
drag file2 into the Web+ window -- same thing
so far, it's all good
if you use the back and forward navigation arrows, you can
see the contents of each file just fine.
again, it's all good at this point
now go up into the URL text field and manually edit the text
e.g.
'file:///boot/home/Desktop/file2' is displayed
so try go to the end of this URL, back up over the '2' and
type in a '1' so that you get
'file:///boot/home/Desktop/file1' and then press ENTER
instead of loading the text file, it gives you a Google search
on that file
'http://www.google.com/search?q=file:///boot/home/Desktop/file1'
of course, it will do this on any local file that you try to
enter via the URL text field, even when giving it a perfectly
valid 'file://' URL to load,
the {file1, file2} scenario was just for demonstration
if this is by design, I don't understand the logic of it
Web+ revision: 577
Haiku version: hrev41667
Change History (7)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
This is just due to my super simple and therefore stupid attempt to mimic Google Chrome's "Omnibar". I think the general logic is to do a Google search if there are no periods in the URL, hence your discovery. Obviously it needs to be a bit smarter with file:// URLs. I never expected my stupid hack to stay so long unchanged, but my Haiku dev time has been minimal this year.
Thanks for the bug report! I should be able to fix it and #7599 before building WebPositive for the alpha3 release.
comment:3 by , 13 years ago
Thanks Ryan!
personally, I don't like things like that -- i.e. having a search query take place without my requesting it
it's too jarring ("what the... where did that come from?" reaction)
however, I LOVE the Google search field that Firefox has at the upper right
that's a case of *knowing* that I'm trying to search for something
but you've probably had requests for that feature any number of times, so I'll leave it alone
comment:4 by , 13 years ago
FWIW I like the feature very much, and it also shouldn't be too hard to get it right ;-)
ribbonz: btw in Chrome you can give your search engines shortcuts, ie. you could type "ox man" in your "omni" box, and it will do a search for "man" in the Oxford Dictionary if you configured it that way. That's much faster and flexible than having to select the right search engine with the mouse each time.
comment:5 by , 13 years ago
I definitely intend to extend this feature quite a bit and will probably mimic Chrome pretty closely. One aspect of Chrome which may help you ribbonz is the drop-down which indicates exactly what will happen with the current entry. It lets you know that for example "toy story" would search Google for "toy story" or for Axel's example that "ox man" will search the Oxford dictionary for man. I will try to provide something similar.
Part of this requires the addition of OpenSearch support for having something like searching the Oxford dictionary or Youtube or whatever, and having each of those discoverable on their respective web-sites and then configurable with keywords, etc. I already started a bit of a prototype to parse the XML format of OpenSearch.
Unfortunately my Haiku development time has been limited lately, and my highest Web+ priority at the moment is getting it built for alpha3. But like I said above I'll try to fix this too, since it is pretty annoying.
comment:6 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This was fixed quite simply in WebPositive r579 by just not doing my "smart URL handling" for file URLs.
comment:7 by , 13 years ago
Version: | R1/alpha3 → R1/Development |
---|
R1 Alpha 3 has not yet been released. This was with an R1 Alpha 3 Release Candidate image.
update:
I overstated the case when saying "any local file" would generate the problem
actually, it's just files without extensions
duplicate the test above, only call the files "file1.xxx" and "file2.xxx" and the files will load properly without generating the google search
any extension on the file seems to do the trick, even an empty one (e.g. "file1.")