- Dillo-dev - lists.mailman3.com

perhaps an iterator bug

by corvid＠lavabit.com

I wrote, back in February: > I was trying the new search functionality a bit more > and found this (it's also present in my Dec 2008 dillo*). > > With the page: > > <table> > <tr><td>no close-tr > <tr><td>has a close-tr</tr> > <tr><td>here's another line</tr> > </table> > > if I search for "rh", it finds one instance of it > split between the second and third table rows. At the time, I didn't recognize what the exact problem was. Now it dawns on me that the difference is really that line 2's text has whitespace before the next tag, and line 3's doesn't. It would be nice if the iterators thought of cells as being separated by whitespace, but I don't know yet whether there's a good and simple way to do that...

Sept. 3, 2009

whattheinternetknowsaboutyou

by corvid＠lavabit.com

Johannes wrote: > this http://wtikay.com/docs/details.html is quite interesting. Dillo > is not vulnerable, but we should keep this in mind when implementing > background image support. Are background images the only way for them to pull that off?

Sept. 2, 2009

whattheinternetknowsaboutyou

by Johannes.Hofmann＠gmx.de

Hi, this http://wtikay.com/docs/details.html is quite interesting. Dillo is not vulnerable, but we should keep this in mind when implementing background image support. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by Johannes.Hofmann＠gmx.de

On Wed, Sep 02, 2009 at 05:02:28PM +0000, corvid wrote: > Johannes wrote: > > corvid, you have just fixed an issue with horizontal scrolling > > during search. > > While testing it I realized, that horizontal scrolling during search > > does not work at all with plain text. Any idea why? > > Actually, I made a patch for that last night (attached). > > getAllocation() determines the boundaries and position > of a Word, and then Iterator's scrollTo() figures out how > to place it. > > But for plain text, the whole line is a Word, so scrollTo > was just positioning the line as a whole and considering its > work done. > > In the patch, I take start and end into account to figure out > what part of the Word we really want to see. > (The current behaviour of showing the whole word is a little > bit nicer for html with "normal"-sized Words, but...) > Cool! Please commit. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by corvid＠lavabit.com

Johannes wrote: > corvid, you have just fixed an issue with horizontal scrolling > during search. > While testing it I realized, that horizontal scrolling during search > does not work at all with plain text. Any idea why? Actually, I made a patch for that last night (attached). getAllocation() determines the boundaries and position of a Word, and then Iterator's scrollTo() figures out how to place it. But for plain text, the whole line is a Word, so scrollTo was just positioning the line as a whole and considering its work done. In the patch, I take start and end into account to figure out what part of the Word we really want to see. (The current behaviour of showing the whole word is a little bit nicer for html with "normal"-sized Words, but...)

Sept. 2, 2009

Planning

by jcid＠dillo.org

On Tue, Sep 01, 2009 at 09:30:54PM +0200, Johannes Hofmann wrote: > On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Here are some pending issues which I've partially sorted by > > > priority (at least the top half). Please add the missing ones and > > > let's try to finish sorting it, with a view to planify our work. > > > > > > > > > * Make DIV-based pages render correctly. > > > This is the most visible rendering fault in Dillo. The > > > textblock doesn't have a way to handle it (not implemented). > > > IIRC I'm willing to dig into it and Johannes will help. > > > e.g. http://www.advogato.org/faq.html > > > > With DIV-based pages you mean floats as in > > http://www.w3.org/TR/CSS21/visuren.html#floats? > > Yes, this is the most obvious rendering problem atm. > > > > > > > > * Add blocker (this also has to do with privacy). > > > A full RE-based one may have significant overhead (test > > > required), but simple string-matching may do most of the trick. > > > I've also thought for a long time that a "don't load from > > > other sites" preference may help a lot. The whole topic needs > > > some thought but it's not hard to implement. > > > e.g. doubleclick. > > > > > > * Handle negative values in CSS. e.g. wikipedia. > > > > Actually it's dw/* that needs to be adapted to handle negative > > margins. This might be related to the floats stuff. > > > > > > > > * What will we do with xhtml? To render or not to render... > > > FF doesn't validate. BUG#732 > > > One solution is to add a notification widget area below the > > > control panel that hides/unhides as the find bar, to warn when a > > > xhtml file has detected bugs (we'd also move the meta refresh > > > warning to display here). I already have a simple patch to add > > > xhtml rendering. The widget implemetation is the missing part. > > > It should be much simpler than the close button in each tab. :-) > > > e.g. http://planet.postgresql.org/ > > > > > > * Jump to #anchor doesn't work correctly. > > > It looks like a timing issue, but the idle-call API needs a > > > review as a whole. > > > > > > * dpi for "view page source" (it re-uses search capability). > > > This requires a check of the current data-passing inside DPIP. > > > > > > * Improve the DPI development/debug framework. > > > > > > * https dialog bombing issue. BUG#868 > > > AKA make https dpi a server (i.e. not a filter dpi). > > > > > > * Render bug at http://www.directfb.org/ (and its links). The > > > table has too wide a first column. Back/Fwd solves it. > > > > Yes, I've seen this on several pages. > > > > > > > > *   handling in fltk.org > > > The relevant point is to define a consistent way to handle > > > whitespace in the textblock. > > > > Can you explain the problem a bit? > > > > > > > > * FTP download doesn't work?! > > > > wget - based downloads work mostly fine for me. Where do you see an > > issue? > > > > I've got one more point: > > > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > > boxes don't cause X11 coordinate overflows. > > E.g. on http://alpen-panoramen.de/newcomments.php > > I will try to fix that. > > Ok fix committed. This took a lot longer than expected. I almost had > full polygon clipping implemented which is quite complex, until I > realized that it is much simpler to change Style::drawBorder() to > use rectangles and triangles instead of a single polygon for each > side. > That way we can easily clip the large part of the border (the > rectangle) and avoid X11 coordinate overflows. > It also seems that this makes dillo a bit snappier. Good, I also feel the extra snappiness! -- Cheers Jorge.-

Sept. 2, 2009

horizontal scrolling while searching

by Johannes.Hofmann＠gmx.de

corvid, you have just fixed an issue with horizontal scrolling during search. While testing it I realized, that horizontal scrolling during search does not work at all with plain text. Any idea why? Cheers, Johannes

Sept. 2, 2009

Planning

by Johannes.Hofmann＠gmx.de

On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Here are some pending issues which I've partially sorted by > > priority (at least the top half). Please add the missing ones and > > let's try to finish sorting it, with a view to planify our work. > > > > > > * Make DIV-based pages render correctly. > > This is the most visible rendering fault in Dillo. The > > textblock doesn't have a way to handle it (not implemented). > > IIRC I'm willing to dig into it and Johannes will help. > > e.g. http://www.advogato.org/faq.html > > With DIV-based pages you mean floats as in > http://www.w3.org/TR/CSS21/visuren.html#floats? > Yes, this is the most obvious rendering problem atm. > > > > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > e.g. doubleclick. > > > > * Handle negative values in CSS. e.g. wikipedia. > > Actually it's dw/* that needs to be adapted to handle negative > margins. This might be related to the floats stuff. > > > > > * What will we do with xhtml? To render or not to render... > > FF doesn't validate. BUG#732 > > One solution is to add a notification widget area below the > > control panel that hides/unhides as the find bar, to warn when a > > xhtml file has detected bugs (we'd also move the meta refresh > > warning to display here). I already have a simple patch to add > > xhtml rendering. The widget implemetation is the missing part. > > It should be much simpler than the close button in each tab. :-) > > e.g. http://planet.postgresql.org/ > > > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > > > * dpi for "view page source" (it re-uses search capability). > > This requires a check of the current data-passing inside DPIP. > > > > * Improve the DPI development/debug framework. > > > > * https dialog bombing issue. BUG#868 > > AKA make https dpi a server (i.e. not a filter dpi). > > > > * Render bug at http://www.directfb.org/ (and its links). The > > table has too wide a first column. Back/Fwd solves it. > > Yes, I've seen this on several pages. > > > > > *   handling in fltk.org > > The relevant point is to define a consistent way to handle > > whitespace in the textblock. > > Can you explain the problem a bit? > > > > > * FTP download doesn't work?! > > wget - based downloads work mostly fine for me. Where do you see an > issue? > > I've got one more point: > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > boxes don't cause X11 coordinate overflows. > E.g. on http://alpen-panoramen.de/newcomments.php > I will try to fix that. Ok fix committed. This took a lot longer than expected. I almost had full polygon clipping implemented which is quite complex, until I realized that it is much simpler to change Style::drawBorder() to use rectangles and triangles instead of a single polygon for each side. That way we can easily clip the large part of the border (the rectangle) and avoid X11 coordinate overflows. It also seems that this makes dillo a bit snappier. Cheers, Johannes

Sept. 1, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > do you plan to answer this mail? Sorry I've been lost with other activities. > My point here is that we should > stick with fltk2 until there is an official release of fltk1.3. Yes. I agree. We went with unreleased FLTK2 and it has caused lots of problems (despite statical linking). > If there are license issues with fltk2 they should be handled > between debian and the fltk community. Of course we could try to > help. It looks like FLTK2 is quite stalled. Of course we can knock the door again. Maybe this is also a good time to ask for fltk1.3's timeline again. The last time, the optimistic release date was near the middle of 2009. > Date: Sat, 22 Aug 2009 18:40:03 +0200 > From: Devid Antonio Filoni <devidfil(a)gmail.com> > Subject: [Dillo-dev] Switch to fltk1.3? > To: dillo-dev(a)dillo.org > > Hi, > is possible to switch to fltk1.3? I sent a lot of emails to fltk > developers trying to get the license issue of fltk2 > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > I still (after months of sent emails) haven't gotten a reply. dillo is > going to be removed from Debian and Ubuntu repositories because it > depends on removed packages and the newest dillo release cannot be > uploaded because fltk2 is not in the repositories and it cannot be > accepted due to the license issue. Is possible to switch to fltk1.3 or > to another toolkit please? > > Thanks, > Devid Antonio Filoni Hi Devid, We plan to switch to fltk1.3 soon. The point is to have a solid release date to start the port. When we started with fltk2 it was supposed to be released soon... :P I'm writing to the fltk1.3 team. Stay tuned. -- Cheers Jorge.-

Aug. 30, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Fri, Aug 28, 2009 at 09:06:06PM +0200, Johannes Hofmann wrote: > On Mon, Aug 24, 2009 at 11:29:45PM +0200, Johannes Hofmann wrote: > > On Sun, Aug 23, 2009 at 09:43:26AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Aug 20, 2009 at 08:03:57PM +0200, Johannes Hofmann wrote: > > > > On Wed, Aug 19, 2009 at 08:03:09PM +0200, Johannes Hofmann wrote: > > > > > On Tue, Aug 18, 2009 at 02:46:51PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > > > > > > > BTW: I don't remember whether a fix for the uClinux URL above was > > > > > > already committed. It didn't SEGFAULT when testing tip. > > > > > > > > > > I got some segfaults recently. I will try to get a proper stack > > > > > trace. > > > > > > > > Ok here it is. It happend after a couple of hours: > > > > > > > > Core was generated by `dillo'. > > > > Program terminated with signal 11, Segmentation fault. > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > 191 if (Info->Flags & (CCC_Ended + CCC_Aborted)) { > > > > (gdb) bt > > > > #0 a_Chain_check (FuncStr=0x80f763a "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) > > > > at chain.c:191 > > > > #1 0x0805e448 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x9274df0, Data2=0x0) > > > > at capi.c:537 > > > > #2 0x0805e5d8 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x86cf3a8, Data1=0x0, > > > > Data2=0x80f7669) at capi.c:178 > > > > #3 0x0805960d in a_Chain_fcb (Op=2, Info=0x44, Data1=0x0, Data2=0x80f7669) at chain.c:113 > > > > #4 0x0807bf82 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x92a9a20, Data1=0x8e2ff90, > > > > Data2=0x0) at dpi.c:625 > > > > #5 0x0805966d in a_Chain_bcb (Op=1, Info=0x44, Data1=0x8e2ff90, Data2=0x0) at chain.c:136 > > > > #6 0x0805eaa3 in a_Capi_dpi_send_cmd (url=0x8f30ff8, bw=0x8e2e790, > > > > cmd=0x86cf328 "<cmd='open_url' url='dpi:/bm/' '>", server=0x8e2ff90 "bookmarks", > > > > flags=<value optimized out>) at capi.c:493 > > > > #7 0x0805f3cc in a_Capi_open_url (web=0x8305208, Call=0, CbData=0x0) at capi.c:365 > > > > #8 0x0805aa05 in Nav_open_url (bw=0x8e2e790, url=0x83d1878, offset=-1) at nav.c:238 > > > > #9 0x08050c61 in UI::handle (this=0x92be3a0, event=12) at ui.cc:760 > > > > #10 0x080e22dc in fltk::Widget::send () > > > > #11 0x080d3935 in fltk::TabGroup::handle () > > > > #12 0x08054538 in CustTabGroup::handle (this=<value optimized out>, e=<value optimized out>) > > > > at uicmd.cc:312 > > > > #13 0x080e22dc in fltk::Widget::send () > > > > #14 0x080b2c0f in fltk::Group::handle () > > > > #15 0x080e4439 in fltk::Window::handle () > > > > #16 0x080e22dc in fltk::Widget::send () > > > > #17 0x080c7749 in fltk::handle () > > > > #18 0x080cac10 in fltk::handle () > > > > #19 0x080cc32d in do_queued_events () > > > > #20 0x080cc5a8 in fltk::wait () > > > > #21 0x080cc784 in fltk::run () > > > > #22 0x0804f371 in main (argc=1, argv=0xbffff654) at dillo.cc:353 > > > > Current language: auto; currently c > > > > (gdb) > > > > > > Good. > > > > > > This is hard to track and I spent a lot of time trying to > > > figure a way for it to happen. I don't yet find it, but at least > > > saw there may be a small race window while the conn is unref'ed > > > twice. > > > > > > Protection committed. Please test. > > > > > > > No crash so far! I will keep testing. > > > > I can't crash it anymore. I guess we can consider this fixed :) Good. > BTW, is the CCC simplification related to the connection limit > patch? Yes and no. Yes: it may help with memory handling. No : the simplification was originally meant to help with stop. (and it has served to iron and clean other bugs too). -- Cheers Jorge.-

Aug. 29, 2009