- Dillo-dev - lists.mailman3.com

want to test some experimental cookies code?

by corvid＠lavabit.com

In recent days, I've been making a version of cookies dpi that follows the current cookies draft of the http state working group. I haven't tested it exhaustively yet, but if anyone who uses cookies wants to try it and watch the msgs and so on, let me know. As for how much validity or meaningfulness this draft has, let's see... - They've made the decision to describe the way things currently behave, having learned from the bitter experience of others who made RFC 2109 and RFC 2965*. In 2010, no one has any way to be King of Cookies. They write testcases and try all of the major browsers and decide what they want to write down in their spec when there are differences. - On their mailing list, from the user agents, they have an opera guy, the curl guy, and someone related to firefox, although I didn't take any notice of whether he has a position of authority in firefox or not. - Of course there will be changes. Smallish, I think. A cookie set without an explicit domain goes only to that domain. A cookie with a domain attribute is sent to that domain and any subdomain. A .domain attr cookie can go to domain. As for how to decide to reject cookies for, e.g., .co.uk, I don't think they're ever going to say too much. A cookie can be set for any path, regardless of the url path of the page setting it. Paths are matched when selecting cookies to return, though. Path-matching does work by slashes instead of simple prefixes. An http page can set a secure cookie (just like currently). An example of the little things that may change are that a cookie that is just VALUE instead of NAME=VALUE is currently allowed, but it's not decided for good yet. There are corner cases such as this that maybe they could make illegal without rendering themselves irrelevant. * To be precise, the main author of the RFCs has written that it was at least initially reasonable to think that what they were putting together in rfc 2109 would be adopted by user agents.

Jan. 5, 2010

table/cursor oddity

by Johannes.Hofmann＠gmx.de

On Mon, Jan 04, 2010 at 01:19:37AM +0000, corvid wrote: > A little bug that I just stumbled upon. > > <table border=1> > <tr><td style="cursor:help">one<td style="cursor:wait">two<td>three > <tr><td colspan=3>row > </table> > > The style of the first td seems to be the style of the whole table. > > (I wasn't surprised that the text has the default cursor, since I > know there's that weirdness with wordStyle and regular style. > Speaking of which, is it spelled out anywhere what is going on with > that exactly? I know there have been times when I've been in the area > of the table code and some reason why it's necessary has become clear, > but I don't think I've ever had the whole shape of the matter in my head.) > > Hmm. I just changed the first td to style="cursor:help; color:red", > and it colored the first td correctly, and now the rest of the table > shows the wait cursor. Interesting. Should be fixed now. Turned out to be a stupid bug in style.cc.

Jan. 5, 2010

css :visited and security

by Johannes.Hofmann＠gmx.de

On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > The other day, I saw another of those pages about using :visited and > display in order to allow others to learn whether the user has visited > a page. (I remember Johannes pointing to a page about this last year, too.) > > I wonder whether it would be sensible to have a dillorc option defaulting > to NO for whether to use :visited. Yes, that sounds good. We should distinguish between remote / embedded CSS and user agent and user stylesheet though. For the latter two we don't need any restrictions. We might also do some other restrictions on remote CSS in the future, e.g. possible dillo specific extensions should also be only accessible via the user agent and user stylesheet.

Jan. 5, 2010

css :visited and security

by corvid＠lavabit.com

The other day, I saw another of those pages about using :visited and display in order to allow others to learn whether the user has visited a page. (I remember Johannes pointing to a page about this last year, too.) I wonder whether it would be sensible to have a dillorc option defaulting to NO for whether to use :visited.

Jan. 5, 2010

Query on Dillo browser supporting "frames"

by corvid＠lavabit.com

Rajesh wrote: > Will Dillo2 browser support "Frames" in future ? IF yes, what is the > time frame for that release ? I'm not aware of any particular plans to work on it, but of course I'm sure a good patch that integrates well with the existing code would be gladly accepted...

Jan. 5, 2010

Javascript

by iveqy＠iveqy.com

Hi, I'm a big dillo fan and a fltk user. Dillo is the fastest browser I ever seens and I strongly like it (too bad fltk 1.3 isn't used but that I believe is to blame the fltk team for). Anyway, now that CSS is almost done, I wonder how the future for javascript support looks. The old discussions I found about this looks to be outdated with the CSS changes. I also found a patch to allow javascript in dillo, but that patch didn't seemed to use the dpi-interface. Would it be possible to use dpi to use the v8 enginge for dillo? -- Regards iveqy

Jan. 5, 2010

Query on Dillo browser supporting "frames"

by rmarathe＠i-rode.com

Hi, Will Dillo2 browser support "Frames" in future ? IF yes, what is the time frame for that release ? regards, Rajesh Marathe.

Jan. 5, 2010

table/cursor oddity

by Johannes.Hofmann＠gmx.de

On Mon, Jan 04, 2010 at 01:19:37AM +0000, corvid wrote: > A little bug that I just stumbled upon. > > <table border=1> > <tr><td style="cursor:help">one<td style="cursor:wait">two<td>three > <tr><td colspan=3>row > </table> > > The style of the first td seems to be the style of the whole table. > > (I wasn't surprised that the text has the default cursor, since I > know there's that weirdness with wordStyle and regular style. > Speaking of which, is it spelled out anywhere what is going on with > that exactly? I know there have been times when I've been in the area > of the table code and some reason why it's necessary has become clear, > but I don't think I've ever had the whole shape of the matter in my head.) If there is e.g. <div style="background-color:red">foo</div> dillo creates a textblock widget for the <div>, which will have a style set with backgoundColor red. Then the word foo is added. The question is what style should the word get? If it would get the same style as the textblock, we would draw a red background for each word again, which is unnecessary as the textblock has a red bg already. More important, it would simply be wrong for things like borders. We want the border around the whole <div>, not around each word. So basically for words we use the style of the containing textblock with resetValues() called plus some minor modifications to make things like <span style="background-color:red">foo</span> work, where <span> does not add a new widget to the textblock (this is the inheritBackgroundColor stuff). > > Hmm. I just changed the first td to style="cursor:help; color:red", > and it colored the first td correctly, and now the rest of the table > shows the wait cursor. Interesting. Interesting indeed :-) I will have a look at this. Cheers, Johannes

Jan. 5, 2010

table/cursor oddity

by corvid＠lavabit.com

A little bug that I just stumbled upon. <table border=1> <tr><td style="cursor:help">one<td style="cursor:wait">two<td>three <tr><td colspan=3>row </table> The style of the first td seems to be the style of the whole table. (I wasn't surprised that the text has the default cursor, since I know there's that weirdness with wordStyle and regular style. Speaking of which, is it spelled out anywhere what is going on with that exactly? I know there have been times when I've been in the area of the table code and some reason why it's necessary has become clear, but I don't think I've ever had the whole shape of the matter in my head.) Hmm. I just changed the first td to style="cursor:help; color:red", and it colored the first td correctly, and now the rest of the table shows the wait cursor. Interesting.

Jan. 4, 2010

patch: handle cookie time overflow

by corvid＠lavabit.com

Jeremy wrote: > On Wed, Dec 30, 2009 at 07:32:19PM +0000, corvid wrote: > > > ... but maybe you will know a nicer calculation, or a portability > > subtlety that I should handle. > > > [...] > > +#define DILLO_TIME_MAX ((time_t) ((1UL << (sizeof(time_t) * 8 - 1)) - 1)) > > Quoting "man -S 0p types.h" > > * time_t and clock_t shall be integer or real-floating types. > > So at least in theory you should not assume that time_t is an integer > type. I've no idea how likely that is to be wrong in practice. (On > my system time_t is long.) Unfortunatly "man sysconf" does not > describe any maximum time value constant. Hmm... well, at least it wouldn't be any worse than it already is! There's a bunch of time_t <-> long in dpi/cookies.c.

Jan. 2, 2010