November 2009 - Dillo-dev - lists.mailman3.com

[patch]: trim the labels of the stylesheet menu

by onepoint＠starurchin.org

While thinking about stylesheet issues I noticed a UI problem: the stylesheet menu uses URLs as the labels of the menu items. This is unfortunate because some sites have stylesheets with insanely long URLs. (Try Wikipedia if you don't believe me!) So I'm attaching a patch that trims long URLs in the menu. This is just a UI change - no functionality is affected. Here's a demonstration of the patch on the front page of Wikipedia: http://starurchin.org/dillo/stylesheet_menu/ Notes: Since the label is no longer always the same as the label the callback must find the URL elsewhere. We put it in the user_data() of the menu item. We just copy the pointer to the DilloUrl structure, so we are assuming it will never be free()-ed while the menu is up. If I'm wrong about this the patch will need to be revised. We get a nice cleanup for free: we loose the mysterious magic constant 5 in the callback. (Bonus points if you can see what that magic constant is! Double bonus points if you can see why the code still worked when I erroneously left it in!) Please comment, Jeremy Henty

Nov. 20, 2009

modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read)

by jcid＠dillo.org

On Thu, Nov 19, 2009 at 08:10:44AM +0900, furaisanjin wrote: > Hi. > > I see the problem on FreeBSD (6.4) as well. But if I modify dillo like this, > > diff -r 0a016f48a68b src/capi.c > --- a/src/capi.c Sun Nov 15 13:00:56 2009 +0100 > +++ b/src/capi.c Thu Nov 19 08:04:20 2009 +0900 > @@ -519,7 +519,7 @@ > _MSG("a_Capi_stop_client: force=%d\n", force); > > Client = a_Cache_client_get_if_unique(Key); > - if (Client && (force || Client->BufSize == 0)) { > + if (Client && force) { > /* remove empty entries too */ > a_Capi_conn_abort_by_url(Client->Url); > } > > I don't see the problem. Because the original Dillo didn't work well > with my local HTTP proxy, I modified like above. I didn't dig out > deeper but it seems that Dillo didn't close socket connection properly > so that HTTP proxy thought the connection was still opened. Excellent! This explains the race condition to me. @all: please test the patch in the repo and report. The problem with HTTP proxy *may* be a different thing, but it also may be fixed now. Please check and report. -- Cheers Jorge.-

Nov. 20, 2009

auth segfault (Re: [Dillo-dev] Q: why do we defer loading linked stylesheets?)

by corvid＠lavabit.com

Jeremy wrote: > On Sun, Nov 15, 2009 at 05:55:11PM +0000, corvid wrote: > > Jeremy wrote: > > > On Sat, Nov 14, 2009 at 03:42:00PM +0000, corvid wrote: > > > > > > > Speaking of repush, I see that there's another bug about auth > > > > and segfaults in the bug tracker. > > > > > > Which one? > > > > 928 > > Ouch! Unfortunately this report doesn't give us much to work on. I > just reran all my auth tests and they still work. Without a specific > page to debug there's not much I can do. Any ideas? Could the fact > that the page uses frames have anything to do with the problem? It looks like a_Nav_cancel_expect() and a NULL bw is what caused the old crash, so maybe it's actually a similar problem of using stylesheets/images outside the auth domain. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-April/006248.html

Nov. 20, 2009

auth segfault (Re: [Dillo-dev] Q: why do we defer loading linked stylesheets?)

by onepoint＠starurchin.org

On Sun, Nov 15, 2009 at 05:55:11PM +0000, corvid wrote: > Jeremy wrote: > > On Sat, Nov 14, 2009 at 03:42:00PM +0000, corvid wrote: > > > > > Speaking of repush, I see that there's another bug about auth > > > and segfaults in the bug tracker. > > > > Which one? > > 928 Ouch! Unfortunately this report doesn't give us much to work on. I just reran all my auth tests and they still work. Without a specific page to debug there's not much I can do. Any ideas? Could the fact that the page uses frames have anything to do with the problem? Regards, Jeremy Henty

Nov. 19, 2009

modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read)

by furaisanjin＠gmail.com

Hi. I see the problem on FreeBSD (6.4) as well. But if I modify dillo like this, diff -r 0a016f48a68b src/capi.c --- a/src/capi.c Sun Nov 15 13:00:56 2009 +0100 +++ b/src/capi.c Thu Nov 19 08:04:20 2009 +0900 @@ -519,7 +519,7 @@ _MSG("a_Capi_stop_client: force=%d\n", force); Client = a_Cache_client_get_if_unique(Key); - if (Client && (force || Client->BufSize == 0)) { + if (Client && force) { /* remove empty entries too */ a_Capi_conn_abort_by_url(Client->Url); } I don't see the problem. Because the original Dillo didn't work well with my local HTTP proxy, I modified like above. I didn't dig out deeper but it seems that Dillo didn't close socket connection properly so that HTTP proxy thought the connection was still opened. Regards, furaisanjin

Nov. 19, 2009

modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read)

by Johannes.Hofmann＠gmx.de

On Wed, Nov 18, 2009 at 09:45:26AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 12, 2009 at 04:28:05AM +0000, corvid wrote: > > 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. > > There were two bugs in this problem: a FD leak, and an obscure > bug with socket closing. I committed a workaround that makes it > work. > > The last thing to blame is external libraries or the kernel > itself, but this bug is weird enough to keep the possibility > open. > > Not closing a completely unrelated stream (above-quoted patch) > also made it work. This makes me think that something happens in > the OS' FD handling code. The committed workaround is a usleep(2) > before closing the socket (which shouldn't be necessary AFAIU > because as from the SPEC, in that case the socket must deliver in > background). > > I've tried with different kernels (and glibc) and the same bug > shows. Corvid also reported it. The question is: Is anyone using > *BSD seeing it? > > Note: the bug is not being able to see bookmark's "Add Section" > page. Go to modify, select "add section", and submit. If you see > the page, there's no bug. > > Note2: please test with and without the workaround patch! ;) > I see the bug on DragonFly BSD with and without the workaround. However it seems to work when truss-ing the bookmarks dpi... Cheers, Johannes

Nov. 18, 2009

weird font

by jcid＠dillo.org

On Tue, Nov 17, 2009 at 11:02:38PM +0100, Johannes Hofmann wrote: > On Sun, Nov 15, 2009 at 11:15:55PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 15, 2009 at 06:16:56PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Wed, Nov 11, 2009 at 12:35:49PM -0300, Jorge Arellano Cid wrote: > > > > > 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. > > > > > > > > I just committed a fix for the first two issues. This should also > > > > fix your problem. > > > > It still does not test all font names in the list as I don't know > > > > how to do that with fltk2, but it's a step in the right direction. > > > > > > I was also sure that fltk would choose a default font for us, > > > but I was just gdbing FltkFont::FltkFont(), and ::fltk::font() > > > did come back NULL when given a font name that it didn't recognize. > > I checked fltk::font() in src/list_fonts.cxx in fltk2. It returns a > font if it finds one with a prefix that matches the given font name. > This should be good enough for our purposes. > > > > > Good that you actually tried it. Then it should be straight forward to > > implement proper font selection. > > Ok, I pushed a patch to implement proper font selection. Please give > it a try. Good. The former patch and this one solve the problem nicely. > > There might be a performance issue if we test all possiblities > > evertime the comma separated list is converted to the real font > > in StyleEngine. This might need some experiments. > > >>From my tests, the relevant code is only run a couple of times per > page, so the current implementation seems ok to me, but please > report any slowdowns. I haven't noticed slowdowns yet. FWIW, if we find nasty slowdowns, it should be easy to map some problematic font requests to our defaults as a workaround. Most probably this will have a different API/implementation/solution in fltk3. -- Cheers Jorge.-

Nov. 18, 2009

modify bookmarks (Re: [Dillo-dev] EAGAIN loop in IO_read)

by jcid＠dillo.org

On Thu, Nov 12, 2009 at 04:28:05AM +0000, corvid wrote: > 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. There were two bugs in this problem: a FD leak, and an obscure bug with socket closing. I committed a workaround that makes it work. The last thing to blame is external libraries or the kernel itself, but this bug is weird enough to keep the possibility open. Not closing a completely unrelated stream (above-quoted patch) also made it work. This makes me think that something happens in the OS' FD handling code. The committed workaround is a usleep(2) before closing the socket (which shouldn't be necessary AFAIU because as from the SPEC, in that case the socket must deliver in background). I've tried with different kernels (and glibc) and the same bug shows. Corvid also reported it. The question is: Is anyone using *BSD seeing it? Note: the bug is not being able to see bookmark's "Add Section" page. Go to modify, select "add section", and submit. If you see the page, there's no bug. Note2: please test with and without the workaround patch! ;) -- Cheers Jorge.-

Nov. 18, 2009

weird font

by Johannes.Hofmann＠gmx.de

On Sun, Nov 15, 2009 at 11:15:55PM +0100, Johannes Hofmann wrote: > On Sun, Nov 15, 2009 at 06:16:56PM +0000, corvid wrote: > > Johannes wrote: > > > On Wed, Nov 11, 2009 at 12:35:49PM -0300, Jorge Arellano Cid wrote: > > > > 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. > > > > > > I just committed a fix for the first two issues. This should also > > > fix your problem. > > > It still does not test all font names in the list as I don't know > > > how to do that with fltk2, but it's a step in the right direction. > > > > I was also sure that fltk would choose a default font for us, > > but I was just gdbing FltkFont::FltkFont(), and ::fltk::font() > > did come back NULL when given a font name that it didn't recognize. I checked fltk::font() in src/list_fonts.cxx in fltk2. It returns a font if it finds one with a prefix that matches the given font name. This should be good enough for our purposes. > > Good that you actually tried it. Then it should be straight forward to > implement proper font selection. Ok, I pushed a patch to implement proper font selection. Please give it a try. > There might be a performance issue if we test all possiblities > evertime the comma separated list is converted to the real font > in StyleEngine. This might need some experiments. >From my tests, the relevant code is only run a couple of times per page, so the current implementation seems ok to me, but please report any slowdowns. Cheers, Johannes

Nov. 17, 2009

weird font

by Johannes.Hofmann＠gmx.de

On Sun, Nov 15, 2009 at 06:16:56PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Nov 11, 2009 at 12:35:49PM -0300, Jorge Arellano Cid wrote: > > > 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. > > > > I just committed a fix for the first two issues. This should also > > fix your problem. > > It still does not test all font names in the list as I don't know > > how to do that with fltk2, but it's a step in the right direction. > > I was also sure that fltk would choose a default font for us, > but I was just gdbing FltkFont::FltkFont(), and ::fltk::font() > did come back NULL when given a font name that it didn't recognize. Good that you actually tried it. Then it should be straight forward to implement proper font selection. There might be a performance issue if we test all possiblities evertime the comma separated list is converted to the real font in StyleEngine. This might need some experiments. Cheers, Johannes

Nov. 15, 2009