- Dillo-dev - lists.mailman3.com

google login redirect

by furaisanjin＠gmail.com

> Does reloading work? Do you mean redirecting? I modified html.cc like this. There is tailing single quotation mark but it seems that dillo ignores it. --- a/src/html.cc Sat Feb 14 10:14:38 2009 +0900 +++ b/src/html.cc Sat Feb 14 17:06:29 2009 +0900 @@ -2898,6 +2898,9 @@ /* Skip to anything after "URL=" */ while (*content && *(content++) != '=') ; + if (*content == '\'') + content++; + /* Send a custom HTML message. * TODO: This is a hairy hack, * It'd be much better to build a widget. */ now I can login by clicking "here". Regards, furaisanjin

Feb. 14, 2009

google login redirect

by corvid＠lavabit.com

furaisanjin wrote: > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > So generated redirect template looks like > > <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> > <td bgcolor='#8899aa' width='100%'> > This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC > (sec 7.4.4) recommends explicitly to avoid it.</td></tr> > <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go > <a href=''http://www.google.com/ ... > > So dillo just navigates to the same page. This is the reason why we can't login. Does reloading work?

Feb. 14, 2009

google login redirect

by furaisanjin＠gmail.com

Hi all. I have noticed that google login redirect is something like this. <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> So generated redirect template looks like <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> <td bgcolor='#8899aa' width='100%'> This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC (sec 7.4.4) recommends explicitly to avoid it.</td></tr> <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go <a href=''http://www.google.com/ ... So dillo just navigates to the same page. This is the reason why we can't login. Regards, furaisanjin

Feb. 14, 2009

[patch] Search Previous

by corvid＠lavabit.com

Jo?o wrote: > Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > > 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. > > > > > > Oh and one more thing. If our purpose is to treat all whitespace equaly > (tabs=Spaces...), why do we _only_ do that when not doing a > case-sensitive comparison? > > A way to verify that (isspace (c1) && isspace (c2)) is causing the fail > is to search for ' ' backwards with case-sens* on --- it finds it. I don't really know that code in any detail whatsoever. I think Johannes implemented it.

Feb. 14, 2009

patch: optgroup for OptionMenu

by corvid＠lavabit.com

I've had this kicking around in my tree for months...finally got around to implementing the max string width for OptionMenu and doing a little polishing. Here it treats optgroup, option, and /optgroup as types of options because when I tried keeping options inside optgroup structures, it turned out to be messier. The idea is that if this is accepted, I will later do some renaming. (Not enabled for ListResource yet because the straightforward approach did not result in something very usable...)

Feb. 14, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > 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. > > Oh and one more thing. If our purpose is to treat all whitespace equaly (tabs=Spaces...), why do we _only_ do that when not doing a case-sensitive comparison? A way to verify that (isspace (c1) && isspace (c2)) is causing the fail is to search for ' ' backwards with case-sens* on --- it finds it. Thanks, Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 14, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > 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. > > OK, I'm not quite sure why we want that, but now I'll try to focus on why it fails with thast particular expression. Thanks for that. Jo?o > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 14, 2009

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