- Dillo-dev - lists.mailman3.com

ComplexButton crashing

by Johannes.Hofmann＠gmx.de

On Wed, Mar 26, 2008 at 04:42:16PM +0000, place wrote: > Johannes wrote: > > place wrote: > > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > > > When the button is destroyed, since the button is a Group, its children > > > get destroyed. > > > Later on, the layout is being destroyed, and it deletes TopLevel. > > > The toplevel widget destructor calls layout->removeWidget(), which tries > > > to iterate through the views. > > > > Ok I'm just trying to understand the ComplexButton button stuff > > - rather good class name btw :-) > > Why is there a view as child of the button? > > What is this view supposed to display? > > I have no idea whether it's necessary. Maybe the layout in the button > doesn't get shown otherwise? > > > Anyway, first I'd suggest: > > > > diff -r f1f343e2c024 dw/fltkui.cc > > --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 > > +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 > > @@ -423,13 +423,15 @@ > > if (!relief) > > button->box(::fltk::FLAT_BOX); > > > > - button->begin (); > > lastFlatView = > > new FltkFlatView (allocation->x + reliefXThickness (), > > allocation->y + reliefYThickness (), > > allocation->width - 2 * reliefXThickness (), > > allocation->ascent + allocation->descent > > - 2 * reliefYThickness ()); > > + > > + button->add (lastFlatView); > > + > > if (layout) > > layout->attachView (lastFlatView); > > return button; > > > > > > > > because this begin () / end () stuff is rather ugly, especially if > > the matching end () is missing. > > Yes! At first, without the end(), I assumed the begin() was extraneous. > > > Sounds reasonable, but I'd really like to understand that > > ComplexButton stuff first. Is there something in doc/ I did not see? > > How did you know it is supposed to be used for image inputs? > > In dw/ui.hh, it says > > * <tr><td>image <td>dw::core::ui::ComplexButtonResource > * <td>dw::core::ui::ResourceFactory::createComplexButtonResource, > * width a dw::Image inside and relief = false. > Ahh, now I understand. layout is a new layout specific to the button. It is created in ComplexButton::init (). So the purpose of ComplexButton is to create buttons that can have arbitrary HTML rendered on them. I wonder if we really need to duplicate the button code from fltk for this. For now I think your fix is good. Perhaps we can make the whole stuff simpler in the future. Did you already manage to add an dw::Image to a ComplexButton? Cheers, Johannes

March 26, 2008

patch: URL data as a Dstr

by place＠gobigwest.com

This is part one in a series for file inputs. Parts two and three are written. Parts four and five are contemplated. Maybe a part six if I feel like it. Part three is the one that makes it at least appear to work, though I'll need help in testing at that point. HTTPS note: If https does remain a dpi, somebody will have to decide what they want to do with Capi_dpi_build_cmd() if http_query can contain NULLs.

March 26, 2008

ComplexButton crashing

by place＠gobigwest.com

Johannes wrote: > place wrote: > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > > When the button is destroyed, since the button is a Group, its children > > get destroyed. > > Later on, the layout is being destroyed, and it deletes TopLevel. > > The toplevel widget destructor calls layout->removeWidget(), which tries > > to iterate through the views. > > Ok I'm just trying to understand the ComplexButton button stuff > - rather good class name btw :-) > Why is there a view as child of the button? > What is this view supposed to display? I have no idea whether it's necessary. Maybe the layout in the button doesn't get shown otherwise? > Anyway, first I'd suggest: > > diff -r f1f343e2c024 dw/fltkui.cc > --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 > +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 > @@ -423,13 +423,15 @@ > if (!relief) > button->box(::fltk::FLAT_BOX); > > - button->begin (); > lastFlatView = > new FltkFlatView (allocation->x + reliefXThickness (), > allocation->y + reliefYThickness (), > allocation->width - 2 * reliefXThickness (), > allocation->ascent + allocation->descent > - 2 * reliefYThickness ()); > + > + button->add (lastFlatView); > + > if (layout) > layout->attachView (lastFlatView); > return button; > > > > because this begin () / end () stuff is rather ugly, especially if > the matching end () is missing. Yes! At first, without the end(), I assumed the begin() was extraneous. > Sounds reasonable, but I'd really like to understand that > ComplexButton stuff first. Is there something in doc/ I did not see? > How did you know it is supposed to be used for image inputs? In dw/ui.hh, it says * <tr><td>image <td>dw::core::ui::ComplexButtonResource * <td>dw::core::ui::ResourceFactory::createComplexButtonResource, * width a dw::Image inside and relief = false. PS I subscribed to the list under a new address, but my first msg is still awaiting moderator approval, so the old address lives on a bit longer...

March 26, 2008

ComplexButton crashing

by Johannes.Hofmann＠gmx.de

On Thu, Mar 20, 2008 at 03:12:15PM +0000, place wrote: > For you dw people... > I am working on getting ComplexButton to work (image inputs), Great! > and it would segfault when I'd close the bw. > > In FltkComplexButtonResource::createNewWidget, the button's child is a view. > When the button is destroyed, since the button is a Group, its children > get destroyed. > Later on, the layout is being destroyed, and it deletes TopLevel. > The toplevel widget destructor calls layout->removeWidget(), which tries > to iterate through the views. Ok I'm just trying to understand the ComplexButton button stuff - rather good class name btw :-) Why is there a view as child of the button? What is this view supposed to display? Anyway, first I'd suggest: diff -r f1f343e2c024 dw/fltkui.cc --- a/dw/fltkui.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/fltkui.cc Wed Mar 26 16:57:13 2008 +0100 @@ -423,13 +423,15 @@ if (!relief) button->box(::fltk::FLAT_BOX); - button->begin (); lastFlatView = new FltkFlatView (allocation->x + reliefXThickness (), allocation->y + reliefYThickness (), allocation->width - 2 * reliefXThickness (), allocation->ascent + allocation->descent - 2 * reliefYThickness ()); + + button->add (lastFlatView); + if (layout) layout->attachView (lastFlatView); return button; because this begin () / end () stuff is rather ugly, especially if the matching end () is missing. > > To make the problem go away, I added: > fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} > but I don't know any of this code well enough to know what _should_ > be going on. Sounds reasonable, but I'd really like to understand that ComplexButton stuff first. Is there something in doc/ I did not see? How did you know it is supposed to be used for image inputs? Cheers, Johannes

March 26, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by jcid＠dillo.org

On Tue, Mar 25, 2008 at 07:10:57PM +0100, Johannes Hofmann wrote: > On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > > I think I mentioned this problem some time ago, but playing with > > ComplexButton makes it much worse (when meta charset causes a repush). > > > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > > to a removeRef, but, again, I don't know this code well enough to know what > > should be going on. > > > > #0 0x40344c81 in kill () from /lib/libc.so.6 > > #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 > > #2 0x401b087b in raise () from /lib/libpthread.so.0 > > #3 0x403448f8 in raise () from /lib/libc.so.6 > > #4 0x40345f00 in abort () from /lib/libc.so.6 > > #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 > > #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) > > at object.cc:49 > > #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, > > element=0x81ab118, compare=true, doNotDeleteAtAll=false) > > at container.cc:254 > > #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, > > element=0x81ab118) at ../lout/container.hh:169 > > #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo > > ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 > > #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) > > at fltkplatform.cc:319 > > #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117 > > > > > > As far as I can see it should be removeRef () here, as you > suggest. While looking at it, I found a buglet in layout.cc. Committed both. -- Cheers Jorge.-

March 26, 2008

Re: cache entry status

by jcid＠dillo.org

On Sun, Mar 23, 2008 at 05:29:00PM +0000, place wrote: > This is what I've ended up with. I suspect you'll regard it as overengineered... A bit too complex, yes. Although most of it stems from a not so clear design isolation between cache, dicache, capi and the rest. BTW, I suspect the dicache may have obsolete parts. > I couldn't bring myself to call it is_cached when it returned various flags, > so it's entry_status. > > I didn't know what to do about testing for Aborted. Aborted is not yet implemented. I committed a modified version (hopefully simpler). > English: I was looking at some docs the other day, and I started to notice > that you use "there're" sometimes... It's perfectly normal in speech, but it > looks odd when written. Committed. -- Cheers Jorge.-

March 26, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by Johannes.Hofmann＠gmx.de

On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > I think I mentioned this problem some time ago, but playing with > ComplexButton makes it much worse (when meta charset causes a repush). > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > to a removeRef, but, again, I don't know this code well enough to know what > should be going on. > > #0 0x40344c81 in kill () from /lib/libc.so.6 > #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 > #2 0x401b087b in raise () from /lib/libpthread.so.0 > #3 0x403448f8 in raise () from /lib/libc.so.6 > #4 0x40345f00 in abort () from /lib/libc.so.6 > #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 > #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) > at object.cc:49 > #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, > element=0x81ab118, compare=true, doNotDeleteAtAll=false) > at container.cc:254 > #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, > element=0x81ab118) at ../lout/container.hh:169 > #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo > ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 > #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) > at fltkplatform.cc:319 > #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117 > > As far as I can see it should be removeRef () here, as you suggest. While looking at it, I found a buglet in layout.cc. Cheers, Johannes diff -r f1f343e2c024 dw/fltkplatform.cc --- a/dw/fltkplatform.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/fltkplatform.cc Tue Mar 25 19:09:26 2008 +0100 @@ -316,7 +316,7 @@ void FltkPlatform::removeIdle (int idleI for(found = false, it = idleQueue->iterator(); !found && it.hasNext(); ) { idleFunc = it.getNext(); if(idleFunc->id == idleId) { - idleQueue->remove (idleFunc); + idleQueue->removeRef (idleFunc); found = true; } } diff -r f1f343e2c024 dw/layout.cc --- a/dw/layout.cc Tue Mar 18 18:05:51 2008 +0100 +++ b/dw/layout.cc Tue Mar 25 19:09:26 2008 +0100 @@ -473,7 +473,7 @@ void Layout::updateAnchor () if (anchor == NULL) { /** \todo Copy comment from old docs. */ - if (scrollIdleId && !scrollIdleNotInterrupted) { + if (scrollIdleId != -1 && !scrollIdleNotInterrupted) { platform->removeIdle (scrollIdleId); scrollIdleId = -1; }

March 25, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 07:48:00PM +0000, place wrote: > Jorge wrote: > > Does anybody else have some experience/theory/article/knowledge on API > > design that can enlighten us? > > > > ;) > > I just meant "okay, never mind". After some investigation I chose to honor "minimal" in this case and committed the equivalent using Dstr_append_l(). With regard to entry_status()/is_cached(), I'm trying to find a good trade off between "minimal set" and "obvious meaning from first code read". ;-) BTW, I found good summary advice on API design here: http://blog.isnotworking.com/2007/05/api-design-guidelines.html -- Cheers Jorge.-

March 24, 2008

https plugin status

by onepoint＠starurchin.org

On Thu, Mar 20, 2008 at 09:37:13AM -0400, Jorge Arellano Cid wrote: > On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > > > > OK, what about my patch to redirect MSG debugging messages from > > stdout to stderr? Is that correct? > > Dpi programs are reading and writing from the stdin descriptor, > and all of them send debug messages to stdout. I think this is > correct, or at least standard by now. OK, I see. I wasn't expecting anything to *write* to the stdin descriptor so I assumed something was wrong. Regards, Jeremy Henty

March 24, 2008

[PATCH]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:57:12PM +0000, Jeremy Henty (me) wrote: > On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > > > Any ideas how to fix this? I having a hard time getting my head > > around this bit of the code. > > Hmm, this little patch seems to do it. Ooops, no it doesn't - it crashes Dillo if you press the reload button or left-click an internal link on a page with a '<meta http-equiv="Content-Type"...' element. Strangely, middle-clicking to bring up a new browser is OK, which is why I missed this problem at first. So how *do* we fix this? Jeremy Henty > diff -pru -- 00_pre/src/nav.c 01_post/src/nav.c > --- 00_pre/src/nav.c 2008-03-16 15:29:31.000000000 +0000 > +++ 01_post/src/nav.c 2008-03-23 23:54:13.000000000 +0000 > @@ -334,8 +334,9 @@ static void Nav_repush(BrowserWindow *bw > ReqURL = a_Url_dup(a_History_get_url(NAV_TOP_UIDX(bw))); > /* Let's make reload be from Cache */ > a_Url_set_flags(ReqURL, URL_FLAGS(ReqURL) | URL_ReloadFromCache); > + bw->nav_expect_url = ReqURL; > + bw->nav_expecting = TRUE; > Nav_open_url(bw, ReqURL, 0); > - a_Url_free(ReqURL); > } > } >

March 24, 2008

[PATCH]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > Any ideas how to fix this? I having a hard time getting my head > around this bit of the code. Hmm, this little patch seems to do it. Comments? Jeremy Henty

March 24, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

On Sun, Mar 23, 2008 at 11:37:35PM +0000, Jeremy Henty (me) wrote: > I think the reason is that the meta element forces the page to be > reloaded by Nav_push() and this does not call a_Nav_expect_done(). > Unfortunately a_Nav_expect_done() is responsible for calling > a_UIcmd_set_scroll_by_fragment(), so any page pulled in by > Nav_push() does not scroll to the anchor. Oops, I meant Nav_repush() instead of Nav_push(). Jeremy Henty

March 24, 2008

[BUG]: anchors break when a page includes '<meta http-equiv="Content-Type" ...'

by onepoint＠starurchin.org

If you navigate to a page with a '<meta http-equiv="Content-Type" ...' in the head element then any anchor in the URL is ignored. (This breaks my local cinema's web page because it puts listings and film descriptions on the same page and links them with anchors.) I think the reason is that the meta element forces the page to be reloaded by Nav_push() and this does not call a_Nav_expect_done(). Unfortunately a_Nav_expect_done() is responsible for calling a_UIcmd_set_scroll_by_fragment(), so any page pulled in by Nav_push() does not scroll to the anchor. Any ideas how to fix this? I having a hard time getting my head around this bit of the code. Regards, Jeremy Henty

March 24, 2008

missing occasional messages on dillo-dev

by place＠gobigwest.com

Jeremy wrote: > On Fri, Mar 21, 2008 at 09:01:51AM +0100, Andreas Kemnade wrote: > > > I have seen theses bounces, too. I have checked the server logs of > > the mailinglist mailserver and it does not contain such bounces from > > the gobigwest.com-Mailserver. So I guess the list server tries to > > be smart if place is in cc: to avoid duplicate emails, but if that > > delivery fails.... > > OK, this one has no CC:. Let's see if place gets it. Got it! Thanks. Sorry to fill the list with my personal email woes, BTW.

March 21, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by jcid＠dillo.org

On Thu, Mar 20, 2008 at 07:44:52PM +0000, place wrote: > I think I mentioned this problem some time ago, but playing with > ComplexButton makes it much worse (when meta charset causes a repush). > > The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). > > To make the problem go away, I changed the remove in FltkPlatform::removeIdle() > to a removeRef, but, again, I don't know this code well enough to know what > should be going on. I don't know either. :( It needs some investigation. -- Cheers Jorge.-

March 21, 2008

missing occasional messages on dillo-dev

by onepoint＠starurchin.org

On Fri, Mar 21, 2008 at 09:01:51AM +0100, Andreas Kemnade wrote: > I have seen theses bounces, too. I have checked the server logs of > the mailinglist mailserver and it does not contain such bounces from > the gobigwest.com-Mailserver. So I guess the list server tries to > be smart if place is in cc: to avoid duplicate emails, but if that > delivery fails.... OK, this one has no CC:. Let's see if place gets it. Jeremy Henty

March 21, 2008

missing occasional messages on dillo-dev

by place＠gobigwest.com

Andreas wrote: > Jeremy Henty <onepoint(a)starurchin.org> wrote: > > > On Thu, Mar 20, 2008 at 08:34:42PM +0000, place wrote: > > > I've been missing the occasional message lately. > > > I do not have any spam filtering. > > > > You may not, but it looks as though something has on your behalf. A > > few days ago I replied to one of your posts and my mailer CC-ed you. > > The CC bounced with this message: > > > I have seen theses bounces, too. I have checked the server logs of the mailinglist > mailserver and it does not contain such bounces from the gobigwest.com-Mailserver. > So I guess the list server tries to be smart if place is in cc: to avoid duplicate > emails, but if that delivery fails.... I didn't get Jeremy's message above. Well, it seems I'll have to pick out an email service...

March 21, 2008

missing occasional messages on dillo-dev

by akemnade＠tzi.de

Hi, On Thu, 20 Mar 2008 22:44:29 +0000 Jeremy Henty <onepoint(a)starurchin.org> wrote: > On Thu, Mar 20, 2008 at 08:34:42PM +0000, place wrote: > > I've been missing the occasional message lately. > > I do not have any spam filtering. > > You may not, but it looks as though something has on your behalf. A > few days ago I replied to one of your posts and my mailer CC-ed you. > The CC bounced with this message: > I have seen theses bounces, too. I have checked the server logs of the mailinglist mailserver and it does not contain such bounces from the gobigwest.com-Mailserver. So I guess the list server tries to be smart if place is in cc: to avoid duplicate emails, but if that delivery fails.... Greetings Andreas Kemnade

March 21, 2008

missing occasional messages on dillo-dev

by onepoint＠starurchin.org

On Thu, Mar 20, 2008 at 08:34:42PM +0000, place wrote: > I've been missing the occasional message lately. > I do not have any spam filtering. You may not, but it looks as though something has on your behalf. A few days ago I replied to one of your posts and my mailer CC-ed you. The CC bounced with this message: This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: place(a)gobigwest.com SMTP error from remote mail server after RCPT TO:<place(a)gobigwest.com>: host gobigwest.com.s6a1.psmtp.com [64.18.5.10]: 571 spam source blocked [^^^^^^^^^^^^^^^^^^^^^^ hmmmm...! - jeremy] Perhaps gobigwest thinks some of us are spammers and are kindly blocking our mail for you? Could you explicitly acknowledge this so we can tell whether it got through to you? Regards, Jeremy Henty

March 20, 2008

missing occasional messages on dillo-dev

by place＠gobigwest.com

I've been missing the occasional message lately. I do not have any spam filtering. Does whoever admins the list have any insight?

March 20, 2008

removeIdle: *** [unknown] This should not happen! *** Aborted

by place＠gobigwest.com

I think I mentioned this problem some time ago, but playing with ComplexButton makes it much worse (when meta charset causes a repush). The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). To make the problem go away, I changed the remove in FltkPlatform::removeIdle() to a removeRef, but, again, I don't know this code well enough to know what should be going on. #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) at object.cc:49 #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, element=0x81ab118, compare=true, doNotDeleteAtAll=false) at container.cc:254 #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, element=0x81ab118) at ../lout/container.hh:169 #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) at fltkplatform.cc:319 #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117

March 20, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by place＠gobigwest.com

Jorge wrote: > I'd prefer to be sure that cached images always render in one pass, > but this workaround is simple and good enough to commit, until someone > comes with a better idea. Well, there was some discussion not too long ago on the list about a capi interface to get the status of cache entries... :)

March 20, 2008

ComplexButton crashing

by place＠gobigwest.com

For you dw people... I am working on getting ComplexButton to work (image inputs), and it would segfault when I'd close the bw. In FltkComplexButtonResource::createNewWidget, the button's child is a view. When the button is destroyed, since the button is a Group, its children get destroyed. Later on, the layout is being destroyed, and it deletes TopLevel. The toplevel widget destructor calls layout->removeWidget(), which tries to iterate through the views. To make the problem go away, I added: fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} but I don't know any of this code well enough to know what _should_ be going on.

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by darkspirit5000＠gmail.com

I do not have problem with that page, but ... I have suffer the same problem(i think) in dillo-gtk few times, but can not reproduce it. I am interested in resolve this bug, but do not have time. Now that the problem happen always maybe we can catch the bug. Try to gdb the dpid or cookies.dpi I think the problem is about the cookies.dpi: cookies.dpi can not start, it die before send an answer to dillo and the dpid restart it one and other time with same result. Dillo wait blocked forever the answer(because a_Dpi_send_blocking_cmd()). To recover the blocked dillo you can stop dpid and at the same time kill the various cookies.dpi running. Te reason to have or not to have this problem, can be to have enabled cookies for that site Diego. 2008/3/20, Jeremy Henty <onepoint(a)starurchin.org>: > > On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > > Jorge wrote: > > > I just noticed that calling current CVS with: > > > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > > > completely blocks the browser. > > > > > > It doesn't happen with older dillo2 versions. > > > > > > Please give it a look. > > > > No problems for me, either with or without cookies. > > > It consistently hangs the latest CVS for me. I have attached the gdb > backtrace. > > For a while not so long ago one of my ISP's pages also hung Dillo in > a_Dpi_send_blocking_cmd() . The problem went away before I got round > to investigating it properly. I don't know if it fixed itself due to > a change in the page, a change in Dillo or some other factor. I > mention it now to point out that this problem *may* have been around > for a little while in some form or other (though I can't be certain). > > Regards, > > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > >

March 20, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by jcid＠dillo.org

On Sun, Mar 16, 2008 at 04:41:08PM +0000, place wrote: > > Your patch below works great for me. > > :) > > Here's a proper patch with proper comments. > > PS If anybody happens to have deep knowledge of various sorts of > networking, maybe they'll know an optimal value for a BufSize test. > All I know is that modem mtu is 15xx. > Committed. I'd prefer to be sure that cached images always render in one pass, but this workaround is simple and good enough to commit, until someone comes with a better idea. -- Cheers Jorge.-

March 20, 2008

[patch] don't allocate tagnames on stack

by jcid＠dillo.org

On Sun, Mar 16, 2008 at 05:05:57PM +0100, Johannes Hofmann wrote: > On Sun, Mar 16, 2008 at 10:47:07AM -0400, Jorge Arellano Cid wrote: > > On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > here is another patch that avoids some malloc/free calls. > > > > > > > I decided to completely remove tag_name, and to use Tags[tag_idx]. > > Please check the patch in CVS. > > Cool. That's even better. > > > > > BTW, with regard to these optimizations (which I was very fond of), > > profiling showed me that the zen of speed is to attack the main bottleneck... > > Can you build a statically linked binary with > profiling enabled? Here it does not work for some reason, so the > timings in the gprof output are bogus. Only the counters work > reliably. I've done it lots of times in the past, with: ./configure --enable-gprof or CFLAGS="-g -O0" CXXFLAGS="-g -O0" ./configure --enable-gprof but now that I test, it doesn't work anymore! !? -- Cheers Jorge.-

March 20, 2008

https plugin status

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:21:23PM +0000, Jeremy Henty wrote: > On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > > > [Jeremey wrote] > > > Or maybe Capi_url_uses_dpi() should be checking for "https" and > > > *not* adding the "proto." prefix? > > > > "proto.https" is the right patch. > > OK, what about my patch to redirect MSG debugging messages from stdout > to stderr? Is that correct? Dpi programs are reading and writing from the stdin descriptor, and all of them send debug messages to stdout. I think this is correct, or at least standard by now. -- Cheers Jorge.-

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > Jorge wrote: > > I just noticed that calling current CVS with: > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > completely blocks the browser. > > > > It doesn't happen with older dillo2 versions. > > > > Please give it a look. > > No problems for me, either with or without cookies. Oh! I'm on dialup now and have: www.fltk.org ACCEPT_SESSION in cookiesrc. It blocks for me on every try... -- Cheers Jorge.-

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by onepoint＠starurchin.org

On Wed, Mar 19, 2008 at 07:55:35PM +0000, place wrote: > Jorge wrote: > > I just noticed that calling current CVS with: > > > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > > > completely blocks the browser. > > > > It doesn't happen with older dillo2 versions. > > > > Please give it a look. > > No problems for me, either with or without cookies. It consistently hangs the latest CVS for me. I have attached the gdb backtrace. For a while not so long ago one of my ISP's pages also hung Dillo in a_Dpi_send_blocking_cmd() . The problem went away before I got round to investigating it properly. I don't know if it fixed itself due to a change in the page, a change in Dillo or some other factor. I mention it now to point out that this problem *may* have been around for a little while in some form or other (though I can't be certain). Regards, Jeremy Henty

March 20, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by place＠gobigwest.com

Jorge wrote: > I just noticed that calling current CVS with: > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > completely blocks the browser. > > It doesn't happen with older dillo2 versions. > > Please give it a look. No problems for me, either with or without cookies.

March 19, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > > > Also, what would you think of me either > > > > > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) > > > > OK. > > attached. > > I renamed it a_Cookies_get_query() in an effort > to suggest that it now returned more than just > the cookies. > > > Everything looks fine when I watch the headers, > but I don't use dillo for anything that _relies_ > on cookies working properly. > > So...anyone who habitually uses cookies might want > to give this a bit of a test. I just noticed that calling current CVS with: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 completely blocks the browser. It doesn't happen with older dillo2 versions. Please give it a look. -- Cheers Jorge.-

March 19, 2008

[jcid@dillo.org: Re: [Dillo-dev] Re: patch: concatenate Dstrs]

by jcid＠dillo.org

-- Cheers Jorge.-

March 19, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 07:48:00PM +0000, place wrote: > Jorge wrote: > > Does anybody else have some experience/theory/article/knowledge on API > > design that can enlighten us? > > > > ;) > > I just meant "okay, never mind". Understood. My point is there're other places in dillo where a more formal API definition is needed, and I'd like to know whether there's some theory or guiding experience that could help. -- Cheers Jorge.-

March 19, 2008

Re: patch: concatenate Dstrs

by place＠gobigwest.com

Jorge wrote: > Does anybody else have some experience/theory/article/knowledge on API > design that can enlighten us? > > ;) I just meant "okay, never mind".

March 18, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 02:14:06PM +0000, place wrote: > > On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > > I made a dStr_dstrcat(). > > > > > > > What's the main advantage of it, over dStr_append_l() ? > > > > I see the convenience and clarity of passing two parameters instead > > of three, but on the other hand, keeping APIs reduced to a functional > > minimum, helps to remember and to choose the right function call. > > > > There may be a point I don't yet see... > > Nope, that's all there was to it. > And I don't have a strong opinion about it, so that's fine. Does anybody else have some experience/theory/article/knowledge on API design that can enlighten us? ;) -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 07:58:34PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Mar 14, 2008 at 06:53:08PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is another patch to reduce the redraws caused by resizing > > > tables. A new method Layout::queueDrawExcept(), that requests the > > > drawing of a rectangle except another rectangle is added. > > > It is then used in widget.cc to redraw the area that was previously > > > occupied by a widget, but is no longer occupied after a resize or move. > > > This makes it possible to redraw less when a table resizes. > > > All in all it should reduce the flicker a bit when loading table > > > based pages. > > > > On the topic of reducing the flicker, I'm far of an expert and > > please correct me if I'm wrong. AFAIU, the current design draws > > the background color before the widget content. > > > > This is: if you have an html page as big table, in dillo, it > > will become a table inside a textblock. When the textblock is > > asked to redraw, it will _erase_ the table with its background > > color and ask its child (the table) to redraw. Causing flicker. > > Yes, that's true. > In addition, before anything is drawn, the rectangle to be drawn is > already cleared with the background color in FltkViewBase::draw() > (the fillrect () calls). Oh, I haven't noticed those calls. > > > > If this is true, a big gain could come from a different > > approach: just draw the surroundings of the widgets and ask the > > child widgets to redraw. > > > > This way widgets aren't erased beforehand, and can also decide > > not to redraw themselves when nothing has changed. > > > > I have worked a bit on this idea, and the attached patch mocks > > the idea hackishly. It draws the "padding" area of the CSS box > > (see the picture in namespacedw_1_1core_1_1style.html in dw docs) > > > > Please give it a review and share your comments, > > corrections and thoughts. > > I've been thinking about something similar as well, but I don't > think it will work out generally. > The main problem is text drawing and maybe transparent widgets > (don't know whether they exist already). Probably drawing text over a background image qualifies as "transparent text widget". > Anyway, for drawing text, you need to erase the area first. > Just comment out the fillrect () calls in FltkViewBase::draw() to > see what I mean :-) Yes, I did. Quite clear example. > Therefore, we will always have flicker, when drawing text. > > The good news is that all the flicker can be avoided easily with > some double buffering technique. And from dillo1 we even know that > this is not necessarily slow :-) > > So for me the flicker itself is not that much of a problem. > It may be an indicator for unnecessary redraws, which should be > avoided to save CPU power. But I think current cvs is already > pretty good in this regard. That makes me happy, because since the queueDrawExcept() patch, flickering has reduced even more. I'm yet to test on a slow system though. > > So I would propose to start to think about efficient double > buffering similar to what I had posted in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-November/003379.html > but platform independent using fltk2 support. Sure, and we still have the reosurce of tunning the refresh rate as in formerly proposed patches. I agree with your proposal. And if someday (soon I hope) we start working together with the FLTK guys, they will have lots of advice on how to tune things up. -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > Hi, > > below is another patch to reduce the redraws caused by resizing > tables. A new method Layout::queueDrawExcept(), that requests the > drawing of a rectangle except another rectangle is added. > It is then used in widget.cc to redraw the area that was previously > occupied by a widget, but is no longer occupied after a resize or move. > This makes it possible to redraw less when a table resizes. > All in all it should reduce the flicker a bit when loading table > based pages. Committed! -- Cheers Jorge.-

March 18, 2008

saving files under recent fltk snapshots?

by Johannes.Hofmann＠gmx.de

On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? There seems to be a bug report regarding this already: http://fltk.org/newsgroups.php?s5234+gfltk.bugs+v5241+T0 Cheers, Johannes

March 18, 2008

Re: patch: concatenate Dstrs

by place＠gobigwest.com

> On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > I made a dStr_dstrcat(). > > > > What's the main advantage of it, over dStr_append_l() ? > > I see the convenience and clarity of passing two parameters instead > of three, but on the other hand, keeping APIs reduced to a functional > minimum, helps to remember and to choose the right function call. > > There may be a point I don't yet see... Nope, that's all there was to it. And I don't have a strong opinion about it, so that's fine.

March 18, 2008

saving files under recent fltk snapshots?

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? The same happened to me! Now I'm using fltk-2.0.x-r5990 plus this patch: ------------------------------------------------------------------------------ diff -pru fltk-2.0.x-r5990/src/message.cxx fltk-2.0.x-r6059/src/message.cxx --- fltk-2.0.x-r5990/src/message.cxx 2007-11-28 16:42:30.000000000 -0300 +++ fltk-2.0.x-r6059/src/message.cxx 2008-02-22 20:00:05.000000000 -0300 @@ -1,5 +1,5 @@ // -// "$Id: message.cxx 5990 2007-11-28 19:42:30Z dejan $" +// "$Id: message.cxx 6041 2008-02-22 23:00:05Z fabien $" // // Copyright 1998-2006 by Bill Spitzak and others. // @@ -429,7 +429,7 @@ static const char* input_innards(const c const char* defstr, uchar type) { int r = innards("?", defstr ? defstr : "", type, fmt, ap, fltk::cancel, fltk::ok, 0); - return r>=0 ? textfield->text() : 0; + return r>0 ? textfield->text() : 0; } /*! ------------------------------------------------------------------------------ -- Cheers Jorge.-

March 18, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

Hi, On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > I made a dStr_dstrcat(). > What's the main advantage of it, over dStr_append_l() ? I see the convenience and clarity of passing two parameters instead of three, but on the other hand, keeping APIs reduced to a functional minimum, helps to remember and to choose the right function call. There may be a point I don't yet see... -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Mon, Mar 17, 2008 at 09:09:04PM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is a small optinization to Html_parse_entities (). > > > > Committed. > > Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. > See my patch below: > > Kind Regards, Ooops, committed. -- Cheers Jorge.-

March 18, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by Christian.Kellermann＠nefkom.net

* Jorge Arellano Cid <jcid(a)dillo.org> [080317 19:40]: > On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > > Hi, > > > > below is a small optinization to Html_parse_entities (). > > Committed. Unfortunately this misses the newly introduced inbuf_t for iconv compatibility. See my patch below: Kind Regards, Christian Index: src/html.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/html.cc,v retrieving revision 1.53 diff -b -u -r1.53 html.cc --- src/html.cc 17 Mar 2008 19:04:11 -0000 1.53 +++ src/html.cc 17 Mar 2008 20:19:21 -0000 @@ -3844,7 +3844,8 @@ int rc = 0; Dstr *output; const int bufsize = 128; - char *buffer, *inPtr, *outPtr; + inbuf_t *inPtr; + char *buffer, *outPtr; size_t inLeft, outRoom; bool bad_chars = false; -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

March 17, 2008

patch: multipart/form-data CRLF

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:29:32PM +0000, place wrote: > Happened to notice in the RFC that multipart types must use CRLF between > body parts. Committed. > PS It was a bit annoying to figure out that http.c needed to be changed, > which suggests that it would have been better for me to store the boundary > string in DilloUrl somewhere after all. It happens. A long time ago I dedicated a long time to generate a minimal perfect hash function for finding HTML tags. It turned out that asimple binary search was simpler and with the same performance... -- Cheers Jorge.-

March 17, 2008

saving files under recent fltk snapshots?

by place＠gobigwest.com

I moved to snapshot 6066 (I'd been on 5990) the other day, and now I notice that dillo is unresponsive after I save a file. Seen in the 6059 announcement (http://fltk.org/articles.php?L791) "+ Changed the modal event loop of file_chooser() and dir_chooser() to use a new exec() method that delegates to Window::exec() internally. This exec() method should handle unpleasant side effects with other modal windows when closing the file_chooser dialog window. + Updated FileChooser.fl to reflect modifications made in the cxx/h files. Please do not edit these files directly (except the include header) Thanks." If anybody's tried a recent snapshot: Does it work for you?

March 17, 2008

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > Hi, > > below is a small optinization to Html_parse_entities (). Committed. -- Cheers Jorge.-

March 17, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. Garret wrote a good part of the certificate handling, you will find that code inside the plugin. > The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. Yes. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again. > > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar. > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. > > But on the other hand couldn't this be done by dpid for all filter > plugins? For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that. > Dpid can keep them alive as long as the following requests > belong to the same URL, then closing the connection after a timeout? > > I am sorry if this has been already decided on before. These thoughts > were rumaging aroung my head all day now... I hope these lines help. -- Cheers Jorge.-

March 17, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > [Jeremey wrote] > > Getting https working would greatly reduce the number of times I > > run Firefox! > > I thought many https sites needed javascript to work. _Please_ > correct me if I'm wrong. :-) Well, I can surf my ISPs forums with dillo-fltk now that https is working. That's something! Regards, Jeremy Henty

March 17, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by place＠gobigwest.com

> Your patch below works great for me. :) Here's a proper patch with proper comments. PS If anybody happens to have deep knowledge of various sorts of networking, maybe they'll know an optimal value for a BufSize test. All I know is that modem mtu is 15xx.

March 16, 2008

[patch] don't allocate tagnames on stack

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 10:47:07AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > > Hi, > > > > here is another patch that avoids some malloc/free calls. > > > > I decided to completely remove tag_name, and to use Tags[tag_idx]. > Please check the patch in CVS. Cool. That's even better. > > BTW, with regard to these optimizations (which I was very fond of), > profiling showed me that the zen of speed is to attack the main bottleneck... Can you build a statically linked binary with profiling enabled? Here it does not work for some reason, so the timings in the gprof output are bogus. Only the counters work reliably. Cheers, Johannes

March 16, 2008