- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] small politically incorrect html parser patch

by Madis Janson

On Tue, 27 Jan 2004, Madis Janson wrote: > > when you want to use dillo for browsing instead of html test tool, then > this little patch is useful for many stupid webs, which randomly close > or not close font tags whenever happens and whereever happens... > sorry for spam, but in the mean time i (re)found better one... diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in dillo-tab/src/html.c dillo/src/html.c --- dillo-tab/src/html.c 2004-01-25 04:37:21.000000000 +0200 +++ dillo/src/html.c 2004-01-27 04:27:18.000000000 +0200 @@ -1176,7 +1183,8 @@ static void Html_tag_cond_cleanup(DilloH while (stack_idx && strcmp(Html_tags_get_name(html->CurrTagIdx), html->stack[stack_idx].tag) && - (old_mode || + ((old_mode && + !Html_match_tag(html->stack[stack_idx].tag, "table>", 6)) || Html_tags_get_endtag(html->stack[stack_idx].tag_idx) == 'O')){ --stack_idx; e_pop = 1; and to the dillorc file: use_old_parser=YES only note: when you use it, don't whine to list that it renders something incorrectly - look the output with use_old_parser=NO and you'll probably discover why...

Jan. 27, 2004

small politically incorrect html parser patch

by Madis Janson

when you want to use dillo for browsing instead of html test tool, then this little patch is useful for many stupid webs, which randomly close or not close font tags whenever happens and whereever happens... diff -pru -x CVS -x configure -x 'aclocal*' -x 'Makefile*' -x config.h.in dillo-tab/src/html.c dillo/src/html.c --- dillo-tab/src/html.c 2004-01-25 04:37:21.000000000 +0200 +++ dillo/src/html.c 2004-01-27 04:27:18.000000000 +0200 @@ -4280,7 +4372,7 @@ static const TagInfo Tags[] = { {"dt", 'O', Html_tag_open_dt, Html_tag_close_par}, {"em", 'R', Html_tag_open_em, Html_tag_close_default}, /* fieldset */ - {"font", 'R', Html_tag_open_font, Html_tag_close_default}, + {"font", 'O', Html_tag_open_font, Html_tag_close_default}, {"form", 'R', Html_tag_open_form, Html_tag_close_form}, {"frame", 'F', Html_tag_open_frame, Html_tag_close_nop}, {"frameset", 'R', Html_tag_open_frameset, Html_tag_close_default}, It makes a bit less likely, that the font tags screw up every other one (like tables and forms)...

Jan. 27, 2004

Dillo cookies

by pete

I am getting this error with Dillo 0.8.0: [pete@happy:.dillo, 07:25 PM, Mon Jan 26]> dillo dillo_dns_init: Here we go! The cookies file has a file lock: disabling cookies in this dillo! Nav_open_url: Url=>about:splash< How do I go about 'unlocking' this file? It was working initially with 0.7.3 Thanks, -- Pete http://milneweb.com http://nomorevirus.com

Jan. 27, 2004

Re: [Dillo-dev] An odd request, I know...

by Tom Barnes-Lawrence

Incidentally, I'm familiar with getting 2 copies of various emails when people reply to both me and the list... but *3*? That's just confusing. On Mon, Jan 26, 2004 at 03:08:32PM +0100, Thorben Thuermer wrote: > On Sat, 24 Jan 2004 00:04:06 +0000 > Tom Barnes-Lawrence <tomble(a)usermail.com> wrote: > > -I understand you not wanting the referer info being sent, even if > > it does make the logs from my hit-counter a bit less useful, *but*, > > some sites do seem to use the referer tags to work out if you're > > accessing their images, etc deep-linked from some other page. > > I'm afraid I can sort of sympathise with this, as the idea of > > "stealing bandwidth" does have quite a lot of truth in it (it > > does cost them money). > > there is one important detail there that i think is very important: > even if you want to avoid image linking by checking referers, you > should allow EMPTY referers... Are we considering empty referers to be the same as no referers? > that way: > a) linking the images will still fail with the majority of browsers > b) browsers that don't send referers will still work. Probably. I have a strange image of *all* browsers ending up sending no referers in order to be able to see remotely hosted images, but I rather doubt that would happen, so you're probably right here. > c) users can for example post a link to a image on irc or > whereever and the link will work (this is something that makes > users like me really hate your site) You hate my site? Wah! But seriously (*unless* you're meaning "your" as in "anybody's"), I know Angelfire *used* to block images on no referers, but I noticed recently that Dillo *was* showing the few images I had on my pages, and after reading your comment today, I copy-pasted the URL of my site's logo into Dillo. Showed up fine. I don't know if you just assumed that Angelfire was still doing that but you hadn't notice since you'd patched your copy of Dillo, or if you'd just thought that my site wasn't downloading all the graphics (there are only about 3 on the whole site, 5 if you count thumbnails as different to their full-size images). > d) users can use download programs to download files off the site without > having to send fake referers (wget --referer, anybody?) Yeah, I'm familiar with *that*... > (and to control those, there's robots.txt) I know what robots.txt is for, how does it apply here? Are you talking about a download program that gets the *whole* site? > imho not allowing the referer to be empty is just stupidity > on the side of the people setting up the filtering, and it just Perhaps it just didn't occur to them? They want to keep their bandwidth costs down, so they'd be worrying more about that issue than supporting an obscure little niche browser like ours (even if it is lovely). > makes their own problems worse, by forcing people to send > fake referer headers (like my dillo does for QUITE some time now). > > (the patch is trivial, just add pairs of > + "Referer: http://%s%s/\r\n" > + URL_HOST(url), s_port->str, > into src/IO/http.c (and don't get the order wrong)) Hey, that's neat, thanks! I was considering doing something like this myself (but wouldn't know where to start). > > So, I'd love it if the bookmarks code stuck each section in its own > > page, and let me nest one section in another. > isn't this is kind of the point of seperating stuff into dpis?: > if you don't like the default one, you can relatively easily > change it without having to deal with the browser code or even > recompile it. Uh, yes, I know. Apart from the fact I got the impression the DPI interface was unstable (as in changing, not crashing) at the moment, I pointed out that I was quite busy right now, and wasn't sure of some of the details, either. I find working with other peoples' code fairly daunting, personally. Perhaps that's lack of experience. Tom Barnes-Lawrence

Jan. 26, 2004

my.yahoo.com

by pete

Hi all, I am now running the CVS version of Dillo. I am seeming to have a lot of lockups with it. Now I know this is common with CVS but is this something that should be mentioned here? Just wondering what is the proper thing to do. Another, I am still trying to access my yahoo with it but still not possible. Am I missing something that I need to do or is this just typical for Yahoo? -- Pete http://milneweb.com http://nomorevirus.com

Jan. 26, 2004

Thanks!

by Arjen Meek

Just a quick "thank you" to all Dillo-devs here. It has replaced Firebird as my default browser less than 5 minutes after installing it. Some experiences: - Dillo combines perfectly with the Ion window manager. A browser shouldn't have to perform window manager tasks, and tabbed browsing becomes a rather silly concept when a sensible window manager combines with a sensible browser. - 0.7.3 compiles & runs cleanly on my 60 Mhz HP PA-RISC system (712/60 running Debian Woody-hppa), and actually renders pages faster on that system than Firebird does on my 600 Mhz Athlon. - A suggestion: why not have CTRL+L switch focus to the URL bar when it is visible, instead of popping up a dialog box? Keep up the good work! Arjen

Jan. 26, 2004

Dillo IRC

by pete

Good morning, Is there an IRC channel for Dillo at this time? And of course the next question where is it or why not? Thanks, -- Pete http://milneweb.com http://nomorevirus.com

Jan. 26, 2004

Re: [Dillo-dev] An odd request, I know...

by Jorge Arellano Cid

On Sat, 24 Jan 2004, Tom Barnes-Lawrence wrote: > Hi again, > On Mon, Jan 19, 2004 at 06:29:16PM -0300, Jorge Arellano Cid wrote: > > > Firstly, I'd like to say I've been using Dillo for over 2 years now, > > > and find it fantastic. Well, apart from a few little details (which > > > I'll probably post to the list in a couple of days, when I'm less > > > busy). So anyways, very well done for this piece of software! > > > > Thanks for your comments. A long time user, that's good news! > > Hehe, you haven't heard my complaints yet ;) Don't worry, they're > not so bad, and I'm not going to go making demands. Here you go: > > -I understand you not wanting the referer info being sent, even if > it does make the logs from my hit-counter a bit less useful, *but*, > some sites do seem to use the referer tags to work out if you're > accessing their images, etc deep-linked from some other page. > I'm afraid I can sort of sympathise with this, as the idea of > "stealing bandwidth" does have quite a lot of truth in it (it > does cost them money). > So, perhaps (as someone else suggested) Dillo could have some > button or menu option, etc that we could click to allow the > referer tags to be set temporarily for pages that need them? > Or alternatively, images on pages could automatically have the > referer tags set for them, or they could be used for accessing > *any* other file on the same server perhaps. Just thoughts. > > -It's great that the cache is used so aggressively with static > content, it keeps things very very fast, keeps the network > usage down, and is very useful when the connection goes down; > but it does seem to get used in many places where it really > shouldn't, such as dynamic content (revisit certain CGI scripts > and you just get the cache), and that problem with images- where > if a screenful of images stops loading, refreshing will *not* reload > the half-done images. > OTOH, it's *good* that dynamic content doesn't get reevaluated when > I press the *back* button. That's a PITA when other browsers do that, > as I usually just want to go back to where I was before. After considering it through the time, I believe that the problem with referer and the cache issue, can be solved using a similar technique to what we use with cookies. Unfortunately some standards allow for easy abuse of the technologies they describe. Sometimes it is the same RFC the one that warns about the problems that may arise! For instance image request with referer (as you suggest) is the basis for a spying technology widely known as web bugs. Allowing our cache to honour http cache directives blindly, would allow sites to send a refresh request on each of their advertising banners (and they usually get paid for request so this practice is very common). That's the reason why going back or forward in history is a PITA with browsers that follow them. Keeping Dillo as it is now, and allowing the user to site-tune it with regard to cookies, cache and referer is a solution that solves a broad range of problems. > > -It's probably because I'm using a snapshot of 0.8.0-pre from about > November with Frank's tabs patch (OK maybe the tabs patch doesn't > affect this), but once or twice I've found my load average go way > up, and looking at PS, found dpid spawning the https plugin > repeatedly (with each one dying again so there was only ever one > at a time). IIRC this happened (some time) after quitting Dillo. > Perhaps this is one of the things you've fixed since then. Yes, I fixed that. > -MOST important to me: Bookmarks. I like the way Dillo now has > bookmarks shown as a web page instead of a menu, I like that it allows > us to put them into categories, and I like that the DPI system allows > the bookmarks to be controlled by a separate program. > Unfortunately, bookmarks are still one of the main reasons I still > use Konqueror (despite the stupid crashes): I have lots of them, > last time I tried to work it out I calculated maybe a thousand- > and a great many of these are *not* pr0n! The only way I can cope > with so many of them is having them organised into a very deep > heirarchy. But not only does Dillo's bookmarks program not allow > this, but it has every single bookmark shown on the same page! The > scrollbar control is tiny! > So, I'd love it if the bookmarks code stuck each section in its own > page, and let me nest one section in another. Perhaps the current > version is only temporary, so you'd have time to work on other > stuff, and all this is already planned, but I thought I ought to > mention it because *this* is one thing that would really make > Dillo great for me. I'd have a go at this myself, but I've already > got lots of other things to do. OK, I suppose you do as well. Yes, I have much more to do than what I can cope with. So I sort it by priority and work on the top. As Thorben remarked, a very important point of dpis is to allow for multiple implementations of them. This is reinforced by the fact that writing a dpi doesn't require knowledge about dillo's internal working. With bookmarks, it keeps the bm list in memory, so making it to return the section list (in whatever format) and to bind each section with a page specific for it, is a one day effort. Testing it to work reliably and comfortably takes more time. If someone comes with a better implementation of bm, it may end as the default and the current one as an option. > That's it, really. For me, the problems are definitely oughtweighed > by Dillo's good points, like the stability and speed, I just want > to be able to use it a lot more! Stability!, thanks for the comment. It takes a great effort from our team to keep it stable. That's the unsexy work of chasing bugs, polishing the code, commenting, careful patch reviewing, and thoughtful design. Cheers Jorge.-

Jan. 26, 2004

Mailing list

by Jorge Arellano Cid

Hi Thorben! Is good to see you around. You've surely noticed I recently switched dillo-dev to only accept posts from its members. This is because it was receiving too much SPAM; the kind that's crafted to bypass SPAM filters. I don't know the current filtering layout of our list, but the fact is that now I receive (as the list administrator) a confirmation email for each rejected message (?) coming from a non-member. :( If the list SPAM-filters everything before checking whether it comes from a member, it's a sane default I suppose, but considering that I have near 3 confirmation requests a day (that repeat themselves for each day I leave these duties unattended), I wonder if it's possible to simply discard them. Regards Jorge.-

Jan. 26, 2004

Re: [Dillo-dev] An odd request, I know...

by Thorben Thuermer

On Sat, 24 Jan 2004 00:04:06 +0000 Tom Barnes-Lawrence <tomble(a)usermail.com> wrote: > -I understand you not wanting the referer info being sent, even if > it does make the logs from my hit-counter a bit less useful, *but*, > some sites do seem to use the referer tags to work out if you're > accessing their images, etc deep-linked from some other page. > I'm afraid I can sort of sympathise with this, as the idea of > "stealing bandwidth" does have quite a lot of truth in it (it > does cost them money). there is one important detail there that i think is very important: even if you want to avoid image linking by checking referers, you should allow EMPTY referers... that way: a) linking the images will still fail with the majority of browsers b) browsers that don't send referers will still work. c) users can for example post a link to a image on irc or whereever and the link will work (this is something that makes users like me really hate your site) d) users can use download programs to download files off the site without having to send fake referers (wget --referer, anybody?) (and to control those, there's robots.txt) imho not allowing the referer to be empty is just stupidity on the side of the people setting up the filtering, and it just makes their own problems worse, by forcing people to send fake referer headers (like my dillo does for QUITE some time now). (the patch is trivial, just add pairs of + "Referer: http://%s%s/\r\n" + URL_HOST(url), s_port->str, into src/IO/http.c (and don't get the order wrong)) > So, I'd love it if the bookmarks code stuck each section in its own > page, and let me nest one section in another. isn't this is kind of the point of seperating stuff into dpis?: if you don't like the default one, you can relatively easily change it without having to deal with the browser code or even recompile it. Greetings, Thorben Thuermer

Jan. 26, 2004