February 2009 - Dillo-dev - lists.mailman3.com

patch: SELECT size > 1 !multiple

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 07:42:34PM +0000, corvid wrote: > When I was working on the SELECT size code recently, > I enabled using the plain fltk::Browser if > size > 1 and multiple was not set. > > I didn't realize that the callbacks for a plain Browser > and a MultiBrowser behave differently. Committed. -- Cheers Jorge.-

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 02:18:06PM +0100, Hofmann Johannes wrote: > On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > > correctly (check "5.1. Normal Examples"), dillo does not handle > > > relative urls with queries correctly. In case of queries it > > > truncates the filename. Anchors are handled correctly. > > > You can see the difference here: > > > > > > <a href="#foo">#foo</a> > > > <a href="?foo=bar">?foo=bar</a> > > > > Yes, dillo doesn't follow rfc1808.txt. > > > > Dillo follows rfc2396 which updates rfc1808. > > This particular case was changed by it. > > The nice thing about RFCs is that there is so many to choose from :) > > Just found this here: > http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… > After reading it I would suggest to follow RFC 3986 which > reintroduces the old (rfc1808) behaviour which is also consistent > with e.g. firefox. After a more detailed review of rfc3986 there turned out to be more cases with a different resolution than in rfc2396. A new patch was committed. It passes all the tests in rfc3986 plus some more, and also the below quoted page to resolve as Firefox: <HTML> <HEAD> <TITLE>Relative URL test</TITLE> <BASE href="http://a/b/c/d;p?q#f"> </HEAD> <BODY> BASE ="http://a/b/c/d;p?q#f"<br> <a href="#foo">#foo</a><br> <a href="?foo=bar">?foo=bar</a><br> <a href="?foo=bar#frag">?foo=bar#frag</a><br> <a href="">empty</a> </BODY> </HTML> It was very good you spotted this bug! Now this kind of links will work in dillo. e.g. those in http://hg.dillo.org/dillo ;-) @all: Please test. -- Cheers Jorge.-

Feb. 13, 2009

patch: SELECT size > 1 !multiple

by corvid＠lavabit.com

When I was working on the SELECT size code recently, I enabled using the plain fltk::Browser if size > 1 and multiple was not set. I didn't realize that the callbacks for a plain Browser and a MultiBrowser behave differently.

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Fri, Feb 13, 2009 at 02:18:06PM +0100, Hofmann Johannes wrote: > On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > > Hi, > > > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > > correctly (check "5.1. Normal Examples"), dillo does not handle > > > relative urls with queries correctly. In case of queries it > > > truncates the filename. Anchors are handled correctly. > > > You can see the difference here: > > > > > > <a href="#foo">#foo</a> > > > <a href="?foo=bar">?foo=bar</a> > > > > Yes, dillo doesn't follow rfc1808.txt. > > > > Dillo follows rfc2396 which updates rfc1808. > > This particular case was changed by it. > > The nice thing about RFCs is that there is so many to choose from :) > > Just found this here: > http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… > After reading it I would suggest to follow RFC 3986 which > reintroduces the old (rfc1808) behaviour which is also consistent > with e.g. firefox. Given that info, it looks like RFC 3986 is the one to follow. I'll work on it. -- Cheers Jorge.-

Feb. 13, 2009

relative urls

by Johannes.Hofmann＠gmx.de

On Fri, Feb 13, 2009 at 10:07:36AM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > > Hi, > > > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > > correctly (check "5.1. Normal Examples"), dillo does not handle > > relative urls with queries correctly. In case of queries it > > truncates the filename. Anchors are handled correctly. > > You can see the difference here: > > > > <a href="#foo">#foo</a> > > <a href="?foo=bar">?foo=bar</a> > > Yes, dillo doesn't follow rfc1808.txt. > > Dillo follows rfc2396 which updates rfc1808. > This particular case was changed by it. The nice thing about RFCs is that there is so many to choose from :) Just found this here: http://www.communities.hp.com/securitysoftware/blogs/jeff/archive/2007/12/1… After reading it I would suggest to follow RFC 3986 which reintroduces the old (rfc1808) behaviour which is also consistent with e.g. firefox. Cheers, Johannes > > It took me some time to review the issue. A long > time ago I made a test program for the URL resolver > that tests all the examples in rfc2396. The riddle > became clear once I reviewed its tests and the result > for this case was different. ;) > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 13, 2009

relative urls

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 12:23:22PM +0100, Hofmann Johannes wrote: > Hi, > > if I'm interpreting http://www.w3.org/Addressing/rfc1808.txt > correctly (check "5.1. Normal Examples"), dillo does not handle > relative urls with queries correctly. In case of queries it > truncates the filename. Anchors are handled correctly. > You can see the difference here: > > <a href="#foo">#foo</a> > <a href="?foo=bar">?foo=bar</a> Yes, dillo doesn't follow rfc1808.txt. Dillo follows rfc2396 which updates rfc1808. This particular case was changed by it. It took me some time to review the issue. A long time ago I made a test program for the URL resolver that tests all the examples in rfc2396. The riddle became clear once I reviewed its tests and the result for this case was different. ;) -- Cheers Jorge.-

Feb. 13, 2009

Close-tab Button

by onepoint＠starurchin.org

On Thu, Feb 12, 2009 at 02:03:03PM +0000, Jo?o Ricardo Louren?o wrote: > Qui, 2009-02-12 ?s 10:51 -0300, Jorge Arellano Cid escreveu: > > BTW, I'd like to welcome/introduce Jo?o Ricardo. He's a > > developer from Brazil that just joined our team! > > Jo?o Hi Jo?o, welcome aboard! Dillo is a great project to work on. The code is good and the team spirit and mutual respect is good too. I'm sure you'll fit right in! Regards, Jeremy Henty

Feb. 13, 2009

[patch] Search Previous

by corvid＠lavabit.com

Jo?o wrote: > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > Jo?o wrote: > > > I've been trying to understand what's going on in CharIterator::prev() > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > In the following code: > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > (isspace (c1) && isspace (c2)); } > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > according to my tests, is wrecking the search-previous functionality. > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > a tab too (for example)? Maybe I missed the point. :S I think we want to treat something like tab and space as the same.

Feb. 13, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > Jo?o wrote: > > I've been trying to understand what's going on in CharIterator::prev() > > and have been running tests and I have a question regarding iterator.hh. > > > > In the following code: > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > (isspace (c1) && isspace (c2)); } > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > according to my tests, is wrecking the search-previous functionality. > > We do want to regard whitespace chars as equivalent, don't we? > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't 'change' the whitespace, as far as I know. Or do we want to consider ' ' a tab too (for example)? Maybe I missed the point. :S Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 13, 2009

[patch] Search Previous

by corvid＠lavabit.com

Jo?o wrote: > I've been trying to understand what's going on in CharIterator::prev() > and have been running tests and I have a question regarding iterator.hh. > > In the following code: > > inline static bool charsEqual (char c1, char c2, bool caseSens) > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > (isspace (c1) && isspace (c2)); } > > Why are we checking if c1 and c2 are spaces? This is the code that, > according to my tests, is wrecking the search-previous functionality. We do want to regard whitespace chars as equivalent, don't we?

Feb. 13, 2009