- Dillo-dev - lists.mailman3.com

[bug]: <pre> element respects color but not background-color

by onepoint＠starurchin.org

<html> <head> <style type="text/css"> pre { background-color:#222; color:#fff; } </style> </head> <body> <pre>Blah, blah, blah</pre> </body> </html> Dillo renders the above as white text on the default background, which is almost illegible. Firefox renders it white on black, as intended. If you apply the style to the body element instead of the pre element then Dillo renders it correctly. The pre element respects the color style parameter but not the background-color. This bug is visible at http://jeffkreeftmeijer.com/2010/the-mighty-reflog-and-the-amazing-bisect/ Regards, Jeremy Henty

Sept. 5, 2010

[patch]: consistent screaming quotes

by onepoint＠starurchin.org

A small cleanup. I noticed the ugly unbalanced quotes in the '>>> a_Nav_repush <<<<' message so I did a quick grep and fixed all similar messages to have the same formatting. (I am still thinking about the "parse missing attribute close quotes like Firefox" patch, but it's taking me a little while to get familiar with html.cc again.) Regards, Jeremy Henty

Sept. 5, 2010

Fwd: your dillo win32 build ....

by obeythepenguin＠gmail.com

Received this earlier today, and figured I should share with the people who deserve real credit :-) ~Benjamin ------- Forwarded message ------- From: "a.r. ramakrishnan" <srizbf(a)gmail.com> To: obeythepenguin(a)gmail.com Cc: Subject: your dillo win32 build .... Date: Fri, 03 Sep 2010 12:40:54 -0400 Hello Benjamin jhonson, congrats for your attempt on dillo for windows. i have tested your 20100902 binary. your building dillo for win9x is exceptional. and it is working under windows98. there are some layout problems in webpages. but barring that you have given the fast browser for normal use . thank you once again expecting many more from you 3rdsep2010 -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Sept. 4, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

All right, I have it running on Windows 95! Screenshots: http://dillo-win32.sourceforge.net/screenshots/dillo-win95.png http://dillo-win32.sourceforge.net/screenshots/dillo-wikipedia-win95.png It's still a little glitchy (FLTK issues, not Dillo per se), but now Dillo can truly run on any Windows system, for all practical purposes. [Of course, if you can prove people still use Win3.11...] Here's the latest patch: http://dillo-win32.sourceforge.net/files/dillo-r1698-win32-20100902.diff I've also got a full installer up on the SourceForge page, if anyone has a Windows machine and wants to take it for a spin. I've been using it quite a bit myself the last few days, including three straight hours the other night. As long as you don't need DPI, it's quite usable. Speaking of which... there's going to be a few complications, mainly because on Windows, file and socket handles are NOT interchangable. DPI seems to rely heavily on dup2(), for which there's no direct Windows equivalent. I've written up a full description of the problem here: http://dillo-win32.sourceforge.net/dpi.html This is where I'm going to need your expert advice. Jorge, if you have the time, I'd especially like to hear your opinion -- I know you're quite busy, and not a personal fan of the Windows platform, but I feel a well-executed port would ultimately help the project far more than it would hurt anything. Thanks again & cheers, ~Benjamin

Sept. 3, 2010

[Patch] Work around lazy loading images

by obeythepenguin＠gmail.com

Another patch, this time not Win32-related. This works around the annoying "lazy loading" technique, which sets src to a placeholder image then uses JavaScript to fetch the real images after the pages load. Here's the diff: http://pastebin.com/wyP32Ukj (sorry it's not hg diff; I don't have access from school) I know Dillo aims to strictly follow standards, but I don't think it's a standards violation per se, so much as a trick too clever for its own good. I personally feel this helps the democratization of information access more than it hurts standards compliance, since otherwise the information might not be available until/unless Dillo implements JavaScript support. You may, of course, disagree... Cheers, ~Benjamin

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

[Oops, screwed up the mail again. Sorry I keep doing this to you corvid, as if keeping up with all my code wasn't bad enough... -bmj] On Tue, 31 Aug 2010 20:48:03 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> Once again you've hit it dead-on before I can even fire up the >> debugger. Do you have psychic powers or something, or are you just >> that good? :-) > > :) You *do* have psychic powers, then! I knew it. Thanks again for all your help -- I never expected to get this far so quickly, and I certainly couldn't have done it without you. >> DPI sounds like the logical next step. Anything in particular I >> should watch out for there? > > I don't know; we'll find out soon enough... I suppose so! By the way, I don't know if this patch is/will be quite good enough to merge in, but should this happen -- I think Johannes expressed some interest -- I'll happily maintain it. I can do Windows binary releases and support on the SourceForge site so it's not bothering anyone in main line. Cheers, ~Benjamin

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > Once again you've hit it dead-on before I can even fire up the > debugger. Do you have psychic powers or something, or are you just > that good? :-) :) > DPI sounds like the logical next step. Anything in particular I > should watch out for there? I don't know; we'll find out soon enough...

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Tue, Aug 31, 2010 at 12:57 AM, corvid <corvid(a)lavabit.com> wrote: > When stylesheets come in, they go through Html_css_load_callback(), and > when the last one has been completely received, a_UIcmd_repush() is > called to start the page rendering over again. Jorge did the repush code, > but it seems to me that dillo continues to receive any partially-received > images, whereas for images that haven't started to arrive, the connection > is closed and a new connection is made to get the image during the > second rendering. > > So when you mention images and IO callbacks, it comes to mind as a > case where something funny could happen... Once again you've hit it dead-on before I can even fire up the debugger. Do you have psychic powers or something, or are you just that good? :-) My solution is to have dsock keep a count of active sockets, and rather than repush immediately, start a background loop that waits for all sockets to close before repushing. It seems to work fine on Unix with the regular iowatch mechanism, but I haven't tested that extensively, so if there's problems it could be #ifdef'd for just the timeout mechanism kludge. A few other changes: file paths are now correctly handled on Windows; disabled unnecessary pthreads check in ./configure; gzip compression is re-enabled; and possibly a couple other things I've already forgotten. The latest patch: http://dillo-win32.sourceforge.net/files/dillo-r1698-win32-20100831.diff And an updated build is available from the usual place: http://dillo-win32.sourceforge.net/ Assuming I didn't make too many more stupid mistakes, DPI sounds like the logical next step. Anything in particular I should watch out for there?

Sept. 1, 2010

Another (native) Dillo-Win32 patch

by corvid＠lavabit.com

Benjamin wrote: > On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > > I wonder whether it has to do with interrupted image downloading > > when it gets all of the remote stylesheets for a page and performs > > a repush. Or, more precisely, when an image has been requested but > > hasn't started coming back from the server. > > So what you're saying is, it's trying to fetch stylesheets between > requesting an image and receiving it, and that's what's causing the > problem? When stylesheets come in, they go through Html_css_load_callback(), and when the last one has been completely received, a_UIcmd_repush() is called to start the page rendering over again. Jorge did the repush code, but it seems to me that dillo continues to receive any partially-received images, whereas for images that haven't started to arrive, the connection is closed and a new connection is made to get the image during the second rendering. So when you mention images and IO callbacks, it comes to mind as a case where something funny could happen...

Aug. 31, 2010

Another (native) Dillo-Win32 patch

by obeythepenguin＠gmail.com

On Mon, Aug 30, 2010 at 11:28 PM, corvid <corvid(a)lavabit.com> wrote: > I wonder whether it has to do with interrupted image downloading > when it gets all of the remote stylesheets for a page and performs > a repush. Or, more precisely, when an image has been requested but > hasn't started coming back from the server. So what you're saying is, it's trying to fetch stylesheets between requesting an image and receiving it, and that's what's causing the problem? > If you turn on image loading and turn off remote stylesheets, does it > work consistently? It seems to be working so far.

Aug. 31, 2010