- Dillo-dev - lists.mailman3.com

tight loop on IO error

by Phil Pennock

When viewing the page [warning, many images]: <URL:http://primates.ximian.com/~miguel/all.html> dillo runs into a tight loop when there's a broken pipe error on retrieving one of the last couple of images. I've tracked down the cause; I'm running the 0.7.3 code, with Frank's patch, but have confirmed the presence of the code in HEAD via the WebCVS interface (wonderful thing). In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" loop runs wild. With a quick change (including new debug statement) I now see: IO_callback: [GIOcond 4] IO_write IO_write: Broken pipe [errno 32] [St -1] IO_write: aborting: Broken pipe [errno 32] The patch includes some extra cosmetic DEBUG changes which can be safely discarded (and the DEBUG_LEVEL change probably should be ...) -----------------------------< cut here >------------------------------- --- /home/pdp/tmp/zshmiVuTI Mon Sep 1 13:43:24 2003 +++ IO.c Mon Sep 1 13:42:58 2003 @@ -30,7 +30,7 @@ #include "../klist.h" #include "IO.h" -#define DEBUG_LEVEL 5 +#define DEBUG_LEVEL 1 #include "../debug.h" @@ -399,8 +399,12 @@ St = read(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_read: [St %d] success\n", St); + } if ( St < 0 ) { /* Error */ @@ -446,18 +450,27 @@ St = write(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_write: success [St %d]\n", St); + } if ( St < 0 ) { /* Error */ io->Status = -errno; - if (errno == EINTR) { + switch (errno) { + case EINTR: continue; - } else if (errno == EAGAIN) { + case EAGAIN: DEBUG_MSG(4, " IO_write: EAGAIN\n"); ret = TRUE; break; + default: + DEBUG_MSG(5, " IO_write: aborting: %s [errno %d]\n", + g_strerror(errno), errno); + return FALSE; } } else if ( St < io->BufSize ){ /* Not all data written */

Sept. 1, 2003

path for support chinese

by super_hoo

I knowed that it had a patch for dillo0.7.2 to supportting Chinese. Where could I find this patch ? thanks a lot. ______________________________________ =================================================================== µ±µ±ÍøÈ«³¡ÒôÏñ5ÕÛ·â¶¥£¬ÓÅ»ÝŒŽœ«œáÊø£¡ (http://ad4.sina.com.cn/sina/dangdang0825.html)

Sept. 1, 2003

Re: [Dillo-dev] Rendering problem (temp-solution.. no patch)

by Ralph Slooten

It seems slashdot.org has serious issues with it's code, so bad that it makes it impossible, hard, or just a PITA to view with Dillo. Instead of patching dillo to render these pages despite obvious errors, I did a bit of simple PHP coding to do the following: I wrote a small php script to download a current working version of slashdot using a Mozilla cookie, wget, tidy and sed. It seems to work fine now with dillo, but probably will skrew up from time to time if 2 users at exactly the same time try refresh the page (I can't be bothered to make this into a full-blown project). It's only ment as a temp solution, and also _only_ supports the main page, linking goes directly to /.'s site, where the rendering is messed up again. http://axljab.homelinux.org:8080/slashdot/ Yeah, this is only for you /. junkies that love using Dillo, and although my internet connection may not be the best in the world, who knows, it may even work for you ;-) Also the page I created will not parse the page like in your own cookies, but is simply the default page using a cokkie of my own, but heck, it's the main page that's most interesting isn't it. Another note, each time the page is refreshed, the php downloads a new copy of/. .... so please don't abuse by continuously refreshing as it will kill my bandwidth, and possibly get me banned from slashdot altogether. Enjoy, and let me know if it works for you ... I love success stories ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Madis Janson

On Fri, 29 Aug 2003, Jorge Arellano Cid wrote: > On Thu, 28 Aug 2003, Ralph Slooten wrote: > > > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > > "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > > > > > Normally, this isn't something that I really care about, but now it's > > > causing slashdot to be rendered as black-on-black text, thus depriving me > > > of my ability to read about the new MD5 sums that the RIAA is using. > > > > Yes, I'm getting this too since today. It's probably a small html error > > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. > > Unfortunately slashdot is sending awful HTML-like content. > > The black text can be explained because they explicitly set the > background, textcolor and visited links to black! (<BODY ...>). > > Probably it changes with CSS. > No, slashdot does not use CSS. The white background is created by tables and is still visible, but articles now seem to be on the side of it, not on it (talking about main page). Probably some table/tr tags are in wrong order and screw up the push/pop parsing. Reason why i think so is that the slashdot page can be seen quite ok in dillo with this patch: @@ -1139,6 +1146,8 @@ static void Html_pop_tag(DilloHtml *html Html_eventually_pop_dw(html); return; } + if (Html_match_tag(html->stack[tag_index].tag, "table>", 6)) + break; } /* Not found, just ignore. */ } But yes, its a workaround for buggy html (not invented for slashdot) and a fact that it helps just quite proves that the slashdot page has problems with tables (along other bad html). I tried to find the problem from slashdot index page, but it was such a bloody mess that my sleepy brain could not parse it at all...

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Sat, 30 Aug 2003 13:47:13 +0200 Ralph Slooten <ralph(a)genesys.ro> wrote: > After running the saved page through tidy, it actualy renders, and renders > well! Umm, just discovered that this only works for me when logged in. If I move my cookies somewhere else, re-open slashdot with dillo, save that page and try with tidy, it fails... Just thought I would let you all know before you go blue in the face trying ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Try with "force_my_colors=YES". Yes, this works, althought the rendering is totally shit ;-) ... definitly not a dillo problem in this case. The problem with Slashdot is that there are just so many tables / blocks that it makes it almost impossible to locate the precise bug (although if I am correct the page is filled with bugs). > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. Yes, Dillo's policy is good... if the html is wrong then that's too bad. BUT... but but but, instead of manually running through all the code, I tried it with "tidy", which found a grand total of 254 warnings and 0 errors... Well, as for 0 errors, I would say 254 warnings should be more than enough to validate one big error ;-) After running the saved page through tidy, it actualy renders, and renders well! > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... > > Please investigate those and report to them. Yes, I have reported a bug about bad HTML on the sourceforge site. It's not really a matter of bad HTML, as the HTML seems resonable, but they are using terms and codes which are definitely not HTML compliant I would say. If you are interested in the output I have put up the origional page with the "fixed" version, and output of warnings / errors here: http://members.rott.chello.nl/r.slooten2/dillo/ You will see here that it appears as if I'm still logged in.. for some reason I cannot log out, LOL .. but that's not the issue.. you can just see how many invalid html commands they seem to be using, and that after the removal of this, and the insertion of several <font> and </font> attributes fixes the whole page which then renders perfectly in Dillo. Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Problems with tab patch

by Nigel Wilkinson

Thanks Frank Nigel

Aug. 29, 2003

[PATCH] Server Mode (was: commands & auto-reload)

by Melvin Hadasht

Hi, I previously posted a "command" patch as a preliminary for the server mode patch for Dillo. It was about handling the list of commands to be sent to the server. The hereby attached patch already contains that patch slightly modified and adds the ability to eventually switch to server mode or to connect and send the commands to a server This patch does not solve the "reload" bugs. I have a web page (user oriented) at: http://melvin.hadasht.free.fr/home/dillo/server/index.html I finally chose the "straightforward" approach instead of the dpid approach. Two reasons for that: i) I felt it'd introduce more complexity, especially for a client instance that needs to connect to a server and ii) the current dpid allows only one socket per service while it would be needed to have more than one Dillo server. I already explained in another mail that the socket name would need to be parametrized (by the server name, for example). Of course, this patch of mine is just a suggestion, if others feels that the dpid approach is better and more efficient, I'd be happy to see how they implemented it. The "commands" patch could still be used. They just need to handle the server/client connection. The hereby attached patch has the following characteristics: - gtk_init() is never called by a client instance - if the XID option is given, and if the server already has an embedded window with that XID, it will reuse it. - an application can still directly access to the server socket and can keep the connection open until it really does not need it. It has to check whether /tmp/dillo-$USER-$SERVERNAME exists. If not, it should launch "dillo -s $SERVERNAME". Then it should open that Unix Domain Socket. Then it just need to send commands to it, the syntax of the commands being that of the -c options. The commands that are to be sent through the socket must be of the following format: ([COMMAND][NUL])*[CRLF] That is, each COMMAND string must be followed by the terminal NUL byte. The list of commands are buffered by the server command until a [CRLF] ("\r\n" without the terminal \NUL) is sent or until the socket is closed. Then, the list of buffered commands are executed. I'll provide a simple library that could be used by an application to directly use the socket, but for the moment, the most easy and straighforward approach is to set the browser command line to "dillo -s SERVERNAME URL". On a PII266Mhz, starting a dillo client with a single open() command needs only ~0.04 seconds (if gtk_init() were executed before command line parsing and thus if each dillo client had to init the display, it would have needed more than 0.1 seconds). My next plans are to provide a simple library to connect (and eventually start) a server and to sent it commands. Then I will try to fix the "reload" bug when the reload time is too short. -- Melvin Hadasht

Aug. 29, 2003

Rendering

by Jorge Arellano Cid

Hi Sebastian! Hope you're not under a pile of workload... Please review this site: http://cocoon.apache.org/index2.html When loaded slowly (dialup speed) it renders the leftmost column too wide (almost a screen), but Back&Forward fixes it. I you can also give a look at the slashdot problem it'd be great. I'm much more interested in the first though. Regards Jorge.-

Aug. 29, 2003

Re: Tab + frame patch, any progress?

by Jorge Arellano Cid

On Wed, 27 Aug 2003, Frank de Lange wrote: > Any progress on the CSS front by the way? Sometime ago we concluded with Sebastian that it may take near three months of work of both of us. We're focusing on other priorities now. I hope we can review your patch soon with him. Cheers Jorge.-

Aug. 29, 2003