- Dillo-dev - lists.mailman3.com

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/2 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Can you please describe the situation where it happens? There are 2 cases. 1. When dillo starts, cursor stays on address bar and this is the side effect of the updated codes. 2. When URL is given on address bar, cursor stays on address bar after the page rendering finishes. This isn't side effect. This may be matter of taste but I don't like this behavior. Regards, furaisanjin

Dec. 2, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Sat, Nov 28, 2009 at 01:06:21PM +0900, furaisanjin wrote: > 2009/11/28 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > I committed a slightly different patch to also cover the case when > > middle_click_opens_new_tab=NO > > > > Please test, > > I tested but I found still there were cases where cursor stayed on > address bar. Could you consider this patch? Can you please describe the situation where it happens? I'm a bit reluctant to sprinkle focus handling code all over the place. Regards, Johannes

Dec. 1, 2009

patch: anchors no longer words

by corvid＠lavabit.com

Johannes wrote: > Looks fine to me too. Maybe you could also garbage collect > core::Content::ANCHOR to avoid confusion, or is it still used? Yes, I plan to remove it.

Nov. 30, 2009

patch: anchors no longer words

by Johannes.Hofmann＠gmx.de

On Mon, Nov 30, 2009 at 10:38:08AM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 30, 2009 at 07:29:13AM +0000, corvid wrote: > > A few days ago, I tried to make addParbreak() work properly when listitems > > have anchors in the beginning (that's why they often show breaks before > > their contents), but it was quite icky -- and required more extensive > > changes than I expected. > > > > So instead, here's what we get if we pull the anchors out of the Word > > list and store them separately. Less icky. > > It looks OK to me, especially if it helps to fix the list item's > extra-line-break bug, by means of code clarity. Looks fine to me too. Maybe you could also garbage collect core::Content::ANCHOR to avoid confusion, or is it still used? Cheers, Johannes

Nov. 30, 2009

patch: anchors no longer words

by jcid＠dillo.org

On Mon, Nov 30, 2009 at 07:29:13AM +0000, corvid wrote: > A few days ago, I tried to make addParbreak() work properly when listitems > have anchors in the beginning (that's why they often show breaks before > their contents), but it was quite icky -- and required more extensive > changes than I expected. > > So instead, here's what we get if we pull the anchors out of the Word > list and store them separately. Less icky. It looks OK to me, especially if it helps to fix the list item's extra-line-break bug, by means of code clarity. -- Cheers Jorge.-

Nov. 30, 2009

patch: anchors no longer words

by corvid＠lavabit.com

A few days ago, I tried to make addParbreak() work properly when listitems have anchors in the beginning (that's why they often show breaks before their contents), but it was quite icky -- and required more extensive changes than I expected. So instead, here's what we get if we pull the anchors out of the Word list and store them separately. Less icky.

Nov. 30, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/11/28 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > I committed a slightly different patch to also cover the case when > middle_click_opens_new_tab=NO > > Please test, I tested but I found still there were cases where cursor stayed on address bar. Could you consider this patch? diff -r 292c1755001c src/web.cc --- a/src/web.cc Sat Nov 28 09:56:57 2009 +0900 +++ b/src/web.cc Sat Nov 28 12:59:41 2009 +0900 @@ -87,6 +87,7 @@ /* Let the Nav module know... */ a_Nav_expect_done(Web->bw); + a_UIcmd_focus_main_area (Web->bw); } else { /* A non-RootUrl. At this moment we only handle image-children */ After page rendering finishes, focus is changed to main area so that cursor doesn't stay on address bar. Regards, furaisanjin

Nov. 28, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote: > > On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > > > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > > > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > > >> > > > >> > I would propose something as in attached patch to ensure that > > > >> > Location is focused when opening a new (empty) tab. > > > >> > > > >> +1 > > > > > > > > +1 > > > > > > I hope the patch will be part of dillo soon. The patch works very well. > > > > @Johannes, please comment what the change is for before committing. > > I committed a slightly different patch to also cover the case when > middle_click_opens_new_tab=NO This is a good improvement. Having the Location focused in a new window == :) I notice that, after shift-button2 on a link, shift-right_arrow doesn't work until I click on things a bit.

Nov. 27, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > >> > > >> > I would propose something as in attached patch to ensure that > > >> > Location is focused when opening a new (empty) tab. > > >> > > >> +1 > > > > > > +1 > > > > I hope the patch will be part of dillo soon. The patch works very well. > > @Johannes, please comment what the change is for before committing. I committed a slightly different patch to also cover the case when middle_click_opens_new_tab=NO Please test, Johannes

Nov. 27, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Thu, Nov 26, 2009 at 08:56:52PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote: > > > On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > > > > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > > > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > > > > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > > > >> > > > > >> > I would propose something as in attached patch to ensure that > > > > >> > Location is focused when opening a new (empty) tab. > > > > >> > > > > >> +1 > > > > > > > > > > +1 > > > > > > > > I hope the patch will be part of dillo soon. The patch works very well. > > > > > > @Johannes, please comment what the change is for before committing. > > > > does anybody know, why > > BW2UI(new_bw)->tabs()->selected_child()->take_focus(); > > focusses the location text input? > > I wouldn't be surprised if fltk chooses it because it's the > UI's first child. Indeed! With below patch, the dummy CustInput get's the focus. diff -r 90fabbb4077b src/ui.cc --- a/src/ui.ccSun Nov 22 18:35:48 2009 +0100 +++ b/src/ui.ccThu Nov 26 22:06:51 2009 +0100 @@ -444,6 +444,7 @@ b->callback(clear_cb, this); b->clear_tab_to_focus(); + new CustInput(0,0,100,0,0); Input *i = Location = new CustInput(0,0,0,0,0); i->color(CuteColor); i->when(WHEN_ENTER_KEY);

Nov. 26, 2009

take_focus on a new tab

by corvid＠lavabit.com

Johannes wrote: > On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote: > > On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > > > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > > > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > > >> > > > >> > I would propose something as in attached patch to ensure that > > > >> > Location is focused when opening a new (empty) tab. > > > >> > > > >> +1 > > > > > > > > +1 > > > > > > I hope the patch will be part of dillo soon. The patch works very well. > > > > @Johannes, please comment what the change is for before committing. > > does anybody know, why > BW2UI(new_bw)->tabs()->selected_child()->take_focus(); > focusses the location text input? I wouldn't be surprised if fltk chooses it because it's the UI's first child.

Nov. 26, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Thu, Nov 26, 2009 at 11:53:12AM -0300, Jorge Arellano Cid wrote: > On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > >> > > >> > I would propose something as in attached patch to ensure that > > >> > Location is focused when opening a new (empty) tab. > > >> > > >> +1 > > > > > > +1 > > > > I hope the patch will be part of dillo soon. The patch works very well. > > @Johannes, please comment what the change is for before committing. does anybody know, why BW2UI(new_bw)->tabs()->selected_child()->take_focus(); focusses the location text input? Cheers, Johannes

Nov. 26, 2009

take_focus on a new tab

by jcid＠dillo.org

On Thu, Nov 26, 2009 at 11:01:02PM +0900, furaisanjin wrote: > 2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > >> > >> > I would propose something as in attached patch to ensure that > >> > Location is focused when opening a new (empty) tab. > >> > >> +1 > > > > +1 > > I hope the patch will be part of dillo soon. The patch works very well. @Johannes, please comment what the change is for before committing. -- Cheers Jorge.-

Nov. 26, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/11/26, Jorge Arellano Cid <jcid(a)dillo.org>: > On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: >> On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: >> >> > I would propose something as in attached patch to ensure that >> > Location is focused when opening a new (empty) tab. >> >> +1 > > +1 I hope the patch will be part of dillo soon. The patch works very well. Regards, furaisanjin

Nov. 26, 2009

take_focus on a new tab

by jcid＠dillo.org

On Thu, Nov 26, 2009 at 08:22:25AM +0000, Jeremy Henty wrote: > On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > > > I would propose something as in attached patch to ensure that > > Location is focused when opening a new (empty) tab. > > +1 +1 -- Cheers Jorge.-

Nov. 26, 2009

take_focus on a new tab

by onepoint＠starurchin.org

On Tue, Nov 24, 2009 at 11:03:23PM +0100, Johannes Hofmann wrote: > I would propose something as in attached patch to ensure that > Location is focused when opening a new (empty) tab. +1 Jeremy Henty

Nov. 26, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Sat, Nov 21, 2009 at 05:33:24PM +0900, furaisanjin wrote: > Hi all. > > I'm wondering if > "BW2UI(new_bw)->tabs()->selected_child()->take_focus()" is really > needed in a_UIcmd_open_url_nt. I usually hit space bar to scroll down > but I can't do this when I open a new tab by clicking middle mouse > button. The reason is that cursor stays on address bar so that I just > add space at the end of url if I hit space bar. Good point. I would propose something as in attached patch to ensure that Location is focused when opening a new (empty) tab. Cheers, Johannes

Nov. 24, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

Hi all. I'm wondering if "BW2UI(new_bw)->tabs()->selected_child()->take_focus()" is really needed in a_UIcmd_open_url_nt. I usually hit space bar to scroll down but I can't do this when I open a new tab by clicking middle mouse button. The reason is that cursor stays on address bar so that I just add space at the end of url if I hit space bar. Regards, furaisanjin

Nov. 21, 2009

[patch]: trim the labels of the stylesheet menu

by corvid＠lavabit.com

Jeremy wrote: > On Fri, Nov 20, 2009 at 09:28:25PM +0000, corvid wrote: > > Jeremy wrote: > > > > > It's interesting that FLTK decides to clip a little bit from the end > > there. I wonder what it was thinking... > > Me too, but I didn't feel like wading through FLTK code tonight! :-) Turns out that it doesn't do it to me when I run it. So let's blame the font... > > > 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. > > > > I don't know the details of when Jorge's code decides to free cache > > entries, but I think it would be best not to assume that the url > > remains valid. > > OK, I agree: robust code should ensure its own safety, not depend on > other code to look after it. Here's a patch to do that. It applies > on top of the previous patch. Committed.

Nov. 21, 2009

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

by furaisanjin＠gmail.com

2009/11/20 Jorge Arellano Cid <jcid(a)dillo.org>: > ?@all: please test the patch in the repo and report. Bookmark problem is fixed on FreeBSD. > ?The ?problem with HTTP proxy *may* be a different thing, but it > also may be fixed now. Please check and report. Still I need to modify for HTTP proxy, so the root cause is different. Regards, furaisanjin

Nov. 21, 2009

[patch]: trim the labels of the stylesheet menu

by onepoint＠starurchin.org

On Fri, Nov 20, 2009 at 09:28:25PM +0000, corvid wrote: > Jeremy wrote: > > > It's interesting that FLTK decides to clip a little bit from the end > there. I wonder what it was thinking... Me too, but I didn't feel like wading through FLTK code tonight! :-) > > 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. > > I don't know the details of when Jorge's code decides to free cache > entries, but I think it would be best not to assume that the url > remains valid. OK, I agree: robust code should ensure its own safety, not depend on other code to look after it. Here's a patch to do that. It applies on top of the previous patch. Jeremy

Nov. 20, 2009

[patch]: trim the labels of the stylesheet menu

by corvid＠lavabit.com

Jeremy wrote: > > 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/ Good. It would be nice to improve the labels. It's interesting that FLTK decides to clip a little bit from the end there. I wonder what it was thinking... > 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. I don't know the details of when Jorge's code decides to free cache entries, but I think it would be best not to assume that the url remains valid.

Nov. 20, 2009

[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

weird font

by corvid＠lavabit.com

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.

Nov. 15, 2009

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

by corvid＠lavabit.com

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

Nov. 15, 2009

Q: why do we defer loading linked stylesheets?

by onepoint＠starurchin.org

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? Regards, Jeremy Henty

Nov. 15, 2009

weird font

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes

Nov. 15, 2009

Q: why do we defer loading linked stylesheets?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Nov 14, 2009 at 10:16:07AM +0000, Jeremy Henty wrote: > > On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > > > Jeremy wrote: > > > > Why do we defer loading the CSS stylesheets named in <link> > > > > elements until the <head> 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. > > > > > > > > [...] > > > > > > It looks like it dates to > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html > > > > Yuk! So what should we do if the <head> includes a <style> element > > that @imports a style sheet? Defer loading that stylesheet until the > > end of the <head>? Maybe defer parsing the entire <style> element? > > Shouldn't we treat all the style information in the same way? It > > seems to me that currently we don't. (Mind you, I'm not familiar with > > these charset and reepush issues so I'm probably missing something.) > > I don't remember all the details, but the basic idea is to defer the > repush (not the loading), so we repush - and as a consequence > redraw - the page just once. > So in your example with an @import directive in the <style> element > body, we would parse it if it is readily available in the cache. But > if not, we continue rendering without it. Then, once <head> is > closed and all requested style sheets are in cache, we repush the > page and restart parsing from start. > There is still a chance that during that repush we find a new > style sheet to be loaded due to a @import in one of the style sheets > we had not examined yet. That seems to be an inherent problem of the > @import thing in general. Speaking of repush, I see that there's another bug about auth and segfaults in the bug tracker. (At least the Tim crash had to do with repush, as I recall.)

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by Johannes.Hofmann＠gmx.de

On Sat, Nov 14, 2009 at 10:16:07AM +0000, Jeremy Henty wrote: > On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > > Jeremy wrote: > > > Why do we defer loading the CSS stylesheets named in <link> > > > elements until the <head> 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. > > > > > > [...] > > > > It looks like it dates to > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html > > Yuk! So what should we do if the <head> includes a <style> element > that @imports a style sheet? Defer loading that stylesheet until the > end of the <head>? Maybe defer parsing the entire <style> element? > Shouldn't we treat all the style information in the same way? It > seems to me that currently we don't. (Mind you, I'm not familiar with > these charset and reepush issues so I'm probably missing something.) I don't remember all the details, but the basic idea is to defer the repush (not the loading), so we repush - and as a consequence redraw - the page just once. So in your example with an @import directive in the <style> element body, we would parse it if it is readily available in the cache. But if not, we continue rendering without it. Then, once <head> is closed and all requested style sheets are in cache, we repush the page and restart parsing from start. There is still a chance that during that repush we find a new style sheet to be loaded due to a @import in one of the style sheets we had not examined yet. That seems to be an inherent problem of the @import thing in general. Cheers, Johannes

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by onepoint＠starurchin.org

On Fri, Nov 13, 2009 at 08:05:05AM +0000, corvid wrote: > Jeremy wrote: > > Why do we defer loading the CSS stylesheets named in <link> > > elements until the <head> 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. > > > > [...] > > It looks like it dates to > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html Yuk! So what should we do if the <head> includes a <style> element that @imports a style sheet? Defer loading that stylesheet until the end of the <head>? Maybe defer parsing the entire <style> element? Shouldn't we treat all the style information in the same way? It seems to me that currently we don't. (Mind you, I'm not familiar with these charset and reepush issues so I'm probably missing something.) Regards, Jeremy Henty

Nov. 14, 2009

Q: why do we defer loading linked stylesheets?

by corvid＠lavabit.com

Jeremy wrote: > Why do we defer loading the CSS stylesheets named in <link> elements > until the <head> 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 <link>-ed stylesheets. At the moment this causes all sorts of > code branches (is the @import in a <link>-ed file or an embedded > <style>, if the latter, is it in the <head> or not). It would be much > simpler to just immediately load every style file at the same time as > it is added to html->ccsUrls , but that would change the behaviour to > load <link>-ed styles immediately instead of at the end of the <head> > element. Would that break anything? It looks like it dates to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/005870.html

Nov. 13, 2009

Q: why do we defer loading linked stylesheets?

by onepoint＠starurchin.org

Why do we defer loading the CSS stylesheets named in <link> elements until the <head> 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 <link>-ed stylesheets. At the moment this causes all sorts of code branches (is the @import in a <link>-ed file or an embedded <style>, if the latter, is it in the <head> or not). It would be much simpler to just immediately load every style file at the same time as it is added to html->ccsUrls , but that would change the behaviour to load <link>-ed styles immediately instead of at the end of the <head> element. Would that break anything? Regards, Jeremy Henty

Nov. 13, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Thu, Nov 12, 2009 at 09:01:03PM +0900, furaisanjin wrote: > This misleads, so I clarify. > > 2009/11/12 furaisanjin <furaisanjin(a)gmail.com>: > > > 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.-

Nov. 12, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

This misleads, so I clarify. 2009/11/12 furaisanjin <furaisanjin(a)gmail.com>: > 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

Nov. 12, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

2009/11/12 Jorge Arellano Cid <jcid(a)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)? 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

Nov. 12, 2009

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

by corvid＠lavabit.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.

Nov. 12, 2009

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

by jcid＠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.-

Nov. 12, 2009

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

by corvid＠lavabit.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.

Nov. 12, 2009

EAGAIN loop in IO_read

by jcid＠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.-

Nov. 12, 2009

EAGAIN loop in IO_read

by furaisanjin＠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

Nov. 11, 2009

weird font

by jcid＠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.-

Nov. 11, 2009