Re: reworked web search
On Sun, May 25, 2014 at 03:12:01PM +0100, Chris Young wrote: On Sun, 25 May 2014 11:32:42 +0100, Vincent Sanders wrote: The search is behaving oddly - I'm getting two (and always two) garbage characters on the end of my search string. So, if I search for netsurf on Google I get something like: http://www.google.com/search?q=netsurfO%FC hmm. that is strange (honest i did test this with the gtk frontend!) is this soemthing to do with how the search term is extracted on amiga? search_web_omni() is supposed to take the search term it is given and substitute it into the search url. I've fixed it, the URL wasn't getting NULL-terminated. I guess on your test platform the memory allocation was zeroed, but here it wasn't. Thankyou very much Chris!. Dumb error on my part, sorry about that. May I ask if (aside from the dumb mistakes) the feature is working as expected now? It ought to have removed any delays if the network was unable to fetch the search providers icons and made the whole thing more robust. I do not know if you are aware of the search_url_bar boolean option which is supposed to control search behaviour on input to the search_web_omni() operation. The heuristics for deciding if a search term is a url are still a little inadequate but I am working on them. This should eventually allow us to have a url bar which mostly does the right thing and perhaps a simple additional button for search for this term, do not try to interpret as a url -- Regards Vincent http://www.kyllikki.org/
Re: reworked web search
On Sun, May 25, 2014 at 10:34:59AM +0100, Steve Fryatt wrote: On 25 May, Vincent Sanders wrote in message 20140525001056.gy27...@kyllikki.org: I have completely reworked the web search functionality in the core of the browser. The new API is much simpler and robust. Currently only two frontends (GTK and Amiga) use the functionality but I hope now that it is so much simpler to use other maintainers might implement it for their frontends. Is this the search field in the toolbar? For some reason I'd got the idea from discussions on here or IRC that it had been deprecated, which is why I never bothered to implement it on RISC OS. The main reason for re-writing the toolbar code was to make it easier to add stuff like this (and tabs, of course). I'll have another look, time permitting. This was more a combination of utterly awful code and API previously coupled with the idea we could simply make the url bar input much smarter about search without having a separate search input consuming space in the toolbar. I just explained in the reply to Chris how that might work. If i can work out a clean way to do this I will be extending the GTK UI to make the search input box toggle appearance alongside the search_url_bar option. Thus you would be able to type urls and search terms into the single url bar and simply have it do the right thing (a bit like chrome or firefox) -- Regards Vincent http://www.kyllikki.org/
Re: reworked web search
On Tue, 27 May 2014 11:06:20 +0100, Vincent Sanders wrote: May I ask if (aside from the dumb mistakes) the feature is working as expected now? It ought to have removed any delays if the network was unable to fetch the search providers icons and made the whole thing more robust. It seems fine, other than not picking up the icon on some occasions. Actually, I had a thought about that - is it fetching, and not notifying the frontend when the new icon is ready? I do not know if you are aware of the search_url_bar boolean option which is supposed to control search behaviour on input to the search_web_omni() operation. Yes, I was aware of that. I think I decided against it due to the inclusion of a separate search bar. The heuristics for deciding if a search term is a url are still a little inadequate but I am working on them. This should eventually allow us to have a url bar which mostly does the right thing and perhaps a simple additional button for search for this term, do not try to interpret as a url That sounds like a good minimalist NetSurfy approach. Chris
Re: IDNA2008 - take 2
On 27 Mar 2014 20:54:57 +0100, Chris Young wrote: OK, second attempt at international domain name support. Branch: chris/idna2008 I've had to import some unrestricted code from elsewhere, due to the necessity of Unicode normalisation and other things. It is working and conforming to the spec, as far as I read it. A couple of minor issues/todos: 1. If an invalid URL is encountered during page layout/box conversion, NetSurf gives a BoxConvert warning and the page is never displayed. This is caused by my new code making nsurl_create return NSERROR_BAD_URL when an IDN fails the compliance checks. I've not been able to work out where in the core this error code is terminating page layout. Page showing this problem: http://blogs.msdn.com/b/shawnste/archive/2006/09/14/idn-test-urls.aspx 2. If a frontend wants to display the UTF-8 version of an IDN then currently the URL needs stripping into component parts, the host run through idna_decode() and the whole thing put back together again. This should probably be handled by nsurl but I'm not sure of the best way to implement it. 3. There are some to-dos noted in code comments for further compliance checking. They are optional in the spec, and I don't see any need to implement them - anything invalid will be rejected by DNS. Most of the mandatory checks seem overkill anyway, given that there is stricter checking at DNS registration time. I have included the optional decode-reencode check for already encoded addresses to weed out any undecodeable nonsense the user might have typed in, but it doesn't bother to do normalisation or validity checking of the decoded address before re-encoding it (maybe it should, I'm not sure, the spec was vague on this point). Is there any interest in reviewing/merging this now 3.1 is out of the way? I'm thinking point 2 above might also tie in with Vince's proposed changes to extract escaped path elements from an nsurl, as it is a similar challenge. Chris
