- Dillo-dev - lists.mailman3.com

[patch]: Basic Authentication

by onepoint＠starurchin.org

OK, here it is. Please comment. Some observations: When the cache parses the HTTP header we just attach any authentication headers to the cache entry. Nothing else happens until we process the clients. Just before iterating over the clients we check if all the data is in. If it is then we do any necessary authentication. Opening the authentication dialog runs the FLTK event loop, which means that incoming data can call the cache again, triggering CCC warnings. We work around it by deferring the dialog to a timeout so that the cache finishes iterating over the clients before the dialog appears. This is annoying but I don't see a better way at the moment. The authentication dialog does not know which browser window opened the URL so it can't call a_Nav_reload(). Instead I implemented a_Nav_reload_url(). There's an interesting case when the server demands authentication for a realm that we have already authenticated ourselves to. It could be that we didn't send authentication because we didn't know the path was in the realm, or it could be that the authentication we sent was wrong. This requires the code to deduce what it did last time it saw this URL and rely on what it will do the next time. It works, but it feels fragile to me. I would prefer the URL to explicitly record authentication attempts so that the code doesn't have to second-guess itself. Thoughts? I implemented a full token-value list parser as per the RFC. Maybe this is overkill for Basic authentication, but it will be necessary for Digest authentication. Yes, it has gotos; I began by setting flags but decided that gotos were actually cleaner. Maybe it should be rewritten in state-machine style? If the user opens several pages in a realm in a very short time then it is conceivable that multiple authentication dialogs for the same realm could pop up (just like the https DPI sometimes does with certificate dialogs). I don't address this at the moment because I think it won't be a problem in practice. If it needs fixing then we will have to monitor the list of currently open dialogs to avoid duplicates. Regards, Jeremy Henty

Dec. 4, 2008

css progress

by furaisanjin＠gmail.com

Hi, > For now you could set force_my_colors=YES in dillorc. That wold be one way to avoid the problem but another issue is we can't change dillo config on the fly, so I have to start dillo up if I want to do so. If I keep force_my_colors=YES, dillo appearance looks bad. Regards, furaisanjin

Dec. 4, 2008

css progress

by Johannes.Hofmann＠gmx.de

On Wed, Dec 03, 2008 at 11:20:53AM +0900, furaisanjin wrote: > Hi, > > One strong demand is that there are pages whose font color and > background color are same in plain HTML but are changed in CSS. In > this case we can't see any text at all. > > This is one example page. http://www.nhk.or.jp/archives/radiodrama/ For now you could set force_my_colors=YES in dillorc. Regards, Johannes

Dec. 3, 2008

css progress

by furaisanjin＠gmail.com

Hi, One strong demand is that there are pages whose font color and background color are same in plain HTML but are changed in CSS. In this case we can't see any text at all. This is one example page. http://www.nhk.or.jp/archives/radiodrama/ Regards, furaisanjin

Dec. 3, 2008

dialog to change charset

by joerg.sonnenberger＠web.de

On Tue, Dec 02, 2008 at 07:12:45PM +0000, corvid wrote: > > You don't have to hard-code it -- read it on startup, it is not more > > than a mapping between user-visible name (hierachical?) and system > > string. That approach also has the advantage of making it easily > > tweakable for admins/packagers/users. > > You're saying a new file in .dillo/ ? Global configuration file referenced in .dillorc, if you want to override the default: copy & adjust link. Joerg

Dec. 2, 2008

dialog to change charset

by corvid＠lavabit.com

Joerg wrote: > On Tue, Dec 02, 2008 at 04:50:06PM +0000, corvid wrote: > > I hadn't bothered to look at the list in Firefox because I thought > > it would certainly be eight miles -- sorry, kilometres -- long, > > but actually it's not so bad. A list that size could fit into dillo. > > I'll try making one that does as you suggest. > > You don't have to hard-code it -- read it on startup, it is not more > than a mapping between user-visible name (hierachical?) and system > string. That approach also has the advantage of making it easily > tweakable for admins/packagers/users. You're saying a new file in .dillo/ ?

Dec. 2, 2008

dialog to change charset

by joerg.sonnenberger＠web.de

On Tue, Dec 02, 2008 at 04:50:06PM +0000, corvid wrote: > I hadn't bothered to look at the list in Firefox because I thought > it would certainly be eight miles -- sorry, kilometres -- long, > but actually it's not so bad. A list that size could fit into dillo. > I'll try making one that does as you suggest. You don't have to hard-code it -- read it on startup, it is not more than a mapping between user-visible name (hierachical?) and system string. That approach also has the advantage of making it easily tweakable for admins/packagers/users. Joerg

Dec. 2, 2008

dialog to change charset

by corvid＠lavabit.com

Joerg wrote: > On Tue, Dec 02, 2008 at 02:22:03AM +0000, corvid wrote: > > I know that Jorge finds a charset selection dialog where the user > > has to know what to enter to be insufficiently user-friendly, > > but I don't know a nice alternative, and this can go in the > > dillo-dev archives for anyone who wants it. > > You can get a list that is mostly exhaustive by calling "iconv -l". > Note that the list is long and there's no portable way to do that > directly in C. > > An alternative might be to just list the normal encodings and provide a > way to specify one directly. I hadn't bothered to look at the list in Firefox because I thought it would certainly be eight miles -- sorry, kilometres -- long, but actually it's not so bad. A list that size could fit into dillo. I'll try making one that does as you suggest.

Dec. 2, 2008

dialog to change charset

by corvid＠lavabit.com

Johannes wrote: > On Tue, Dec 02, 2008 at 02:22:03AM +0000, corvid wrote: > > I know that Jorge finds a charset selection dialog where the user > > has to know what to enter to be insufficiently user-friendly, > > but I don't know a nice alternative, and this can go in the > > dillo-dev archives for anyone who wants it. > > I never needed to switch the charset, but I noticed that firefox > also has a dialog to do so. > When exactly is this needed and why doesn't automatic detection work > properly? Is it faulty webserver configuration? People don't specify a charset, or put the wrong one. For me, it doesn't make much difference because it'll usually just be the quotation marks and dashes that don't show up properly, but I suspect it matters more for people using languages where the possible encodings are very different. bug#822 requested such a thing, giving http://www.ixbt.com as an example (which does not tell the browser that it's in windows-1251 encoding)

Dec. 2, 2008

dialog to change charset

by joerg.sonnenberger＠web.de

On Tue, Dec 02, 2008 at 02:22:03AM +0000, corvid wrote: > I know that Jorge finds a charset selection dialog where the user > has to know what to enter to be insufficiently user-friendly, > but I don't know a nice alternative, and this can go in the > dillo-dev archives for anyone who wants it. You can get a list that is mostly exhaustive by calling "iconv -l". Note that the list is long and there's no portable way to do that directly in C. An alternative might be to just list the normal encodings and provide a way to specify one directly. Joerg

Dec. 2, 2008

dialog to change charset

by Johannes.Hofmann＠gmx.de

On Tue, Dec 02, 2008 at 02:22:03AM +0000, corvid wrote: > I know that Jorge finds a charset selection dialog where the user > has to know what to enter to be insufficiently user-friendly, > but I don't know a nice alternative, and this can go in the > dillo-dev archives for anyone who wants it. I never needed to switch the charset, but I noticed that firefox also has a dialog to do so. When exactly is this needed and why doesn't automatic detection work properly? Is it faulty webserver configuration? Anyway, if it's useful and other browsers also offer this, why not include it? Cheers, Johannes

Dec. 2, 2008

css progress

by Johannes.Hofmann＠gmx.de

On Tue, Dec 02, 2008 at 08:13:33AM +0900, furaisanjin wrote: > This is great! When will CSS be merged into main dillo? Well, fltk.org is one of the few sites where current CSS prototype improves the look. There is a lot where it gets worse. There also is a noticable reduction in rendering speed depending on the size of the stylesheet. I'd say we wait until automatic stylesheet loading is implemented. Then we can decide whether to merge CSS support. Regards, Johannes

Dec. 2, 2008

dialog to change charset

by corvid＠lavabit.com

I know that Jorge finds a charset selection dialog where the user has to know what to enter to be insufficiently user-friendly, but I don't know a nice alternative, and this can go in the dillo-dev archives for anyone who wants it.

Dec. 2, 2008

css progress

by furaisanjin＠gmail.com

This is great! When will CSS be merged into main dillo? Regards, furaisanjin

Dec. 2, 2008

Re: patch: middle-click submits in new window/tab

by corvid＠lavabit.com

I wrote: > Also, I saw that you can hold down Enter and have > the key repeat submitsubmitsubmitsubmit.... > Perhaps it would be good to change complex button's > handle() from KEY to KEYUP (and try to talk the > FLTKers into a similar change for Button). I discovered that KEYUP causes a problem: If a page has a complex button, - right click to pop up page menu. - select show source - press enter to close it. the complex button is usually a submit button, and so somehow the keyup reaches it and triggers a submit. So, uh, never mind my keyup idea.

Dec. 1, 2008

css progress

by corvid＠lavabit.com

Johannes wrote: > http://freehg.org/u/dillo/css-prototype now contains an extended CSS > parser that can handle more complex CSS selectors. > With this, some other changes, manual stylesheet download, and > some tweaking, the fltk homepage looks like this: > > http://www.ecademix.com/JohannesHofmann/tmp/dillo-fltk.png Nice! :)

Dec. 1, 2008

css progress

by Johannes.Hofmann＠gmx.de

Hi, http://freehg.org/u/dillo/css-prototype now contains an extended CSS parser that can handle more complex CSS selectors. With this, some other changes, manual stylesheet download, and some tweaking, the fltk homepage looks like this: http://www.ecademix.com/JohannesHofmann/tmp/dillo-fltk.png Cheers, Johannes

Dec. 1, 2008

empty html elements

by corvid＠lavabit.com

Johannes wrote: > Hi, > > while working on css I came across the following: > > <a class="d" name="INCR32"/> (found at [1]) > > dillo currently doesn't recognize that the element is empty. > The relevant code is at html.cc:3530: > > /* Test for </x>, ReqTagClose, <x /> and <x/> */ > if (*start == '/' || /* </x> */ > html->ReqTagClose || /* request */ > (tag[tagsize - 2] == '/' && /* XML: */ > (isspace(tag[tagsize - 3]) || /* <x /> */ > (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* <x/> */ > > > We could simply drop the requirement for the blank before '/' which > would lead to > > /* Test for </x>, ReqTagClose, <x /> and <x/> */ > if (*start == '/' || /* </x> */ > html->ReqTagClose || /* request */ > (tag[tagsize - 2] == '/')) { /* XML */ > > > or allow a '"' instead of the blank or keep things as they are, if > XML requires a blank before the '/'. > >From http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags > I'd say the blank is optional. > > What do you think? Yes, it looks like whitespace is optional there. EmptyElemTag ::= '<' Name (S Attribute)* S? '/>' S ::= (#x20 | #x9 | #xD | #xA)+ > [1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port…

Dec. 1, 2008

empty html elements

by Johannes.Hofmann＠gmx.de

Hi, while working on css I came across the following: <a class="d" name="INCR32"/> (found at [1]) dillo currently doesn't recognize that the element is empty. The relevant code is at html.cc:3530: /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/' && /* XML: */ (isspace(tag[tagsize - 3]) || /* <x /> */ (size_t)tagsize == strlen(Tags[ni].name) + 3))) { /* <x/> */ We could simply drop the requirement for the blank before '/' which would lead to /* Test for </x>, ReqTagClose, <x /> and <x/> */ if (*start == '/' || /* </x> */ html->ReqTagClose || /* request */ (tag[tagsize - 2] == '/')) { /* XML */ or allow a '"' instead of the blank or keep things as they are, if XML requires a blank before the '/'. >From http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags I'd say the blank is optional. What do you think? Cheers, Johannes [1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port…

Dec. 1, 2008

Re: patch: middle-click submits in new window/tab

by corvid＠lavabit.com

Jorge wrote: > On Fri, Nov 28, 2008 at 10:08:21PM +0000, corvid wrote: > > > Now if I go to: > > > > > > http://www.dillo.org/bugtrack/Dremove.html > > > > > > and fill the entries with the keyboard, then TAB to the submit > > > button and press ENTER, nothing happens. > > > > > > Doing the same, with the unpatched version, works OK here... > > > > Here's one with the widgetCallback stuff changed in fltkui.cc > > > > Middle click submits in new tab was committed! > > With this minor changes: > > * A compiler warning fix > * An event_key() test instead of event_button() because the > latter may return garbage. It may be safer. events.h show both of them returning e_keysym -- although, given the changes you made in fltkui.cc, it does naturally make sense to use event_key. > BTW, now it submits with Enter but not with Space. Yes, I'd noticed that the buttons were written to make Space submit, which surprised me a bit. Also, I saw that you can hold down Enter and have the key repeat submitsubmitsubmitsubmit.... Perhaps it would be good to change complex button's handle() from KEY to KEYUP (and try to talk the FLTKers into a similar change for Button).

Nov. 30, 2008

Re: patch: middle-click submits in new window/tab

by jcid＠dillo.org

On Fri, Nov 28, 2008 at 10:08:21PM +0000, corvid wrote: > > Now if I go to: > > > > http://www.dillo.org/bugtrack/Dremove.html > > > > and fill the entries with the keyboard, then TAB to the submit > > button and press ENTER, nothing happens. > > > > Doing the same, with the unpatched version, works OK here... > > Here's one with the widgetCallback stuff changed in fltkui.cc > Middle click submits in new tab was committed! With this minor changes: * A compiler warning fix * An event_key() test instead of event_button() because the latter may return garbage. It may be safer. BTW, now it submits with Enter but not with Space. -- Cheers Jorge.-

Nov. 30, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

On Fri, Nov 28, 2008 at 06:51:48AM +0000, corvid wrote: > Jeremy wrote: > > ... if I show the dialog from inside Cache_process_queue() just > > before it iterates over the clients then something *still* runs > > asynchronously while the dialog is up, ... What now? > > I don't know CCC either. > I wonder whether the original patch gave that warning with 0.8.x. The original patch was slightly different in that the dialog was part of the bw structure. Rather than port that approach I decided to go the way suggested by the earlier discussion between Jorge and Christian. Anyway, here's a version that seems to work. It defers both the dialog and the reload to a timeout. Unfortunately we no longer have a reference to the browser window so it calls a new function a_Nav_reload_url() that reloads all browsers displaying the URL. It removes CA_Reload and bw->reload_level since they're now unnecessary. It's actually quite straightforward, the only clunkiness is using the timeout and a_Nav_reload_url(), but that seems to be necessary. Now I just have do the actual authentication. Regards, Jeremy Henty

Nov. 28, 2008

Basic Authentication: what's happening here?

by corvid＠lavabit.com

Jeremy wrote: > On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote: > > Jeremy wrote: > > > Is there any way to stop this happening, or do I have to postpone > > > showing the dialog until Cache_process_queue() runs? > > > > Postponing it sounds right to me. > > Unfortunately, if I show the dialog from inside Cache_process_queue() > just before it iterates over the clients then something *still* runs > asynchronously while the dialog is up, which gets me a warning from > the CCC about a call on a finished chain, followed by a segfault when > I confirm the dialog and reload the browser window. If I delay the > reload even further by doing it from inside a timeout then I still get > the warning, but not the segfault. (Amended patch attached.) I don't > understand the CCC well enough to know what I should be doing here. > What now? I don't know CCC either. I wonder whether the original patch gave that warning with 0.8.x. > When I was doing this from a DPI it all happened asynchronously and I > ended up writing a a_Nav_reload_url() that reloaded all the browsers > for a gicen URL. I thought that was pretty hacky but maybe it's the > only way to make this work?

Nov. 28, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

On Fri, Nov 28, 2008 at 01:30:05AM +0000, corvid wrote: > Jeremy wrote: > > Is there any way to stop this happening, or do I have to postpone > > showing the dialog until Cache_process_queue() runs? > > Postponing it sounds right to me. Unfortunately, if I show the dialog from inside Cache_process_queue() just before it iterates over the clients then something *still* runs asynchronously while the dialog is up, which gets me a warning from the CCC about a call on a finished chain, followed by a segfault when I confirm the dialog and reload the browser window. If I delay the reload even further by doing it from inside a timeout then I still get the warning, but not the segfault. (Amended patch attached.) I don't understand the CCC well enough to know what I should be doing here. What now? When I was doing this from a DPI it all happened asynchronously and I ended up writing a a_Nav_reload_url() that reloaded all the browsers for a gicen URL. I thought that was pretty hacky but maybe it's the only way to make this work? Regards, Jeremy Henty

Nov. 28, 2008

Basic Authentication: what's happening here?

by corvid＠lavabit.com

Jeremy wrote: > OK, after reviewing the links people sent in (thanks!) and the > discussion at [1] I decided not to create a DPI. > > I've hit a strange problem with getting the page to reload after the > user confirms the user/password dialog. I show the dialog in > Cache_parse_header() by calling fltk::Window::exec() and set a new > CA_Reload flag (which is just like CA_Redirect, but simpler) if the > user confirms. Cache_process_queue() then handles the CA_Reload. > *But* Cache_process_queue() runs before the window is closed, and > therefore before the flag is set. It looks as though the rest of the > data comes in asynchronously while the dialog is still showing. If I > change a_Auth_do_auth() to return immediately instead of showing a > dialog then Cache_process_queue() runs after the flag is set, as I > would expect. > > Is there any way to stop this happening, or do I have to postpone > showing the dialog until Cache_process_queue() runs? Postponing it sounds right to me.

Nov. 28, 2008

Basic Authentication: what's happening here?

by onepoint＠starurchin.org

OK, after reviewing the links people sent in (thanks!) and the discussion at [1] I decided not to create a DPI. I've hit a strange problem with getting the page to reload after the user confirms the user/password dialog. I show the dialog in Cache_parse_header() by calling fltk::Window::exec() and set a new CA_Reload flag (which is just like CA_Redirect, but simpler) if the user confirms. Cache_process_queue() then handles the CA_Reload. *But* Cache_process_queue() runs before the window is closed, and therefore before the flag is set. It looks as though the rest of the data comes in asynchronously while the dialog is still showing. If I change a_Auth_do_auth() to return immediately instead of showing a dialog then Cache_process_queue() runs after the flag is set, as I would expect. Is there any way to stop this happening, or do I have to postpone showing the dialog until Cache_process_queue() runs? Patch attached if you wish to experiment (it doesn't do authentication but it demonstrates the problem with the dialog). Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005023.html

Nov. 28, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Wed, Nov 26, 2008 at 06:39:56AM +0900, furaisanjin wrote: > This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) > contains the original BASIC auth path Thanks, that's very useful. Jeremy Henty

Nov. 27, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by furaisanjin＠gmail.com

Hi, This page (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz.html) contains the original BASIC auth path (http://linux.ee/~mzz/dillo/0.8.0/dillo-0.8.0-mzz-auth.diff.gz) i18n patch contains lots of small patches there and it's not easy to pick up one of them. Regards, furaisanjin

Nov. 25, 2008

experimental patch: tooltip decodes urlencoded Location

by corvid＠lavabit.com

For example, if you go to el.wikipedia.org, it redirects to http://el.wikipedia.org/wiki/%CE%9A%CF%8D%CF%81%CE%B9%CE%B1_%CE%A3%CE%B5%CE… and the location tooltip shows that this means http://el.wikipedia.org/wiki/?????_??????

Nov. 25, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Sat, Nov 22, 2008 at 03:39:06PM +0100, Johannes Hofmann wrote: > Debian seems to ship dillo with a patch for basic authentication: > http://patch-tracking.debian.net/patch/series/dl/dillo/0.8.5-4.1/01_i18n Thanks for the link but, yikes, it's a 1.5M patch that does i18n, tabs, auth and the kitchen sink too! It also does a fair amount of reorganisation, eg. factoring a lot of stuff into a DilloDoc struct. I'll dig into it when I start doing the auth stuff but it's a lot to wade through. (Unfortunately the auth.[ch] files in this patch are just wrappers: the actual auth implementation is elsewhere and I haven't tracked it down yet.) Regards, Jeremy Henty

Nov. 25, 2008

css todo

by Johannes.Hofmann＠gmx.de

Hi, here's the current todo list: * convert more of html.cc and form.cc to the new style handling. see Html_tag_open_a() as an example. Basically every style change that happens due to an HTML attribute (e.g. bgcolor="black") should be handled by passing a corresponding hint in CSS form to the styleEnginge using the setNonCssHints() methods. This way these attributes can be overridden e.g. by the user stylesheet as defined in the CSS standard. Other styling that is fixed for the HTML element in question (e.g. font size changes caused by <small>) should be replaced by corresponding entries in the user-agent stylesheet (see CssContext::buildUserAgentStyle()). There is an example user-agent stylesheet at http://www.w3.org/TR/CSS21/sample.html One of the more complex parts to convert is list handling (Html_tag_open_li()). * Reenable shaded colors as default for table borders. However CSS21 states (http://www.w3.org/TR/CSS21/box.html#border-color-properties) "If an element's border color is not specified with a border property, user agents must use the value of the element's 'color' property as the computed value for the border color." Not sure what to do here. What do you think? * Switch "width" and "height" handling from dw::core::style::Length to CssLength. Problem is how to handle relative lengths as they occur in Html_parse_length_or_multi_length(). They don't seem to exist in the CSS model. * Remove functions from html.cc that are now empty (e.g. Html_tag_open_em()). DilloHtml should be able to handle NULL for TagOpenFunct and TagCloseFunct of TagInfo. Or we could use a default function. * Enhance the CSS parser (or tokenizer) to properly ignore CSS comments. * Enhance the CSS parser to handle more complex CSS selector definitions (see http://www.w3.org/TR/CSS21/selector.html) * Figure out how to implement more complex selectors in the CssSelector class. At the same time think about how to speed up selector matching (currently on every opening tag all selectors are checked). Cheers, Johannes

Nov. 23, 2008

css-prototype repository has moved

by Johannes.Hofmann＠gmx.de

Hi, at freehg.org I created a new account "dillo" which now holds the css-prototype repository and a copy of current cvs which I will update regularily: http://freehg.org/u/dillo/css-prototype http://freehg.org/u/dillo/main Cheers, Johannes

Nov. 23, 2008

shaded colors and css

by corvid＠lavabit.com

Johannes wrote: > mapping css properties to dw::core::style::Style members went very > smooth, because Style was obviously implemented with css in mind. > > Just for the shaded color thing I can't find a corresponding concept > in css. > What exactly is the definition of a shaded color? Is it just a bit > darker than the normal one? > Does anyone know the corresponding concept in css? I had figured the shaded colors were just for giving tables and rulers a three-dimensional appearance.

Nov. 23, 2008

New developers?

by corvid＠lavabit.com

Jorge wrote: > Some people have written me expressing their will to join as > developers. They have introduced themselves, asked questions and > for some advice. I've answered, hinted and made suggestions. > Since all of them have remained silent, I wonder whether they are > concentrated studying the code, or simply changed their mind... Maybe the answers/suggestions should always go on the website somewhere so that you don't have to repeat yourself to people who just disappear. [So much ink has been spilled in the free software world over the years about being very very welcoming -- usually in the context of why women have better things to do than contribute to free software -- and I can really see now why those involved in projects might not roll out the parades and fireworks until seeing attempts at patches or at least detailed discussion...]

Nov. 22, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Nov 20, 2008 at 04:08:21PM +0000, Jeremy Henty wrote: > On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote: > > On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > > > > > Is this a good way to do it or is there a smarter way? All > > > comments and advice are welcome. > > > > It looks OK. > > Good! > > > I wonder why a dpi is deemed necessary for this. > > I don't know whether it is necessary. That's why I asked for > comments. I just thought that HTTP authentication looked rather > "cookie-ish" and decided to copy and modify the cookies > implementation. I'm new to this part of Dillo so I am following > established practice. I already have a dummy auth dpi running and > hooked into the main Dillo program, so I think that the dpi part of > things is by far the easiest bit. The most work is actually > implementing authentication! Debian seems to ship dillo with a patch for basic authentication: http://patch-tracking.debian.net/patch/series/dl/dillo/0.8.5-4.1/01_i18n Might be worth looking at. Cheers, Johannes

Nov. 22, 2008

shaded colors and css

by Johannes.Hofmann＠gmx.de

Hello, mapping css properties to dw::core::style::Style members went very smooth, because Style was obviously implemented with css in mind. Just for the shaded color thing I can't find a corresponding concept in css. What exactly is the definition of a shaded color? Is it just a bit darker than the normal one? Does anyone know the corresponding concept in css? Cheers, Johannes

Nov. 22, 2008

New developers?

by jcid＠dillo.org

Hi, Some people have written me expressing their will to join as developers. They have introduced themselves, asked questions and for some advice. I've answered, hinted and made suggestions. Since all of them have remained silent, I wonder whether they are concentrated studying the code, or simply changed their mind... Are you still there? -- Cheers Jorge.-

Nov. 22, 2008

[jcid@dillo.org: Re: CSS merge looks great!]

by jcid＠dillo.org

On Sat, Nov 22, 2008 at 01:15:56PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 21 Nov 2008 14:11:23 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Hi Jorge, > > > > > > On Thu, Nov 20, 2008 at 02:31:19PM -0300, Jorge Arellano Cid wrote: > > > > Hi Johannes, > > > > > > > > After sometime finally I'm back to CSS. So far the merged code > > > > looks great. I'd like to make this the official branch soon. > > > > > > Great! But I still consider the CSS support a prototype and I think > > > it's time to step back for a moment and consider what we've learned > > > so far. > > > > OK. > > > > As CSS is the most demanded feature, I was thinking along the > > lines of making a release that implements a small subset of CSS, > > to let the world know that the main pieces are already coded, and > > to attract more developers to help completing it. > > > I really hope there will be a switch to *disable* css parsing. > In my opinion there are a lot of sites which are more usable on > mobile devices or devices with unusual screen sizes (800x480 like the eeepc) > without CSS. Yes, that's simple to do. Even more, currently (i.e. with the mercurial repository) you can specify *your* CSS stylesheet in ~/.dillo/style.css, and tailor it for your needs. As remote stylesheet loading isn't hooked yet, you can see the desired effect now. > I can really remember cases where I switched from firefox to dillo > because css (or its interpretation by firefox?) was so bad that I even cannot > click on some links. > > But if course, in more cases having css is really great! > > > For instance, if just colors were working OK (i.e. rendering > > looked better with CSS-colors support), that's be a good starting > > point. > > Yes, colors would be nice. That would probably give the opportunity to write > small patches for e.g. font support in CSS without the need for deep conceptual > decisions. So that can be a starting point for developers which are not that > deep in the code yet. That's the idea! -- Cheers Jorge.-

Nov. 22, 2008

[jcid@dillo.org: Re: CSS merge looks great!]

by akemnade＠tzi.de

Hi, On Fri, 21 Nov 2008 14:11:23 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > Hi Jorge, > > > > On Thu, Nov 20, 2008 at 02:31:19PM -0300, Jorge Arellano Cid wrote: > > > Hi Johannes, > > > > > > After sometime finally I'm back to CSS. So far the merged code > > > looks great. I'd like to make this the official branch soon. > > > > Great! But I still consider the CSS support a prototype and I think > > it's time to step back for a moment and consider what we've learned > > so far. > > OK. > > As CSS is the most demanded feature, I was thinking along the > lines of making a release that implements a small subset of CSS, > to let the world know that the main pieces are already coded, and > to attract more developers to help completing it. > I really hope there will be a switch to *disable* css parsing. In my opinion there are a lot of sites which are more usable on mobile devices or devices with unusual screen sizes (800x480 like the eeepc) without CSS. I can really remember cases where I switched from firefox to dillo because css (or its interpretation by firefox?) was so bad that I even cannot click on some links. But if course, in more cases having css is really great! > For instance, if just colors were working OK (i.e. rendering > looked better with CSS-colors support), that's be a good starting > point. Yes, colors would be nice. That would probably give the opportunity to write small patches for e.g. font support in CSS without the need for deep conceptual decisions. So that can be a starting point for developers which are not that deep in the code yet. Greetings Andreas Kemnade

Nov. 22, 2008

A warning about HTTPS and proxies

by corvid＠lavabit.com

In the dillo 2.0 dillorc, I had written that HTTPS uses wget, and that configuring wget to use a proxy would therefore send https traffic through it. That's wrong; I was repeating outdated information. Right now, HTTPS will not use a proxy at all. I bring this to your attention in case it matters to those using Tor and the like. ------ In other news, have you noticed that the dillo website is particularly speedy now? Andreas turned on HTTP compression :)

Nov. 21, 2008

[Johannes.Hofmann@gmx.de: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[jcid@dillo.org: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[Johannes.Hofmann@gmx.de: Re: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

[jcid@dillo.org: CSS merge looks great!]

by jcid＠dillo.org

FYI, -- Cheers Jorge.-

Nov. 21, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Jorge wrote: > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. I think it was gentoo that was having an inbuf_t detection problem.

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

On Thu, Nov 20, 2008 at 09:14:56AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > > > Is this a good way to do it or is there a smarter way? All > > comments and advice are welcome. > > It looks OK. Good! > I wonder why a dpi is deemed necessary for this. I don't know whether it is necessary. That's why I asked for comments. I just thought that HTTP authentication looked rather "cookie-ish" and decided to copy and modify the cookies implementation. I'm new to this part of Dillo so I am following established practice. I already have a dummy auth dpi running and hooked into the main Dillo program, so I think that the dpi part of things is by far the easiest bit. The most work is actually implementing authentication! > Isn't an implementation of a_Dialog_user_passwd() enough to solve > it? It certainly appears to be the missing link, in the sense that everything else that authentication needs is the kind of thing that the cookies dpi already does and therefore counts as a solved problem already. I plan to continue with the dpi-based implementation on the grounds that the biggest part of the task is implementing authentication and a_Dialog_user_passwd(), and that code will not depend on whether we do authentication in the dillo main program or a dpi. If we decide to move authentication out of the dpi and into dillo itself then I will just move the authentication code around and delete some dpi wrapper code, which won't be much work. At least that's how I expect it will work. Stay tuned, and please comment further. Jeremy Henty

Nov. 20, 2008

a list of what dillo2 runs on

by ljmoore＠wightman.ca

On Thu, Nov 20, 2008 at 09:12:35AM -0300, Jorge Arellano Cid wrote: > On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > > My system isn't representative of any mainstream (debian on a m68k ) but > > will download from cvs, compile and soforth when prompted. > > What system do you have? > > I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, > that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. > > -- > Cheers > Jorge.- It's a Macintosh Quadra 610 which has been running debian since the woody release At the moment, the unofficial etch-m68k with some lenny packages. As I said, rather non-standard. -- "I don't think I've found God, but I may have seen where gods come from." Terry Pratchett

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by jcid＠dillo.org

On Thu, Nov 20, 2008 at 02:42:19AM +0000, Jeremy Henty wrote: > > I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd > appreciate comments on how I'm doing it. > > (Motivation: (a) I'm tired of the irony of having to use Firefox to > log on to the FLTK Trac Wiki to update the Dillo page, (b) this will > be a useful primer for hacking on the https dpi.) > > The problem is that the dpi must prompt the user for a username and > password but src/dialog.cc only supports dialogs that present a choice > of buttons. > > I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to > create a modal dialog, return the clicked button and write the > contents of the dialog entries into a struct. Then I can add a > wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That > will let the dpi query the user. > > Is this a good way to do it or is there a smarter way? All comments > and advice are welcome. It looks OK. I wonder why a dpi is deemed necessary for this. Isn't an implementation of a_Dialog_user_passwd() enough to solve it? -- Cheers Jorge.-

Nov. 20, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Wed, Nov 19, 2008 at 08:01:49PM -0500, Larry Moore wrote: > On Tue, Aug 26, 2008 at 05:52:43PM +0000, corvid wrote: > > Christopher Illies wrote: > > > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > > > I wonder whether we could get someone for each system who > > > > would have the responsibility (or, let's say "_glory_" :) > > > > of responding to "Hey, we changed [some configuration stuff] > > > > in the latest CVS. Does it work fine on your system?" messages. > > > > > > I can take that part for FreeBSD for now and will respond when such > > > messages are posted to this list. Also, I can do a fresh compile every > > > two weeks or so. > > > > Cool! > > > > > My system isn't representative of any mainstream (debian on a m68k ) but > will download from cvs, compile and soforth when prompted. What system do you have? I'm thinking in the "inbuf_t" wrongly detected for a BSD flavour, that has a patch in CVS, and AFAIR hasn't been acknowledged to work yet. -- Cheers Jorge.-

Nov. 20, 2008

Q: Thoughts on a user/password dialog for an HTTP AUTH dpi?

by onepoint＠starurchin.org

I'm implementing an HTTP AUTH dpi (based on the cookies dpi) and I'd appreciate comments on how I'm doing it. (Motivation: (a) I'm tired of the irony of having to use Firefox to log on to the FLTK Trac Wiki to update the Dillo page, (b) this will be a useful primer for hacking on the https dpi.) The problem is that the dpi must prompt the user for a username and password but src/dialog.cc only supports dialogs that present a choice of buttons. I think I'll have to add a_Dialog_user_passwd() to src/dialog.cc to create a modal dialog, return the clicked button and write the contents of the dialog entries into a struct. Then I can add a wrapper for it to src/dpiapi.c and hook it into a_Capi_ccc(). That will let the dpi query the user. Is this a good way to do it or is there a smarter way? All comments and advice are welcome. Regards, Jeremy Henty

Nov. 20, 2008