- Dillo-dev - lists.mailman3.com

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

[patch] Search Previous

by jorl17.8＠gmail.com

Qui, 2009-02-12 ?s 19:38 +0000, corvid escreveu: > I updated the UTF-8 sampler search bar screenshot > to show off the nifty new button :) > > Great, thanks! Onto another subject 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. Thanks, Jo?o

Feb. 12, 2009

Close-tab Button

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 06:17:04PM +0100, Hofmann Johannes wrote: > Hello, > > On Thu, Feb 12, 2009 at 06:43:44PM +0200, Rogut?s Sparnuotos wrote: > > Hello, > > > > Some redrawing bug got uncovered with the close-tab button. Open dillo, > > click on bookmarks, hit ctrl-t and ctrl-q - the "km" part of the > > "Bookmarks" tab title is shown in white on the "Clear the URL box". Now > > click ctrl-t and the close-tab button - the whole "Bookmarks" title is > > shown in white over the toolbar. > > In the first case, it is hardly noticeable, but it is when using the new > > button. > > I guess this is http://fltk.org/str.php?L2062 > I'm thinking about the workaround suggested by AlbrechtS. It's a bit > nasty to implement though... Yeah, I'm also not for implementing this. We've had already a tough time with the close-tab button. For the short term, I'd try to ask AlbrechtS for inclusion of his fix in the next FLTK2 release. On the long term, it'd be nice to re-implement tabs without the TabGroup widget inside Dillo (i.e. like the control Panel). This way we can use native fltk widgets and avoid problems. All of this is minor compared with the hidden goal: to avoid having multiple pages rendered at the same time. With dillo's speed we can just save different navigation stacks and render tabs on demand. This would reduce memory footprint to a single page no matter how many tabs are openned. -- Cheers Jorge.-

Feb. 12, 2009

Repush and scroll position

by jcid＠dillo.org

On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > position. This is, if you load a page, start scrolling and the > > > stylesheet arrives after that, it will no longer go back to the > > > top. > > > > > > Please test. > > > > Works for me with Slashdot. Very nice! > > Yes, works great. > > One minor thing, which also happens when going back/forward: > > It seems that the page is first drawn with scroll position 0 and then > immediately scrolled down to the remembered scroll position. > Any ideas where the first redraw comes from? Maybe we can eliminate > that? I thought that with the implementation of cancelQueueDraw(), and the respective call from scrollTo() it would work, but I was wrong. The attached patch implements cancelQueueDraw() and adds some debugging messages that show interesting facts: Nav_open_url: new url='dpi:/bm/' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw Nav_open_url: new url='http://localhost/htdocs/redraw.html' FltkViewBase::cancelQueueDraw() Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw FltkViewBase::cancelQueueDraw() FltkViewBase::cancelQueueDraw() FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw FltkViewBase::draw 1.- There's no need for an explicit call to cancelQueueDraw() from Layout::scrollTo0(). It happens anyway. 2.- For bookmarks there's just one draw() call. 3.- For coming back to a scrolled page, there're four calls!!! 4.- I'm using a test page with no repush(): <html><body><img src="image1.png"><br> <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 </ul></body></html> This could take some time, so I'm handing it back to you now... -- Cheers Jorge.-

Feb. 12, 2009