From corvid at lavabit.com Sun Nov 1 00:39:15 2009 From: corvid at lavabit.com (corvid) Date: Sun Nov 1 00:43:56 2009 Subject: [Dillo-dev] arbitrary keysyms in keysrc Message-ID: <20091031233915.GA12161@local.gobigwest.com> What would you think of allowing arbitrary keysyms to be specified in keysrc using their hex values? From corvid at lavabit.com Sun Nov 1 19:16:09 2009 From: corvid at lavabit.com (corvid) Date: Sun Nov 1 19:20:49 2009 Subject: [Dillo-dev] patch: jpegs and cmyk color space Message-ID: <20091101181608.GA3691@local.gobigwest.com> Here's one page that links to some CMYK jpgs and pretty much fits with what I've been able to learn: http://code.google.com/p/chromium/issues/detail?id=21659 Everything I find on the web about this shows roughly the same amount of uncertainty. -------------- next part -------------- diff -r fcbd1ffac58e src/image.hh --- a/src/image.hh Sat Oct 31 21:11:06 2009 +0000 +++ b/src/image.hh Sun Nov 01 17:53:47 2009 +0000 @@ -29,6 +29,7 @@ DILLO_IMG_TYPE_INDEXED, DILLO_IMG_TYPE_RGB, DILLO_IMG_TYPE_GRAY, + DILLO_IMG_TYPE_CMYK_INV, DILLO_IMG_TYPE_NOTSET /* Initial value */ } DilloImgType; diff -r fcbd1ffac58e src/imgbuf.cc --- a/src/imgbuf.cc Sat Oct 31 21:11:06 2009 +0000 +++ b/src/imgbuf.cc Sun Nov 01 17:53:47 2009 +0000 @@ -45,6 +45,19 @@ for (x = 0; x < width; x++) memset(linebuf + x * 3, buf[x], 3); break; + case DILLO_IMG_TYPE_CMYK_INV: + /* + * We treat CMYK as if it were "RGBW", and it works. Everyone who is + * trying to handle CMYK jpegs is confused by this, and supposedly + * the issue is that Adobe CMYK is "wrong" but ubiquitous. + */ + for (x = 0; x < width; x++) { + uint_t white = buf[x * 4 + 3]; + linebuf[x * 3] = buf[x * 4] * white / 0x100; + linebuf[x * 3 + 1] = buf[x * 4 + 1] * white / 0x100; + linebuf[x * 3 + 2] = buf[x * 4 + 2] * white / 0x100; + } + break; case DILLO_IMG_TYPE_RGB: /* avoid a memcpy here! --Jcid */ return (uchar_t *)buf; diff -r fcbd1ffac58e src/jpeg.c --- a/src/jpeg.c Sat Oct 31 21:11:06 2009 +0000 +++ b/src/jpeg.c Sun Nov 01 17:53:47 2009 +0000 @@ -273,8 +273,12 @@ } else if (jpeg->cinfo.num_components == 3) { type = DILLO_IMG_TYPE_RGB; } else { - _MSG("jpeg: can't handle %d component images\n", - jpeg->cinfo.num_components); + MSG("4bpp JPEG!\n"); + if (jpeg->cinfo.jpeg_color_space == JCS_YCCK) + MSG("YCCK. Are the colors wrong?\n"); + if (!jpeg->cinfo.saw_Adobe_marker) + MSG("No adobe marker! Is the image shown in reverse video?\n"); + type = DILLO_IMG_TYPE_CMYK_INV; } /* * If a multiple-scan image is not completely in cache, From jcid at dillo.org Sun Nov 1 22:24:18 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Nov 1 22:24:57 2009 Subject: [Dillo-dev] Big changes in DPI framework and API Message-ID: <20091101212418.GC2763@dillo.org> Hi, Today the big work on DPI/DPIP was committed! The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago. There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less). One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now). Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain. Please test and enjoy. ...and remember to "dpidc stop" before "make install-strip". -- Cheers Jorge.- From corvid at lavabit.com Sun Nov 1 22:30:54 2009 From: corvid at lavabit.com (corvid) Date: Sun Nov 1 22:35:36 2009 Subject: [Dillo-dev] arbitrary keysyms in keysrc In-Reply-To: <20091101205307.GB2763@dillo.org> References: <20091031233915.GA12161@local.gobigwest.com> <20091101205307.GB2763@dillo.org> Message-ID: <20091101213054.GA4671@local.gobigwest.com> Jorge wrote: > On Sat, Oct 31, 2009 at 11:39:15PM +0000, corvid wrote: > > > > What would you think of allowing arbitrary keysyms > > to be specified in keysrc using their hex values? > > What's the gain? Being able to use a hex code from xev? > (to me it's an obscure representation, but easy to find OTOH) I finally got a newer computer, and it has some buttons that fltk has no idea about (e.g., a picture of a rectangle and arrow that X thinks of as XF86Next), and it would be nice to be able to use them. From furaisanjin at gmail.com Mon Nov 2 02:57:00 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Mon Nov 2 02:57:54 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091101212418.GC2763@dillo.org> References: <20091101212418.GC2763@dillo.org> Message-ID: <144aa14b0911011757u1e6been2568526f9e226486@mail.gmail.com> Hi. I got compiling problem on FreeBSD 6.4. if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDPIDRC_SYS='"/usr/local/etc/dillo/dpidrc"' -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -W -Wno-unused-parameter -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" -c -o dpid.o dpid.c; \ then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; else rm -f ".deps/dpid.Tpo"; exit 1; fi dpid.c: In function `init_ids_srs_socket': dpid.c:615: error: `IPPORT_USERRESERVED' undeclared (first use in this function) dpid.c:615: error: (Each undeclared identifier is reported only once dpid.c:615: error: for each function it appears in.) dpid.c: In function `init_dpi_socket': dpid.c:637: error: `IPPORT_USERRESERVED' undeclared (first use in this function) Because FreeBSD 6.4 doesn't have IPPORT_USERRESERVED. Regards, furaisanjin From onepoint at starurchin.org Mon Nov 2 08:14:29 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon Nov 2 08:15:24 2009 Subject: [Dillo-dev] Cleanups for Html_tag_cleanup_at_close() Message-ID: <20091102071429.GA3195@omphalos.singularity> Congratulations on the big DPI reworking! Meanwhile I'd like to submit some cleanups for Html_tag_cleanup_at_close(), whose logic is currently pretty opaque. The first is a resubmit (it seems to have vanished into the ether when last posted). These should have no effect on behaviour, they just make it more clear what is going on. Regards, Jeremy Henty -------------- next part -------------- diff -r c0c0b4b3e9f8 -r 7f1eb453a3f0 src/html.cc --- a/src/html.cc Tue Dec 09 14:28:50 2008 +0000 +++ b/src/html.cc Tue Oct 20 23:09:06 2009 +0100 @@ -1294,6 +1294,20 @@ Html_eventually_pop_dw(html, hand_over_break); } +static void Html_tag_cleanup_to_idx(DilloHtml *html, int idx) +{ + while (html->stack->size() > idx) { + int toptag_idx = S_TOP(html)->tag_idx; + if (html->stack->size() > idx + 1 && + Tags[toptag_idx].EndTag != 'O') + BUG_MSG(" - forcing close of open tag: <%s>\n", + Tags[toptag_idx].name); + _MSG("Close: %*s%s\n", html->stack->size()," ",Tags[toptag_idx].name); + Tags[toptag_idx].close (html, toptag_idx); + Html_real_pop_tag(html); + } +} + /* * Default close function for tags. * (conditional cleanup of the stack) @@ -1328,21 +1342,7 @@ /* clean, up to the matching tag */ if (cmp == 0 && stack_idx > 0) { - /* There's a valid matching tag in the stack */ - while (html->stack->size() > stack_idx) { - int toptag_idx = S_TOP(html)->tag_idx; - /* Warn when we decide to close an open tag (for !w3c_mode) */ - if (html->stack->size() > stack_idx + 1 && - Tags[toptag_idx].EndTag != 'O') - BUG_MSG(" - forcing close of open tag: <%s>\n", - Tags[toptag_idx].name); - - /* Close this and only this tag */ - _MSG("Close: %*s%s\n", html->stack->size()," ",Tags[toptag_idx].name); - Tags[toptag_idx].close (html, toptag_idx); - Html_real_pop_tag(html); - } - + Html_tag_cleanup_to_idx(html, stack_idx); } else { if (stack_idx == 0) { BUG_MSG("unexpected closing tag: .\n", Tags[new_idx].name); -------------- next part -------------- diff -r 0504787199c5 src/html.cc --- a/src/html.cc Sat Oct 24 16:39:49 2009 +0100 +++ b/src/html.cc Sat Oct 24 17:04:39 2009 +0100 @@ -1322,31 +1322,41 @@ static void Html_tag_cleanup_at_close(DilloHtml *html, int TagIdx) { int w3c_mode = !prefs.w3c_plus_heuristics; - int stack_idx, cmp = 1; - int new_idx = TagIdx; + int stack_idx, new_idx = TagIdx; + TagInfo tag, new_tag = Tags[new_idx]; + int matched = 0, expected = 0; /* Look for the candidate tag to close */ - stack_idx = html->stack->size() - 1; - while (stack_idx && - (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && - (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O' || - (!w3c_mode && - Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < - Tags[new_idx].TagLevel))) { - --stack_idx; + stack_idx = html->stack->size(); + while (--stack_idx) { + + int tag_idx = html->stack->getRef(stack_idx)->tag_idx; + + /* stop if this is the matching tag */ + if (new_idx == tag_idx) { + matched = 1; + break; + } + + /* skip an optional tag */ + tag = Tags[tag_idx]; + if (tag.EndTag == 'O') + continue; + + /* stop if this is the tag that should have been closed */ + if (w3c_mode || tag.TagLevel >= new_tag.TagLevel) { + expected = 1; + break; + } } - /* clean, up to the matching tag */ - if (cmp == 0 && stack_idx > 0) { + if (matched) { Html_tag_cleanup_to_idx(html, stack_idx); + } else if (expected) { + BUG_MSG("unexpected closing tag: -- expected .\n", + new_tag.name, tag.name); } else { - if (stack_idx == 0) { - BUG_MSG("unexpected closing tag: .\n", Tags[new_idx].name); - } else { - BUG_MSG("unexpected closing tag: . -- expected \n", - Tags[new_idx].name, - Tags[html->stack->getRef(stack_idx)->tag_idx].name); - } + BUG_MSG("unexpected closing tag: .\n", new_tag.name); } } -------------- next part -------------- diff -r 09c91e40e61b -r 3c451a80bfcf src/html.cc --- a/src/html.cc Tue Dec 09 14:28:50 2008 +0000 +++ b/src/html.cc Sat Oct 24 11:40:38 2009 +0100 @@ -1292,16 +1292,19 @@ Html_eventually_pop_dw(html, hand_over_break); } +/* + * Cleanup the stack to a given index. + */ static void Html_tag_cleanup_to_idx(DilloHtml *html, int idx) { - while (html->stack->size() > idx) { + int size; + while ((size = html->stack->size()) > idx) { int toptag_idx = S_TOP(html)->tag_idx; - if (html->stack->size() > idx + 1 && - Tags[toptag_idx].EndTag != 'O') - BUG_MSG(" - forcing close of open tag: <%s>\n", - Tags[toptag_idx].name); - _MSG("Close: %*s%s\n", html->stack->size()," ",Tags[toptag_idx].name); - Tags[toptag_idx].close (html, toptag_idx); + TagInfo toptag = Tags[toptag_idx]; + if (size > idx + 1 && toptag.EndTag != 'O') + BUG_MSG(" - forcing close of open tag: <%s>\n", toptag.name); + _MSG("Close: %*s%s\n", size," ",toptag.name); + toptag.close (html, toptag_idx); Html_real_pop_tag(html); } } From jcid at dillo.org Mon Nov 2 16:12:38 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 2 16:13:13 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <144aa14b0911011757u1e6been2568526f9e226486@mail.gmail.com> References: <20091101212418.GC2763@dillo.org> <144aa14b0911011757u1e6been2568526f9e226486@mail.gmail.com> Message-ID: <20091102151238.GA2201@dillo.org> On Mon, Nov 02, 2009 at 10:57:00AM +0900, furaisanjin wrote: > Hi. > > I got compiling problem on FreeBSD 6.4. > > if gcc -DHAVE_CONFIG_H -I. -I. -I.. > -DDPIDRC_SYS='"/usr/local/etc/dillo/dpidrc"' -I/usr/local/include -g > -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -W > -Wno-unused-parameter -Waggregate-return -MT dpid.o -MD -MP -MF > ".deps/dpid.Tpo" -c -o dpid.o dpid.c; \ > then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; else rm -f > ".deps/dpid.Tpo"; exit 1; fi > dpid.c: In function `init_ids_srs_socket': > dpid.c:615: error: `IPPORT_USERRESERVED' undeclared (first use in this function) > dpid.c:615: error: (Each undeclared identifier is reported only once > dpid.c:615: error: for each function it appears in.) > dpid.c: In function `init_dpi_socket': > dpid.c:637: error: `IPPORT_USERRESERVED' undeclared (first use in this function) > > Because FreeBSD 6.4 doesn't have IPPORT_USERRESERVED. Thanks for the report. Please try the latest repo and send feedback! -- Cheers Jorge.- From corvid at lavabit.com Mon Nov 2 17:16:53 2009 From: corvid at lavabit.com (corvid) Date: Mon Nov 2 17:21:34 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091101212418.GC2763@dillo.org> References: <20091101212418.GC2763@dillo.org> Message-ID: <20091102161653.GA3914@local.gobigwest.com> That's a lot of code! Jorge wrote: > There're still pending patches and docs. Details are in the > Changelog and Mercurial repo (hg log -v|less). I tried putting the pieces under ~/.dillo/, similar to how I'd had them before, and got error msgs instead of working dpis. Would it make more sense for me to dig in now to understand what is happening, or are the docs and patches coming very soon? From jcid at dillo.org Mon Nov 2 17:51:58 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 2 17:52:34 2009 Subject: [Dillo-dev] Cleanups for Html_tag_cleanup_at_close() In-Reply-To: <20091102071429.GA3195@omphalos.singularity> References: <20091102071429.GA3195@omphalos.singularity> Message-ID: <20091102165158.GB2201@dillo.org> On Mon, Nov 02, 2009 at 07:14:29AM +0000, Jeremy Henty wrote: > > Congratulations on the big DPI reworking! Thanks Jeremy. It took a long effort, but now I'm confident it'll be less frustrating (and hopefully fun) to work with DPIs. At least it happened to me. After the underlying layer was ready, ironing bugs out was easy. > Meanwhile I'd like to > submit some cleanups for Html_tag_cleanup_at_close(), whose logic is > currently pretty opaque. The first is a resubmit (it seems to have > vanished into the ether when last posted). These should have no > effect on behaviour, they just make it more clear what is going on. Committed. Sorry for the delay. FWIW, it was more me vanishing under the DPI/DPIP work ;) -- Cheers Jorge.- From jcid at dillo.org Mon Nov 2 19:07:29 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 2 19:08:04 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102161653.GA3914@local.gobigwest.com> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> Message-ID: <20091102180729.GC2201@dillo.org> On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > That's a lot of code! Yes. I made the partial diffstats but have no idea on how much the whole pack was in the end. :) > Jorge wrote: > > There're still pending patches and docs. Details are in the > > Changelog and Mercurial repo (hg log -v|less). > > I tried putting the pieces under ~/.dillo/, similar to how I'd > had them before, and got error msgs instead of working dpis. > Would it make more sense for me to dig in now to understand what > is happening, or are the docs and patches coming very soon? I should write Docs soon (before Friday). There were no changes regarding dpis in ~/.dillo/. I haven't tested them though. Let me check here... -- Cheers Jorge.- From jcid at dillo.org Mon Nov 2 19:20:40 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 2 19:21:14 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102180729.GC2201@dillo.org> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> Message-ID: <20091102182040.GD2201@dillo.org> On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > [...] > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > had them before, and got error msgs instead of working dpis. > > Would it make more sense for me to dig in now to understand what > > is happening, or are the docs and patches coming very soon? > > I should write Docs soon (before Friday). There were no changes > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > check here... After changing the table colors in file.dpi, more or less it worked with: make dpidc stop mkdir -p ~/.dillo/dpi/file cp file.dpi ~/.dillo/dpi/file dillo . It may be that you already have dpis there, and those will not work with the new code. They need convertion to the new dsh API. If this is the case, you can wait a bit for the docs, or give a look to the respective "convert to dsh API" patch in the repo. -- Cheers Jorge.- From onepoint at starurchin.org Mon Nov 2 19:57:49 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon Nov 2 19:58:45 2009 Subject: [Dillo-dev] Cleanups for Html_tag_cleanup_at_close() In-Reply-To: <20091102165158.GB2201@dillo.org> References: <20091102071429.GA3195@omphalos.singularity> <20091102165158.GB2201@dillo.org> Message-ID: <20091102185749.GB3195@omphalos.singularity> On Mon, Nov 02, 2009 at 01:51:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 02, 2009 at 07:14:29AM +0000, Jeremy Henty wrote: > > > Meanwhile I'd like to submit some cleanups for > > Html_tag_cleanup_at_close(), ... > > ... Sorry for the delay. FWIW, it was more me vanishing under the > DPI/DPIP work ;) No problems. I thought that was probably the reason so I delayed resubmitting for a few days. No need to apologise when Dillo keeps getting better! Regards, Jeremy Henty From corvid at lavabit.com Mon Nov 2 20:26:49 2009 From: corvid at lavabit.com (corvid) Date: Mon Nov 2 20:31:29 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102182040.GD2201@dillo.org> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> Message-ID: <20091102192649.GB3914@local.gobigwest.com> Jorge wrote: > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > [...] > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > had them before, and got error msgs instead of working dpis. > > > Would it make more sense for me to dig in now to understand what > > > is happening, or are the docs and patches coming very soon? > > > > I should write Docs soon (before Friday). There were no changes > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > check here... > > After changing the table colors in file.dpi, more or less it > worked with: > > make > dpidc stop > mkdir -p ~/.dillo/dpi/file > cp file.dpi ~/.dillo/dpi/file > dillo . > > It may be that you already have dpis there, and those will not > work with the new code. They need convertion to the new dsh API. > If this is the case, you can wait a bit for the docs, or give a > look to the respective "convert to dsh API" patch in the repo. When dillo tries to talk to dpid: After connect(), lsof -i shows me ESTABLISHED for both sides After write(), the dpid side is gone and dillo says CLOSE_WAIT After shutdown(), both sides are gone. Then Dpi_get_server_port: can't read server port from dpid. and ** ERROR **: dpi.c: can't start dpi daemon From jcid at dillo.org Mon Nov 2 20:58:05 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 2 20:58:41 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102192649.GB3914@local.gobigwest.com> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> <20091102192649.GB3914@local.gobigwest.com> Message-ID: <20091102195805.GE2201@dillo.org> On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > [...] > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > had them before, and got error msgs instead of working dpis. > > > > Would it make more sense for me to dig in now to understand what > > > > is happening, or are the docs and patches coming very soon? > > > > > > I should write Docs soon (before Friday). There were no changes > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > check here... > > > > After changing the table colors in file.dpi, more or less it > > worked with: > > > > make > > dpidc stop > > mkdir -p ~/.dillo/dpi/file > > cp file.dpi ~/.dillo/dpi/file > > dillo . > > > > It may be that you already have dpis there, and those will not > > work with the new code. They need convertion to the new dsh API. > > If this is the case, you can wait a bit for the docs, or give a > > look to the respective "convert to dsh API" patch in the repo. > > When dillo tries to talk to dpid: > After connect(), lsof -i shows me ESTABLISHED for both sides > After write(), the dpid side is gone and dillo says CLOSE_WAIT > After shutdown(), both sides are gone. > Then Dpi_get_server_port: can't read server port from dpid. > and ** ERROR **: dpi.c: can't start dpi daemon There may be an old dpid binary around. Try this in two terminal windows: 1.- 2.- cd src/dpid cd src/dpid ./dpid ./dpidc stop If dpid stops, it's OK. Most probably an old dpid is started. Is anybody else seeing this problem? -- Cheers Jorge.- From corvid at lavabit.com Mon Nov 2 21:14:40 2009 From: corvid at lavabit.com (corvid) Date: Mon Nov 2 21:19:19 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102195805.GE2201@dillo.org> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> <20091102192649.GB3914@local.gobigwest.com> <20091102195805.GE2201@dillo.org> Message-ID: <20091102201440.GC3914@local.gobigwest.com> Jorge wrote: > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > [...] > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > had them before, and got error msgs instead of working dpis. > > > > > Would it make more sense for me to dig in now to understand what > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > check here... > > > > > > After changing the table colors in file.dpi, more or less it > > > worked with: > > > > > > make > > > dpidc stop > > > mkdir -p ~/.dillo/dpi/file > > > cp file.dpi ~/.dillo/dpi/file > > > dillo . > > > > > > It may be that you already have dpis there, and those will not > > > work with the new code. They need convertion to the new dsh API. > > > If this is the case, you can wait a bit for the docs, or give a > > > look to the respective "convert to dsh API" patch in the repo. > > > > When dillo tries to talk to dpid: > > After connect(), lsof -i shows me ESTABLISHED for both sides > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > After shutdown(), both sides are gone. > > Then Dpi_get_server_port: can't read server port from dpid. > > and ** ERROR **: dpi.c: can't start dpi daemon > > There may be an old dpid binary around. Try this in two > terminal windows: > > 1.- 2.- > cd src/dpid cd src/dpid > ./dpid ./dpidc stop > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > Is anybody else seeing this problem? But that dpid had been listening on the port advertised in dpid_comm_keys, which an old dpid wouldn't have been doing. From furaisanjin at gmail.com Tue Nov 3 01:02:29 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Tue Nov 3 01:03:23 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102151238.GA2201@dillo.org> References: <20091101212418.GC2763@dillo.org> <144aa14b0911011757u1e6been2568526f9e226486@mail.gmail.com> <20091102151238.GA2201@dillo.org> Message-ID: <144aa14b0911021602o205ace53we7f76079feebf1f2@mail.gmail.com> 2009/11/3 Jorge Arellano Cid : > ?Please try the latest repo and send feedback! > Thank you for updating and now I can compile. However I encounter the problematic pages. I will report this in another thread. Regards, furaisanjin From furaisanjin at gmail.com Tue Nov 3 01:19:50 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Tue Nov 3 01:20:43 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp Message-ID: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> Hi. I don't try all pages but at least there are several pages where dillo keeps crashing. One example is http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace shows something like this. #0 0x28554687 in __vfprintf () from /lib/libc.so.6 #1 0x284e1fe0 in vsnprintf () from /lib/libc.so.6 #2 0x0807a16f in dStr_vsprintfa (ds=0x83cad40, format=0x80fd314 "unexpected closing tag: -- expected .\n", argp=0xbfbfe318 "・216\017\b") at dlib.c:362 #3 0x08065f94 in DilloHtml::bugMessage (this=0x847f400, format=0x80fd314 "unexpected closing tag: -- expected .\n") at html.cc:144 #4 0x0806bed5 in Html_tag_cleanup_at_close (html=0x847f400, new_idx=8) at html.cc:1338 #5 0x0806ce4f in Html_write_raw (html=0x847f400, buf=0x861e000 "\n\n\n\n\n, close = 0x8067db0 } (gdb) p tag $2 = {name = 0x79000000 , Flags = 16 '\020', EndTag = 0 '\0', TagLevel = 0 '\0', open = 0, close = 0x2f} Regards, furaisanjin From jcid at dillo.org Tue Nov 3 12:22:00 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 3 12:22:36 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091102201440.GC3914@local.gobigwest.com> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> <20091102192649.GB3914@local.gobigwest.com> <20091102195805.GE2201@dillo.org> <20091102201440.GC3914@local.gobigwest.com> Message-ID: <20091103112200.GA3656@dillo.org> On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > > [...] > > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > > had them before, and got error msgs instead of working dpis. > > > > > > Would it make more sense for me to dig in now to understand what > > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > > check here... > > > > > > > > After changing the table colors in file.dpi, more or less it > > > > worked with: > > > > > > > > make > > > > dpidc stop > > > > mkdir -p ~/.dillo/dpi/file > > > > cp file.dpi ~/.dillo/dpi/file > > > > dillo . > > > > > > > > It may be that you already have dpis there, and those will not > > > > work with the new code. They need convertion to the new dsh API. > > > > If this is the case, you can wait a bit for the docs, or give a > > > > look to the respective "convert to dsh API" patch in the repo. > > > > > > When dillo tries to talk to dpid: > > > After connect(), lsof -i shows me ESTABLISHED for both sides > > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > > After shutdown(), both sides are gone. > > > Then Dpi_get_server_port: can't read server port from dpid. > > > and ** ERROR **: dpi.c: can't start dpi daemon > > > > There may be an old dpid binary around. Try this in two > > terminal windows: > > > > 1.- 2.- > > cd src/dpid cd src/dpid > > ./dpid ./dpidc stop > > > > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > > > > Is anybody else seeing this problem? > > But that dpid had been listening on the port advertised in > dpid_comm_keys, which an old dpid wouldn't have been doing. OK. The error looks like a problem in the authentication phase, but I'm not sure. Does the above test work for you? Are you testing on GNU/Linux or other OS? Is there a chance of another app trying to talk to the same port (DPID_BASE_PORT)? Are you trying to run all from ~/.dillo, or a global install? -- Cheers Jorge.- From jcid at dillo.org Tue Nov 3 12:33:32 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 3 12:34:06 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> Message-ID: <20091103113332.GB3656@dillo.org> On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > Hi. > > I don't try all pages but at least there are several pages where dillo > keeps crashing. One example is > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > shows something like this. It doesn't crash here... :P The were a couple of patches for cleanup_at_close, please try from the repository without them (upto 1404:d4a8309dc63c), and let us know how it goes. -- Cheers Jorge.- From furaisanjin at gmail.com Tue Nov 3 13:08:24 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Tue Nov 3 13:09:18 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <20091103113332.GB3656@dillo.org> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> Message-ID: <144aa14b0911030408i58e8b2e9q8c6697bbee6a2f28@mail.gmail.com> 2009/11/3 Jorge Arellano Cid : > ?The were a couple of patches for cleanup_at_close, please > try from the repository without them (upto 1404:d4a8309dc63c), > and let us know how it goes. I did hg update -C 1404, this looks OK. Regards, furaisanjin From corvid at lavabit.com Tue Nov 3 16:10:31 2009 From: corvid at lavabit.com (corvid) Date: Tue Nov 3 16:15:10 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <20091103113332.GB3656@dillo.org> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> Message-ID: <20091103151030.GA5291@local.gobigwest.com> Jorge wrote: > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > Hi. > > > > I don't try all pages but at least there are several pages where dillo > > keeps crashing. One example is > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > shows something like this. > > It doesn't crash here... :P > > The were a couple of patches for cleanup_at_close, please > try from the repository without them (upto 1404:d4a8309dc63c), > and let us know how it goes. I don't see where the tag variable is set to anything at all in tip. I don't get a crash, but I get gibberish in the page bugs. From corvid at lavabit.com Tue Nov 3 16:20:02 2009 From: corvid at lavabit.com (corvid) Date: Tue Nov 3 16:24:40 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091103112200.GA3656@dillo.org> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> <20091102192649.GB3914@local.gobigwest.com> <20091102195805.GE2201@dillo.org> <20091102201440.GC3914@local.gobigwest.com> <20091103112200.GA3656@dillo.org> Message-ID: <20091103152002.GB5291@local.gobigwest.com> Jorge wrote: > On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > > > [...] > > > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > > > had them before, and got error msgs instead of working dpis. > > > > > > > Would it make more sense for me to dig in now to understand what > > > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > > > check here... > > > > > > > > > > After changing the table colors in file.dpi, more or less it > > > > > worked with: > > > > > > > > > > make > > > > > dpidc stop > > > > > mkdir -p ~/.dillo/dpi/file > > > > > cp file.dpi ~/.dillo/dpi/file > > > > > dillo . > > > > > > > > > > It may be that you already have dpis there, and those will not > > > > > work with the new code. They need convertion to the new dsh API. > > > > > If this is the case, you can wait a bit for the docs, or give a > > > > > look to the respective "convert to dsh API" patch in the repo. > > > > > > > > When dillo tries to talk to dpid: > > > > After connect(), lsof -i shows me ESTABLISHED for both sides > > > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > > > After shutdown(), both sides are gone. > > > > Then Dpi_get_server_port: can't read server port from dpid. > > > > and ** ERROR **: dpi.c: can't start dpi daemon > > > > > > There may be an old dpid binary around. Try this in two > > > terminal windows: > > > > > > 1.- 2.- > > > cd src/dpid cd src/dpid > > > ./dpid ./dpidc stop > > > > > > > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > > > > > > > Is anybody else seeing this problem? > > > > But that dpid had been listening on the port advertised in > > dpid_comm_keys, which an old dpid wouldn't have been doing. > > OK. The error looks like a problem in the authentication phase, > but I'm not sure. Does the above test work for you? Are you > testing on GNU/Linux or other OS? Is there a chance of another > app trying to talk to the same port (DPID_BASE_PORT)? The test starts and stops dpid. GNU/Linux. lsof -i doesn't show anything else doing anything. > Are you trying to run all from ~/.dillo, or a global install? All from ~/.dillo From corvid at lavabit.com Tue Nov 3 17:11:03 2009 From: corvid at lavabit.com (corvid) Date: Tue Nov 3 17:15:43 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091103152002.GB5291@local.gobigwest.com> References: <20091101212418.GC2763@dillo.org> <20091102161653.GA3914@local.gobigwest.com> <20091102180729.GC2201@dillo.org> <20091102182040.GD2201@dillo.org> <20091102192649.GB3914@local.gobigwest.com> <20091102195805.GE2201@dillo.org> <20091102201440.GC3914@local.gobigwest.com> <20091103112200.GA3656@dillo.org> <20091103152002.GB5291@local.gobigwest.com> Message-ID: <20091103161103.GC5291@local.gobigwest.com> dillo-dev wrote: > Jorge wrote: > > On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote: > > > > > > > On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote: > > > > > > > > [...] > > > > > > > > I tried putting the pieces under ~/.dillo/, similar to how I'd > > > > > > > > had them before, and got error msgs instead of working dpis. > > > > > > > > Would it make more sense for me to dig in now to understand what > > > > > > > > is happening, or are the docs and patches coming very soon? > > > > > > > > > > > > > > I should write Docs soon (before Friday). There were no changes > > > > > > > regarding dpis in ~/.dillo/. I haven't tested them though. Let me > > > > > > > check here... > > > > > > > > > > > > After changing the table colors in file.dpi, more or less it > > > > > > worked with: > > > > > > > > > > > > make > > > > > > dpidc stop > > > > > > mkdir -p ~/.dillo/dpi/file > > > > > > cp file.dpi ~/.dillo/dpi/file > > > > > > dillo . > > > > > > > > > > > > It may be that you already have dpis there, and those will not > > > > > > work with the new code. They need convertion to the new dsh API. > > > > > > If this is the case, you can wait a bit for the docs, or give a > > > > > > look to the respective "convert to dsh API" patch in the repo. > > > > > > > > > > When dillo tries to talk to dpid: > > > > > After connect(), lsof -i shows me ESTABLISHED for both sides > > > > > After write(), the dpid side is gone and dillo says CLOSE_WAIT > > > > > After shutdown(), both sides are gone. > > > > > Then Dpi_get_server_port: can't read server port from dpid. > > > > > and ** ERROR **: dpi.c: can't start dpi daemon > > > > > > > > There may be an old dpid binary around. Try this in two > > > > terminal windows: > > > > > > > > 1.- 2.- > > > > cd src/dpid cd src/dpid > > > > ./dpid ./dpidc stop > > > > > > > > > > > > If dpid stops, it's OK. Most probably an old dpid is started. > > > > > > > > > > > > Is anybody else seeing this problem? > > > > > > But that dpid had been listening on the port advertised in > > > dpid_comm_keys, which an old dpid wouldn't have been doing. > > > > OK. The error looks like a problem in the authentication phase, > > but I'm not sure. Does the above test work for you? Are you > > testing on GNU/Linux or other OS? Is there a chance of another > > app trying to talk to the same port (DPID_BASE_PORT)? > > The test starts and stops dpid. > GNU/Linux. > lsof -i doesn't show anything else doing anything. > > > Are you trying to run all from ~/.dillo, or a global install? > > All from ~/.dillo I removed the dpidrc and was looking at things, wasn't enlightened, wrote a new one, and now it's working. Evidently there was something wrong in the first one. Hurray! I did notice that dpid was making 8 dpi service entries from local, and then 8 more because it's regarding (perhaps rightly) my dpi_dir line as pointing to system dpis even though it's just pointing to the local ones. The 16 entries didn't seem to be harming anything, though. From dtikhonov at yahoo.com Tue Nov 3 19:00:37 2009 From: dtikhonov at yahoo.com (Dmitri Tikhonov) Date: Tue Nov 3 19:01:32 2009 Subject: [Dillo-dev] PATCH: don't force selection of first element in multi-select input. Message-ID: <837874.84441.qm@web57005.mail.re3.yahoo.com> Hi all, Great job on dillo! Below is a patch that prevents the browser from selecting the first element of a multi-select input. Thanks, - Dmitri. --- a/src/form.cc Mon Nov 02 13:41:37 2009 -0300 +++ b/src/form.cc Tue Nov 03 12:57:02 2009 -0500 @@ -767,8 +767,8 @@ void Html_tag_close_select(DilloHtml *ht DilloHtmlInput *input = Html_get_current_input(html); DilloHtmlSelect *select = input->select; - // BUG(?): should not do this for MULTI selections - select->ensureSelection (); + if (DILLO_HTML_INPUT_SEL_LIST != input->type) + select->ensureSelection (); SelectionResource *res = (SelectionResource*)input->embed->getResource(); select->addOptionsTo (res); From corvid at lavabit.com Tue Nov 3 20:01:42 2009 From: corvid at lavabit.com (corvid) Date: Tue Nov 3 20:06:21 2009 Subject: [Dillo-dev] PATCH: don't force selection of first element in multi-select input. In-Reply-To: <837874.84441.qm@web57005.mail.re3.yahoo.com> References: <837874.84441.qm@web57005.mail.re3.yahoo.com> Message-ID: <20091103190142.GB3748@local.gobigwest.com> Dmitri wrote: > Hi all, Hi Dmitri > Great job on dillo! :) > Below is a patch that prevents the browser from selecting the first element of a multi-select input. It looks like that would change the behaviour for size > 1 even if multiple is not set. *digs into the spec a little* Technically, section 17.6.1 just says that "If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined", as opposed to coming out and saying that we don't have to preselect _any_ for the multiple case if we don't want to. Checking good old firefox, let's see... If size is 1 and multiple is not set, one has to be selected in the option menu, of course. If size > 1, it does not force a selection, regardless of whether multiple is set. For some reason, that seems more reasonable to me in the multiple case than in the non-multiple case. But if we want to simply copy firefox here and we know that it doesn't break websites, I'd be all right with that. From dtikhonov at yahoo.com Wed Nov 4 00:28:02 2009 From: dtikhonov at yahoo.com (Dmitri Tikhonov) Date: Wed Nov 4 00:28:57 2009 Subject: [Dillo-dev] PATCH: don't force selection of first element in multi-select input. In-Reply-To: <20091103190142.GB3748@local.gobigwest.com> References: <837874.84441.qm@web57005.mail.re3.yahoo.com> <20091103190142.GB3748@local.gobigwest.com> Message-ID: <438369.31337.qm@web57001.mail.re3.yahoo.com> > It looks like that would change the behaviour for size > 1 even if > multiple is not set. I see what you mean, there's a bug in my patch. I did not see that rows == 1 && multi == false in Html_tag_open_select(). I will try to come up with a new one... I need to save the 'multi' somewhere and then be able to check it in Html_tag_close_select(). C++ is not my forte. - Dmitri. From furaisanjin at gmail.com Wed Nov 4 13:04:40 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Nov 4 13:05:35 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <20091103151030.GA5291@local.gobigwest.com> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> <20091103151030.GA5291@local.gobigwest.com> Message-ID: <144aa14b0911040404o455b3479o5b4275af20b7f55f@mail.gmail.com> 2009/11/4 corvid : > I don't see where the tag variable is set to anything at all in tip. Agree. > I don't get a crash, but I get gibberish in the page bugs. That's interesting aspect in Linux, isn't it? How can you access to memory pointed by none-initialized variable in Linux? Regards, furaisanjin From jcid at dillo.org Wed Nov 4 13:31:47 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Nov 4 13:32:09 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <144aa14b0911040404o455b3479o5b4275af20b7f55f@mail.gmail.com> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> <20091103151030.GA5291@local.gobigwest.com> <144aa14b0911040404o455b3479o5b4275af20b7f55f@mail.gmail.com> Message-ID: <20091104123147.GA3127@dillo.org> On Wed, Nov 04, 2009 at 09:04:40PM +0900, furaisanjin wrote: > 2009/11/4 corvid : > > I don't see where the tag variable is set to anything at all in tip. > > Agree. > > > I don't get a crash, but I get gibberish in the page bugs. > > That's interesting aspect in Linux, isn't it? How can you access to > memory pointed by none-initialized variable in Linux? Please try Hg tip and report. BTW, are you using some BSD? -- Cheers Jorge.- From jcid at dillo.org Wed Nov 4 13:33:52 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Nov 4 13:33:59 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <20091103151030.GA5291@local.gobigwest.com> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> <20091103151030.GA5291@local.gobigwest.com> Message-ID: <20091104123351.GB3127@dillo.org> On Tue, Nov 03, 2009 at 03:10:31PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > > Hi. > > > > > > I don't try all pages but at least there are several pages where dillo > > > keeps crashing. One example is > > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > > shows something like this. > > > > It doesn't crash here... :P > > > > The were a couple of patches for cleanup_at_close, please > > try from the repository without them (upto 1404:d4a8309dc63c), > > and let us know how it goes. > > I don't see where the tag variable is set to anything at all in tip. > I don't get a crash, but I get gibberish in the page bugs. Right, I made hurried modifications to a good patch and that bug slipped in. -- Cheers Jorge.- From furaisanjin at gmail.com Wed Nov 4 14:25:14 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Nov 4 14:26:36 2009 Subject: [Dillo-dev] Crashes at bizmakoto.jp In-Reply-To: <20091104123147.GA3127@dillo.org> References: <144aa14b0911021619w4ab32697t12723e7039ab1b92@mail.gmail.com> <20091103113332.GB3656@dillo.org> <20091103151030.GA5291@local.gobigwest.com> <144aa14b0911040404o455b3479o5b4275af20b7f55f@mail.gmail.com> <20091104123147.GA3127@dillo.org> Message-ID: <144aa14b0911040525w642ffca5u3fd1cb27d3db03ef@mail.gmail.com> 2009/11/4 Jorge Arellano Cid : > ?Please try Hg tip and report. OK, now the problem is solved. > ?BTW, are you using some BSD? Yes, I'm using FreeBSD as I reported in compilation problem. Regards, furaisanjin From furaisanjin at gmail.com Wed Nov 4 23:45:20 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Nov 4 23:46:44 2009 Subject: [Dillo-dev] Style sheet question (centering and list-style-type) Message-ID: <144aa14b0911041445r1727bfc2h19f8e8eadd157e71@mail.gmail.com> Hi all. I'm wondering how this web page will be rendered. test Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin From corvid at lavabit.com Thu Nov 5 02:12:10 2009 From: corvid at lavabit.com (corvid) Date: Thu Nov 5 02:17:00 2009 Subject: [Dillo-dev] Style sheet question (centering and list-style-type) In-Reply-To: <144aa14b0911041445r1727bfc2h19f8e8eadd157e71@mail.gmail.com> References: <144aa14b0911041445r1727bfc2h19f8e8eadd157e71@mail.gmail.com> Message-ID: <20091105011210.GA13063@local.gobigwest.com> It should be fixed now. From furaisanjin at gmail.com Thu Nov 5 12:48:19 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Thu Nov 5 12:49:13 2009 Subject: [Dillo-dev] Style sheet question (centering and list-style-type) In-Reply-To: <20091105011210.GA13063@local.gobigwest.com> References: <144aa14b0911041445r1727bfc2h19f8e8eadd157e71@mail.gmail.com> <20091105011210.GA13063@local.gobigwest.com> Message-ID: <144aa14b0911050348l6693cb93y57062b1d350f606b@mail.gmail.com> 2009/11/5 corvid : > It should be fixed now. Thank you. Now pages look better. Regards, furaisanjin From onepoint at starurchin.org Sat Nov 7 17:50:24 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sat Nov 7 17:51:20 2009 Subject: [Dillo-dev] [patch]: fix the default style to match Message-ID: <20091107165024.GB12868@omphalos.singularity> I had assumed that the style would be the same as the style but with bold and centering added, so I was surprised to see that it's not. The style has some border styling and padding that the style does not, which seems wrong to me. I'm attaching a patch that brings the style in line with my expectations, plus a test file and before/after screenshots. Please comment! Regards, Jeremy Henty -------------- next part -------------- diff -r f44bb8d39e5a -r d0288628c310 src/css.cc --- a/src/css.cc Tue Dec 09 14:28:50 2008 +0000 +++ b/src/css.cc Sat Nov 07 11:56:12 2009 +0000 @@ -583,7 +583,7 @@ "table {border-style: outset; border-spacing: 1px}" "td {border-style: inset; padding: 2px}" "thead, tbody, tfoot {vertical-align: middle}" - "th {font-weight: bolder; text-align: center}" + "th {font-weight: bolder; text-align: center border-style: inset; padding: 2px}" "code, tt, pre, samp, kbd {font-family: monospace}"; CssParser::parse (NULL, NULL, this, cssBuf, strlen (cssBuf), -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091107/886b72fd/td_th.html -------------- next part -------------- A non-text attachment was scrubbed... Name: 00_before.png Type: image/png Size: 1086 bytes Desc: not available Url : /pipermail/attachments/20091107/886b72fd/00_before.png -------------- next part -------------- A non-text attachment was scrubbed... Name: 01_after.png Type: image/png Size: 1085 bytes Desc: not available Url : /pipermail/attachments/20091107/886b72fd/01_after.png From Johannes.Hofmann at gmx.de Sat Nov 7 18:26:30 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Nov 7 18:28:52 2009 Subject: [Dillo-dev] [patch]: fix the default style to match In-Reply-To: <20091107165024.GB12868@omphalos.singularity> References: <20091107165024.GB12868@omphalos.singularity> Message-ID: <20091107172630.GA2591@blob.baaderstrasse.com> On Sat, Nov 07, 2009 at 04:50:24PM +0000, Jeremy Henty wrote: > > I had assumed that the style would be the same as the style > but with bold and centering added, so I was surprised to see that it's > not. The style has some border styling and padding that the > style does not, which seems wrong to me. I'm attaching a patch that > brings the style in line with my expectations, plus a test file > and before/after screenshots. Please comment! Agreed. I committed a slightly adjusted fix. Thanks, Johannes PS: There may be more glitches in the default user-agent style. Please report any strangeness. From Johannes.Hofmann at gmx.de Sat Nov 7 19:23:43 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Nov 7 19:26:05 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091101212418.GC2763@dillo.org> References: <20091101212418.GC2763@dillo.org> Message-ID: <20091107182343.GA3383@blob.baaderstrasse.com> On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote: > Hi, > > Today the big work on DPI/DPIP was committed! > > The new framework and API is easier to use and more powerful. > Lots of bugs and constraints were removed in the process. It was > a lot of work but now is easier to fix and implement new things. > After all the DPI framework was growing as new needs arose and it > needed a rewrite since long ago. > > There're still pending patches and docs. Details are in the > Changelog and Mercurial repo (hg log -v|less). > > One of them is the new select() based file dpi. It should be > faster and use less resources (all happens in a single process > now). > > Note: currently the code uses Internet Domain sockets instead > of Unix domain sockets. This was initially meant for MINIX, but > in the process several bugs were fixed, the code restructured, > added more error handling and improved in general. In the future > we may go back to UDS, but the cleanup gains will remain. > > Please test and enjoy. For now I can just confirm that it works nice on DragonFly :-) Do you think it would be a good time now, to look into the view source dpi thing again? Cheers, Johannes From Hole.destructor at gmx.de Sat Nov 7 22:16:34 2009 From: Hole.destructor at gmx.de (Alexander Voigt) Date: Sat Nov 7 22:17:30 2009 Subject: [Dillo-dev] Dillo package for Ubuntu 9.10 Message-ID: <20091107211634.GA5314@alex-laptop> Dear Dillo developers, could anyone be so kind and build a Dillo package (with ssl enabled) and a FLTK2 package for the new Ubuntu version 9.10 Karmic Koala? Many thanks in advance, Alexander Voigt From jcid at dillo.org Sun Nov 8 14:15:43 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Nov 8 14:16:20 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091107182343.GA3383@blob.baaderstrasse.com> References: <20091101212418.GC2763@dillo.org> <20091107182343.GA3383@blob.baaderstrasse.com> Message-ID: <20091108131543.GA2405@dillo.org> On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote: > On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > Today the big work on DPI/DPIP was committed! > > > > The new framework and API is easier to use and more powerful. > > Lots of bugs and constraints were removed in the process. It was > > a lot of work but now is easier to fix and implement new things. > > After all the DPI framework was growing as new needs arose and it > > needed a rewrite since long ago. > > > > There're still pending patches and docs. Details are in the > > Changelog and Mercurial repo (hg log -v|less). > > > > One of them is the new select() based file dpi. It should be > > faster and use less resources (all happens in a single process > > now). > > > > Note: currently the code uses Internet Domain sockets instead > > of Unix domain sockets. This was initially meant for MINIX, but > > in the process several bugs were fixed, the code restructured, > > added more error handling and improved in general. In the future > > we may go back to UDS, but the cleanup gains will remain. > > > > Please test and enjoy. > > For now I can just confirm that it works nice on DragonFly :-) Excellent. > Do you think it would be a good time now, to look into the view > source dpi thing again? The buffer size constraint and atomicity transfer hope (left to the OS) were removed. DPIP implementation handles it internally now. I was planning to work on the view source dpi a bit and at least advance it until the dpi gets the whole file so you can do the funny part. I can't but feel a bit guilty by the work you have put on it only to discover the framework was not up to the task. The DPIP framework grew by extending it to each new dpi needs, and there were constraints. This rewrite was necessary to make it more reliable in the concept, and not ad-hoc to the task. BTW, I still have to turn https into a server dpi to remove the dialog-storm bug, and to give a look into the cookies dpi to make it distinguish among different instances of dillo. View source is the first on the list, so if I were you I'd keep working on the scrolling patch and wait until Jorge commits. :) Or at your own choice let him finish the whole view source thing! -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Sun Nov 8 18:08:58 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Nov 8 18:11:21 2009 Subject: [Dillo-dev] Big changes in DPI framework and API In-Reply-To: <20091108131543.GA2405@dillo.org> References: <20091101212418.GC2763@dillo.org> <20091107182343.GA3383@blob.baaderstrasse.com> <20091108131543.GA2405@dillo.org> Message-ID: <20091108170858.GB1053@blob.baaderstrasse.com> On Sun, Nov 08, 2009 at 10:15:43AM -0300, Jorge Arellano Cid wrote: > On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Today the big work on DPI/DPIP was committed! > > > > > > The new framework and API is easier to use and more powerful. > > > Lots of bugs and constraints were removed in the process. It was > > > a lot of work but now is easier to fix and implement new things. > > > After all the DPI framework was growing as new needs arose and it > > > needed a rewrite since long ago. > > > > > > There're still pending patches and docs. Details are in the > > > Changelog and Mercurial repo (hg log -v|less). > > > > > > One of them is the new select() based file dpi. It should be > > > faster and use less resources (all happens in a single process > > > now). > > > > > > Note: currently the code uses Internet Domain sockets instead > > > of Unix domain sockets. This was initially meant for MINIX, but > > > in the process several bugs were fixed, the code restructured, > > > added more error handling and improved in general. In the future > > > we may go back to UDS, but the cleanup gains will remain. > > > > > > Please test and enjoy. > > > > For now I can just confirm that it works nice on DragonFly :-) > > Excellent. > > > Do you think it would be a good time now, to look into the view > > source dpi thing again? > > The buffer size constraint and atomicity transfer hope (left to > the OS) were removed. DPIP implementation handles it internally > now. > > I was planning to work on the view source dpi a bit and at > least advance it until the dpi gets the whole file so you can > do the funny part. I can't but feel a bit guilty by the work you > have put on it only to discover the framework was not up to the > task. The DPIP framework grew by extending it to each new dpi > needs, and there were constraints. This rewrite was necessary to > make it more reliable in the concept, and not ad-hoc to the task. No problem at all. I'm glad if things get simpler. > > BTW, I still have to turn https into a server dpi to remove the > dialog-storm bug, and to give a look into the cookies dpi to make > it distinguish among different instances of dillo. View source is > the first on the list, so if I were you I'd keep working on the > scrolling patch and wait until Jorge commits. :) Or at your own > choice let him finish the whole view source thing! I have updated the scrolling patch, but came to the conclusion, that it is not a good idea - at least not in the way I did it originally: I have made the scrollbars part of the UI and ripped out the code that deals with scrollbar widths in layout.cc. But then I thought about frames, and there we potentially need scrollbars for every frame. So for now will leave things as they are and focus on fixing real bugs. Cheers, Johannes From furaisanjin at gmail.com Sun Nov 8 23:59:20 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Mon Nov 9 00:00:20 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read Message-ID: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> Hi all. This might be FreeBSD specific issue but I have EAGAIN loop in IO_read. I don't know anything yet why this happens but at some point read function keeps returning EAGAIN in IO_read and nothing is read. Do you have any idea how to investigate this further? I think this happens after DPI big change. Regards, furaisanjin From jcid at dillo.org Mon Nov 9 03:15:41 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 9 03:16:17 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> Message-ID: <20091109021541.GB2405@dillo.org> On Mon, Nov 09, 2009 at 07:59:20AM +0900, furaisanjin wrote: > Hi all. > > This might be FreeBSD specific issue but I have EAGAIN loop in > IO_read. I don't know anything yet why this happens but at some point > read function keeps returning EAGAIN in IO_read and nothing is read. > Do you have any idea how to investigate this further? I think this > happens after DPI big change. How do you trigger the problem? It's possible that something weird is happening. Linux behavior differs from BSD socket implementations. If you isolate a way to reproduce the bug, we may ask other *BSD users to test, and I'd have a hint of the code path. -- Cheers Jorge.- From furaisanjin at gmail.com Mon Nov 9 04:05:30 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Mon Nov 9 04:06:23 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109021541.GB2405@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> Message-ID: <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> I dont't know any trigger yet. I just browse pages and occasionally the problem happens. There isn't any specific page either. Regards, furaisanjin 2009/11/9, Jorge Arellano Cid : > On Mon, Nov 09, 2009 at 07:59:20AM +0900, furaisanjin wrote: >> Hi all. >> >> This might be FreeBSD specific issue but I have EAGAIN loop in >> IO_read. I don't know anything yet why this happens but at some point >> read function keeps returning EAGAIN in IO_read and nothing is read. >> Do you have any idea how to investigate this further? I think this >> happens after DPI big change. > > How do you trigger the problem? > > It's possible that something weird is happening. Linux behavior > differs from BSD socket implementations. If you isolate a way to > reproduce the bug, we may ask other *BSD users to test, and I'd > have a hint of the code path. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev@dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > From jcid at dillo.org Mon Nov 9 15:34:36 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 9 15:35:13 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> Message-ID: <20091109143436.GA2341@dillo.org> On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > I dont't know any trigger yet. I just browse pages and occasionally > the problem happens. There isn't any specific page either. The point is we have massive changes in the DPI area, not in dillo. If you trigger it while browsing HTTP, DPI is out of the equation. If it happens with HTTPS, DPI participates. I'd expect you not being able to trigger the bug by using the file dpi, but if you can with plain HTTP it's a surprise. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Nov 9 19:24:45 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Nov 9 19:31:13 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109143436.GA2341@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> Message-ID: <20091109182445.GA5807@blob.baaderstrasse.com> On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > I dont't know any trigger yet. I just browse pages and occasionally > > the problem happens. There isn't any specific page either. > > The point is we have massive changes in the DPI area, not in > dillo. If you trigger it while browsing HTTP, DPI is out of the > equation. If it happens with HTTPS, DPI participates. > > I'd expect you not being able to trigger the bug by using the > file dpi, but if you can with plain HTTP it's a surprise. Not 100% sure if it is the same issue, but I can crash dillo by going to the bookmark page and then keep Ctrl-r pressed so that it reloads continiously. After a while I get a segmentation fault, but no proper stack unfortunately. Cheers, Johannes From jcid at dillo.org Mon Nov 9 19:40:58 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Nov 9 19:42:15 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109182445.GA5807@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> Message-ID: <20091109184058.GC3337@dillo.org> On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Was the crash possible before the DPI changes? -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Nov 9 20:00:43 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Nov 9 20:03:40 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109184058.GC3337@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> Message-ID: <20091109190043.GA7966@blob.baaderstrasse.com> On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? No. BTW. I can now reproduce it on Linux under valgrind. Things seem to be ok for a while until suddenly: [bookmarks dpi]: (v.13): accepting connections... [bookmarks dpi]: (v.13): accepting connections... ==21677== Warning: invalid file descriptor 1019 in syscall socket() ==21677== Warning: invalid file descriptor 1019 in syscall pipe() ==21677== Invalid read of size 4 ==21677== at 0x8059D48: a_Url_str (url.c:71) ==21677== by 0x8059F22: a_Url_dup (url.c:425) ==21677== by 0x80552D7: a_Bw_add_url (bw.c:210) ==21677== by 0x805B9E0: Nav_open_url (nav.c:240) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80DEF20: fltk::TabGroup::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x8054C48: CustTabGroup::handle(int) (uicmd.cc:315) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80BBAFC: fltk::Group::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F26A3: fltk::Window::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== Address 0x447a4d0 is 0 bytes inside a block of size 60 free'd ==21677== at 0x4022B8A: free (vg_replace_malloc.c:323) ==21677== by 0x805B6B2: a_Nav_cancel_expect (nav.c:252) ==21677== by 0x805F91D: a_Capi_ccc (capi.c:610) ==21677== by 0x805A352: a_Chain_fcb (chain.c:113) ==21677== by 0x8081B11: a_Dpi_ccc (dpi.c:713) ==21677== by 0x8081A3A: a_Dpi_ccc (dpi.c:689) ==21677== by 0x805A3D2: a_Chain_bcb (chain.c:136) ==21677== by 0x806012B: a_Capi_dpi_send_cmd (capi.c:493) ==21677== by 0x8060AB9: a_Capi_open_url (capi.c:365) ==21677== by 0x805B9B9: Nav_open_url (nav.c:238) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) and so on. Cheers, Johannes PS: While looking at the code I found that Dpi_make_socket_fd() could be simplified to just: return socket(AF_INET, SOCK_STREAM, 0); From Johannes.Hofmann at gmx.de Mon Nov 9 20:27:23 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Nov 9 20:33:10 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109184058.GC3337@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> Message-ID: <20091109192723.GA8083@blob.baaderstrasse.com> On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? One more thing. There is a file descriptor leak you can see with diff -r 8535113920b1 src/IO/dpi.c --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 @@ -90,7 +90,7 @@ static void Dpi_close_fd(int fd) { int st; - +fprintf(stderr, "===> close %d\n", fd); dReturn_if (fd < 0); do st = close(fd); @@ -432,6 +432,7 @@ if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { ret = fd; } +fprintf(stderr, "===> socket %d\n", fd); return ret; } Each time one accesses the bookmarks page one fd is leaked. I think there is also some close()'s missing in the error cases. Cheers, Johannes From jcid at dillo.org Tue Nov 10 16:56:48 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 10 16:57:27 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109182445.GA5807@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> Message-ID: <20091110155648.GE3337@dillo.org> On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. OK, I found the bug! Patch commit soon... -- Cheers Jorge.- From jcid at dillo.org Tue Nov 10 21:45:48 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 10 21:46:24 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109182445.GA5807@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> Message-ID: <20091110204548.GF3337@dillo.org> On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Yes, a FD leak was responsible. -- Cheers Jorge.- From jcid at dillo.org Tue Nov 10 21:48:12 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 10 21:48:47 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109190043.GA7966@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109190043.GA7966@blob.baaderstrasse.com> Message-ID: <20091110204812.GG3337@dillo.org> On Mon, Nov 09, 2009 at 08:00:43PM +0100, Johannes Hofmann wrote: > > PS: While looking at the code I found that Dpi_make_socket_fd() > could be simplified to just: > > return socket(AF_INET, SOCK_STREAM, 0); Yes, it was coded that way to set socket options from a single function easily. When those proved unnecessary, the skeleton was left just in case. -- Cheers Jorge.- From jcid at dillo.org Tue Nov 10 21:51:08 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 10 21:51:44 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091109192723.GA8083@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> Message-ID: <20091110205108.GH3337@dillo.org> On Mon, Nov 09, 2009 at 08:27:23PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > > the problem happens. There isn't any specific page either. > > > > > > > > The point is we have massive changes in the DPI area, not in > > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > > equation. If it happens with HTTPS, DPI participates. > > > > > > > > I'd expect you not being able to trigger the bug by using the > > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > > going to the bookmark page and then keep Ctrl-r pressed so that it > > > reloads continiously. After a while I get a segmentation fault, but > > > no proper stack unfortunately. > > > > Was the crash possible before the DPI changes? > > One more thing. There is a file descriptor leak you can see with > > diff -r 8535113920b1 src/IO/dpi.c > --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 > +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 > @@ -90,7 +90,7 @@ > static void Dpi_close_fd(int fd) > { > int st; > - > +fprintf(stderr, "===> close %d\n", fd); > dReturn_if (fd < 0); > do > st = close(fd); > @@ -432,6 +432,7 @@ > if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { > ret = fd; > } > +fprintf(stderr, "===> socket %d\n", fd); > return ret; > } > > > Each time one accesses the bookmarks page one fd is leaked. I think > there is also some close()'s missing in the error cases. No FD leak here, the respective FD is closed by IO, although there were a couple of FD leaks elsewhere (fixed in repo). BTW, in the process I learnt this trick (GNU/Linux): ls -l /proc/`pgrep dillo`/fd -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Tue Nov 10 22:00:47 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Nov 10 22:03:41 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091110204812.GG3337@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109190043.GA7966@blob.baaderstrasse.com> <20091110204812.GG3337@dillo.org> Message-ID: <20091110210047.GA10959@blob.baaderstrasse.com> On Tue, Nov 10, 2009 at 05:48:12PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 08:00:43PM +0100, Johannes Hofmann wrote: > > > > PS: While looking at the code I found that Dpi_make_socket_fd() > > could be simplified to just: > > > > return socket(AF_INET, SOCK_STREAM, 0); > > Yes, it was coded that way to set socket options from a single > function easily. When those proved unnecessary, the skeleton was > left just in case. Understood, but I thought the body of the function could be simplified like this: static int Dpi_make_socket_fd() { return socket(AF_INET, SOCK_STREAM, 0); } Cheers, Johannes From Johannes.Hofmann at gmx.de Tue Nov 10 22:02:02 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Nov 10 22:18:04 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091110205108.GH3337@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> Message-ID: <20091110210202.GB10959@blob.baaderstrasse.com> On Tue, Nov 10, 2009 at 05:51:08PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 08:27:23PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > > > the problem happens. There isn't any specific page either. > > > > > > > > > > The point is we have massive changes in the DPI area, not in > > > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > > > equation. If it happens with HTTPS, DPI participates. > > > > > > > > > > I'd expect you not being able to trigger the bug by using the > > > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > > > going to the bookmark page and then keep Ctrl-r pressed so that it > > > > reloads continiously. After a while I get a segmentation fault, but > > > > no proper stack unfortunately. > > > > > > Was the crash possible before the DPI changes? > > > > One more thing. There is a file descriptor leak you can see with > > > > diff -r 8535113920b1 src/IO/dpi.c > > --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 > > +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 > > @@ -90,7 +90,7 @@ > > static void Dpi_close_fd(int fd) > > { > > int st; > > - > > +fprintf(stderr, "===> close %d\n", fd); > > dReturn_if (fd < 0); > > do > > st = close(fd); > > @@ -432,6 +432,7 @@ > > if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { > > ret = fd; > > } > > +fprintf(stderr, "===> socket %d\n", fd); > > return ret; > > } > > > > > > Each time one accesses the bookmarks page one fd is leaked. I think > > there is also some close()'s missing in the error cases. > > No FD leak here, the respective FD is closed by IO, although > there were a couple of FD leaks elsewhere (fixed in repo). Yes, problem is gone, nice! Cheers, Johannes From jcid at dillo.org Tue Nov 10 22:46:45 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Nov 10 22:47:21 2009 Subject: [Dillo-dev] weird font Message-ID: <20091110214645.GA13700@dillo.org> Hi, On some sites I get weird fonts. Today I got to isolate the problem. See attached file. Here it displays like this: http://www.dillo.org/test/xmp2.png The embedded CSS says: pre { font-family: MS Courier New, Courier, monospace; } If I remove "MS Courier New", it works OK. Any clues? -- Cheers Jorge.- -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/attachments/20091110/c910f9aa/xmp2.html From Johannes.Hofmann at gmx.de Tue Nov 10 23:06:30 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Nov 10 23:08:53 2009 Subject: [Dillo-dev] weird font In-Reply-To: <20091110214645.GA13700@dillo.org> References: <20091110214645.GA13700@dillo.org> Message-ID: <20091110220630.GA11581@blob.baaderstrasse.com> Hi Jorge, On Tue, Nov 10, 2009 at 06:46:45PM -0300, Jorge Arellano Cid wrote: > Hi, > > On some sites I get weird fonts. Today I got to isolate the > problem. See attached file. Here it displays like this: > > http://www.dillo.org/test/xmp2.png > > The embedded CSS says: > > pre { font-family: MS Courier New, Courier, monospace; } > > If I remove "MS Courier New", it works OK. > Any clues? There are multiple issues with font selection: * The CSS parser only returns the part until the first blank ('MS' in this case). * StyleEngine currently does not handle comma separated font name lists (see \todo comment). * ::fltk::font(name, fa); in fltkplatform.cc does not offer a way to determine whether a font with that name actually exists on the system. Instead if no exact match can be found, it guesses a replacement font. This makes it impossible for dillo to choose the right one from a given list. In your specific case, fltk gets the string 'MS' and on your system it seems to find some funny font that has a similar name. Cheers, Johannes From marc at marcengelhardt.com Tue Nov 10 23:22:29 2009 From: marc at marcengelhardt.com (Marc Engelhardt) Date: Tue Nov 10 23:23:26 2009 Subject: [Dillo-dev] weird font In-Reply-To: <20091110214645.GA13700@dillo.org> References: <20091110214645.GA13700@dillo.org> Message-ID: <4AF9E7A5.2090200@marcengelhardt.com> Jorge wrote: If I remove "MS Courier New", it works OK. Any clues? I think the problem is the missing quote signs ("") before and after the font name (MS Courier New). I can be wrong, but I think that Dillo doesn't recognizes that the three words (MS, Courier, New), which normally builds the font, must be combined to build a valid font. The problem can be fixed if you add a feature to Dillo, which let Dillo recognizes that a string in a CSS rule (before a comma) represents a valid font and should be applied to the elements on the page, which are affected by the CSS rule. So, Dillo should be recognizes fonts, which are one, two or three words in length. Please keep in mind, that font names, which are between the quote signs, must also be recognized by Dillo. From jcid at dillo.org Wed Nov 11 16:35:49 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Nov 11 16:36:27 2009 Subject: [Dillo-dev] weird font In-Reply-To: <20091110220630.GA11581@blob.baaderstrasse.com> References: <20091110214645.GA13700@dillo.org> <20091110220630.GA11581@blob.baaderstrasse.com> Message-ID: <20091111153548.GC13700@dillo.org> On Tue, Nov 10, 2009 at 11:06:30PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Tue, Nov 10, 2009 at 06:46:45PM -0300, Jorge Arellano Cid wrote: > > Hi, > > > > On some sites I get weird fonts. Today I got to isolate the > > problem. See attached file. Here it displays like this: > > > > http://www.dillo.org/test/xmp2.png > > > > The embedded CSS says: > > > > pre { font-family: MS Courier New, Courier, monospace; } > > > > If I remove "MS Courier New", it works OK. > > Any clues? > > There are multiple issues with font selection: > > * The CSS parser only returns the part until the first blank > ('MS' in this case). > * StyleEngine currently does not handle comma separated font name > lists (see \todo comment). > * ::fltk::font(name, fa); in fltkplatform.cc does not offer a way to > determine whether a font with that name actually exists on the > system. Instead if no exact match can be found, it guesses a > replacement font. This makes it impossible for dillo to choose the > right one from a given list. > > In your specific case, fltk gets the string 'MS' and on your system > it seems to find some funny font that has a similar name. Thanks for the detailed explanation. -- Cheers Jorge.- From furaisanjin at gmail.com Wed Nov 11 23:54:25 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Wed Nov 11 23:55:18 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091110210202.GB10959@blob.baaderstrasse.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> Message-ID: <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> Hi. My problem also seems to be fixed because it's very harder to reproduce the problem now. By the way, I'm a bit wondering this code and I suppose something like this. --- dillo/src/IO/dpi.c 2009-11-11 05:51:28.000000000 +0900 +++ dillo-test/src/IO/dpi.c 2009-11-11 22:05:42.000000000 +0900 @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); - } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); - } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } else { + if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); + } + if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); + } + Dpi_close_fd(sock_fd); } - Dpi_close_fd(sock_fd); return ret; } Regards, furaisanjin From jcid at dillo.org Thu Nov 12 00:38:02 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Nov 12 00:38:58 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> Message-ID: <20091111233802.GF13700@dillo.org> On Thu, Nov 12, 2009 at 07:54:25AM +0900, furaisanjin wrote: > Hi. > > My problem also seems to be fixed because it's very harder to > reproduce the problem now. Is still possible to trigger the problem (but very hard)? > By the way, I'm a bit wondering this code > and I suppose something like this. > > --- dillo/src/IO/dpi.c 2009-11-11 05:51:28.000000000 +0900 > +++ dillo-test/src/IO/dpi.c 2009-11-11 22:05:42.000000000 +0900 > @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char > > if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { > MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); > - } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { > - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); > - } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { > - MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); > + } else { > + if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { > + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); > + } > + if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { > + MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); > + } > + Dpi_close_fd(sock_fd); > } > - Dpi_close_fd(sock_fd); Dpi_close_fd() checks fd != -1 so AFAIS it's OK. BTW, I chasing a very weird bug here. I can't modify a bookmark unless I comment closing a stream on an unrelated file! This is: @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) SharedKey[i] = 0; ret = 1; } - if (In) - fclose(In); Then it works! :-P @all: The question is, is this happening only in my system or do you see the problem as well. In other words: can you modify a bookmark? -- Cheers Jorge.- From corvid at lavabit.com Thu Nov 12 01:08:33 2009 From: corvid at lavabit.com (corvid) Date: Thu Nov 12 01:13:11 2009 Subject: modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read) In-Reply-To: <20091111233802.GF13700@dillo.org> References: <20091109021541.GB2405@dillo.org> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> Message-ID: <20091112000833.GB2830@local.gobigwest.com> Jorge wrote: > BTW, I chasing a very weird bug here. I can't modify a bookmark > unless I comment closing a stream on an unrelated file! > > This is: > > @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) > SharedKey[i] = 0; > ret = 1; > } > - if (In) > - fclose(In); > > > Then it works! :-P > > @all: The question is, is this happening only in my system or do you > see the problem as well. In other words: can you modify a bookmark? I don't normally use bookmarks, but if I try it, I click submit, get Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' Nav_open_url: new url='dpi:/bm/modify' and...nothing else seems to happen. From jcid at dillo.org Thu Nov 12 01:55:12 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Nov 12 01:55:49 2009 Subject: modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read) In-Reply-To: <20091112000833.GB2830@local.gobigwest.com> References: <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> <20091112000833.GB2830@local.gobigwest.com> Message-ID: <20091112005512.GH13700@dillo.org> On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote: > Jorge wrote: > > BTW, I chasing a very weird bug here. I can't modify a bookmark > > unless I comment closing a stream on an unrelated file! > > > > This is: > > > > @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) > > SharedKey[i] = 0; > > ret = 1; > > } > > - if (In) > > - fclose(In); > > > > > > Then it works! :-P > > > > @all: The question is, is this happening only in my system or do you > > see the problem as well. In other words: can you modify a bookmark? > > I don't normally use bookmarks, but if I try it, I click submit, get > Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' > Nav_open_url: new url='dpi:/bm/modify' > > and...nothing else seems to happen. Exactly as here... and if you apply the above patch? -- Cheers Jorge.- From corvid at lavabit.com Thu Nov 12 05:28:05 2009 From: corvid at lavabit.com (corvid) Date: Thu Nov 12 05:32:43 2009 Subject: modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read) In-Reply-To: <20091112005512.GH13700@dillo.org> References: <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> <20091112000833.GB2830@local.gobigwest.com> <20091112005512.GH13700@dillo.org> Message-ID: <20091112042805.GC2830@local.gobigwest.com> Jorge wrote: > On Thu, Nov 12, 2009 at 12:08:33AM +0000, corvid wrote: > > Jorge wrote: > > > BTW, I chasing a very weird bug here. I can't modify a bookmark > > > unless I comment closing a stream on an unrelated file! > > > > > > This is: > > > > > > @@ -417,8 +417,10 @@ static int Dpi_read_comm_keys(int *port) > > > SharedKey[i] = 0; > > > ret = 1; > > > } > > > - if (In) > > > - fclose(In); > > > > > > > > > Then it works! :-P > > > > > > @all: The question is, is this happening only in my system or do you > > > see the problem as well. In other words: can you modify a bookmark? > > > > I don't normally use bookmarks, but if I try it, I click submit, get > > Nav_open_url: new url='dpi:/bm/modify?operation=modify&submit=submit.&s0=on&url1=on' > > Nav_open_url: new url='dpi:/bm/modify' > > > > and...nothing else seems to happen. > > Exactly as here... > > and if you apply the above patch? Yup, I get a new page for updating the title. From furaisanjin at gmail.com Thu Nov 12 12:47:50 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Thu Nov 12 12:48:45 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <20091111233802.GF13700@dillo.org> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <144aa14b0911081905v7288ae50vd9dafb901c53e564@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> Message-ID: <144aa14b0911120347g11773c84j90250a26c733ccbd@mail.gmail.com> 2009/11/12 Jorge Arellano Cid : > On Thu, Nov 12, 2009 at 07:54:25AM +0900, furaisanjin wrote: >> Hi. >> >> My problem also seems to be fixed because it's very harder to >> reproduce the problem now. > > ?Is still possible to trigger the problem (but very hard)? I have no idea but the problem did happen in one hour but now it's very difficult to make it happen. >> By the way, I'm a bit wondering this code >> and I suppose something like this. >> >> --- dillo/src/IO/dpi.c ?2009-11-11 05:51:28.000000000 +0900 >> +++ dillo-test/src/IO/dpi.c ? ? 2009-11-11 22:05:42.000000000 +0900 >> @@ -793,12 +793,15 @@ char *a_Dpi_send_blocking_cmd(const char >> >> ? ? if ((sock_fd = Dpi_connect_socket(server_name, TRUE)) == -1) { >> ? ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't connect to server.\n"); >> - ? } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { >> - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); >> - ? } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { >> - ? ? ?MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); >> + ? } else { >> + ? ? if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { >> + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't send message.\n"); >> + ? ? } >> + ? ? if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { >> + ? ? ? MSG_ERR("[a_Dpi_send_blocking_cmd] Can't read message.\n"); >> + ? ? } >> + ? ? Dpi_close_fd(sock_fd); >> ? ? } >> - ? Dpi_close_fd(sock_fd); > > ?Dpi_close_fd() checks fd != -1 so AFAIS it's OK. I meant Dpi_blocking_read as well. Regards, furaisanjin From furaisanjin at gmail.com Thu Nov 12 13:01:03 2009 From: furaisanjin at gmail.com (furaisanjin) Date: Thu Nov 12 13:02:00 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <144aa14b0911120347g11773c84j90250a26c733ccbd@mail.gmail.com> References: <144aa14b0911081459w362f09fcp2f87d89e43551e7f@mail.gmail.com> <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> <144aa14b0911120347g11773c84j90250a26c733ccbd@mail.gmail.com> Message-ID: <144aa14b0911120401w67ad761ua16d474f7e56c703@mail.gmail.com> This misleads, so I clarify. 2009/11/12 furaisanjin : > I have no idea but the problem did happen in one hour but now it's > very difficult to make it happen. I haven't seen it since I applied the patch. Regards, furaisanjin From jcid at dillo.org Thu Nov 12 15:33:32 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Nov 12 15:34:23 2009 Subject: [Dillo-dev] EAGAIN loop in IO_read In-Reply-To: <144aa14b0911120401w67ad761ua16d474f7e56c703@mail.gmail.com> References: <20091109143436.GA2341@dillo.org> <20091109182445.GA5807@blob.baaderstrasse.com> <20091109184058.GC3337@dillo.org> <20091109192723.GA8083@blob.baaderstrasse.com> <20091110205108.GH3337@dillo.org> <20091110210202.GB10959@blob.baaderstrasse.com> <144aa14b0911111454h3c675bffo875f43b7cade9d61@mail.gmail.com> <20091111233802.GF13700@dillo.org> <144aa14b0911120347g11773c84j90250a26c733ccbd@mail.gmail.com> <144aa14b0911120401w67ad761ua16d474f7e56c703@mail.gmail.com> Message-ID: <20091112143332.GI13700@dillo.org> On Thu, Nov 12, 2009 at 09:01:03PM +0900, furaisanjin wrote: > This misleads, so I clarify. > > 2009/11/12 furaisanjin : > > > I have no idea but the problem did happen in one hour but now it's > > very difficult to make it happen. > > I haven't seen it since I applied the patch. Thanks, it's good to hear that! ;) -- Cheers Jorge.- From onepoint at starurchin.org Fri Nov 13 08:32:39 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Fri Nov 13 08:33:33 2009 Subject: [Dillo-dev] Q: why do we defer loading linked stylesheets? Message-ID: <20091113073239.GA3080@omphalos.singularity> Why do we defer loading the CSS stylesheets named in elements until the element is closed? In html.cc, Html_tag_close_head() has the comment "charset is already set, load remote stylesheets now", but I don't understand the significance of the charset. I am asking because I'd like to patch Dillo to add @import-ed stylesheets to the browser window popup menu, just as it already does for -ed stylesheets. At the moment this causes all sorts of code branches (is the @import in a -ed file or an embedded