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

forms related segfault

by jcid＠dillo.org

On Fri, Nov 09, 2007 at 01:15:19PM +0000, place wrote: > > > [Jorge wrote] > > > BTW, I asked on the linkblock/callback patch, because if I look at it, > > > you can devote your time to gzip decoding. > > > > > [place wrote] > > > All right. > > > > :-) > > > > So maybe this means he's expecting me to do it. > > > > Place, would you mind confirm? > > Yes, I thought you were doing it... > > What I had meant about page url and base_url was that I'd started, screwed > it up badly, and happily scrapped it when I saw your message. Good. I'll make it ASAP then and let Johannes know so we can solve the forms problem too. -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by place＠gobigwest.com

> > [Jorge wrote] > > BTW, I asked on the linkblock/callback patch, because if I look at it, > > you can devote your time to gzip decoding. > > > [place wrote] > > All right. > > :-) > > So maybe this means he's expecting me to do it. > > Place, would you mind confirm? Yes, I thought you were doing it... What I had meant about page url and base_url was that I'd started, screwed it up badly, and happily scrapped it when I saw your message.

Nov. 9, 2007

forms related segfault

by jcid＠dillo.org

Hi, On Fri, Nov 09, 2007 at 09:09:26AM -0300, Jorge Arellano Cid wrote: > Hi, > > On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote: > > Hello, > > > > when I go to e.g. www.google.com enter a search, click submit and then > > when the result page shows up hit Enter, I always get a segfault: > > Yes, it happens here too. > > > I think it has to do with the input form of the previous page > > somehow still being activ. > > Me too. > > As a side effect of flickering, I noticed several times how some > non existent inputs (text entries and buttons) were phantom-rendered > during updates (i.e. appeared on screen for a few jiffies). > > I'm investigating. More later. For instance, enable flickering (disable double-buffer and internal buffer), then go to: 1. www.google.com //and then to 2. chlamydia.fs.ei.tum.de/pub/DragonFly/packages/stable/DragonFly-1.10/All/ While loading the second URL you'll see the phantom-rendering of the text input and the two buttons that google uses. Now, I thought this was to be deleted from the call in web.cc (as a children of the top widget or something), but there's another way to do it that looks like the original idea. In html parsing we have a structure called the linkblock. This contains all the data that is needed after the page is parsed and rendered (mainly forms data), and also dw widgets! In html.hh you'll find DilloHtmlLB. Within DilloHtmlLB there's a vector of DilloHtmlForm, which has a vector of DilloHtmlInput which holds widgets. The linkblock is designed to be freed when the displayed dw is deleted, but this hook is not currently operative! (this is the warning you get at html.cc compile time about Html_lb_free not being called). A few days ago we were working on another issue with "place", and I made the necessary bindings for freeing the analog of DilloHtmlLB when parsing plain text. This is why when you leave a plain text page in dillo to render another one (anything) you'll see a message like this: a_Plain_free! 0x8177860 Now, making the binding for html.cc is not hard but takes some time and "place" is about to send it to me soon. But, maybe I understood it wrong: > [Jorge wrote] > BTW, I asked on the linkblock/callback patch, because if I look at it, > you can devote your time to gzip decoding. > [place wrote] > All right. :-) So maybe this means he's expecting me to do it. Place, would you mind confirm? Anyway, when the linkblock-free callback is hooked, those widgets can be destroyed from Html_lb_free(). Which is mainly implemented but not yet tested. Hope this helps. -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by jcid＠dillo.org

Hi, On Thu, Nov 08, 2007 at 06:49:36PM +0100, Johannes Hofmann wrote: > Hello, > > when I go to e.g. www.google.com enter a search, click submit and then > when the result page shows up hit Enter, I always get a segfault: Yes, it happens here too. > > Program received signal SIGSEGV, Segmentation fault. > loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, > argv=0xbfbff2dc) at container.hh:93 > 93 inline Iterator iterator() { Iterator > it(createIterator()); return it; } > (gdb) bt > #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, > argc=2, > argv=0xbfbff2dc) at container.hh:93 > #1 0x08084367 in > dw::core::ui::Resource::ActivateEmitter::emitActivate ( > this=0x28661208, resource=0x28661200) at ui.cc:109 > #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at > Widget.h:125 > #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at > Input.cxx:1267 > #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, > r=@0xbfbff414) > [...] > I think it has to do with the input form of the previous page > somehow still being activ. Me too. As a side effect of flickering, I noticed several times how some non existent inputs (text entries and buttons) were phantom-rendered during updates (i.e. appeared on screen for a few jiffies). I'm investigating. More later. > Jorge, do you know what happens to the fltk widgets like buttons or > inputs, when a new page gets loaded? They should be deleted, but my guess is that they don't. > Are the deleted, and if so > where in the code does this happen? I should hapen from: a_Web_dispatch_by_type /* This method frees the old dw if any */ layout->setWidget(dw); -- Cheers Jorge.-

Nov. 9, 2007

forms related segfault

by place＠gobigwest.com

Johannes wrote: > when I go to e.g. www.google.com enter a search, click submit and then > when the result page shows up hit Enter, I always get a segfault: It might not be the same problem, and I don't know whether it's a reasonable fix, but I used to have a lot of trouble with forms crashing until I did the following: diff -pur dw2/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2/dw/fltkui.cc 2007-10-06 22:03:01.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-11-04 01:46:01.000000000 +0000 @@ -40,6 +40,7 @@ #include <fltk/Symbol.h> #include <fltk/Item.h> #include <fltk/ItemGroup.h> +#include <fltk/events.h> namespace dw { namespace fltk { @@ -467,7 +468,8 @@ void FltkEntryResource::widgetCallback ( void *data) { printf ("when = %d\n", widget->when ()); - if (widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) + if ((widget->when () & ::fltk::WHEN_ENTER_KEY_ALWAYS) && + (::fltk::event_key() == ::fltk::ReturnKey)) ((FltkEntryResource*)data)->emitActivate (); }

Nov. 8, 2007

fltk dead key problem

by matthias.franz＠ujf-grenoble.fr

On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > - A problem which is already present in the fltk2 program test/input: > Pressing a dead key and then a letter (e.g., "^" and "o") works fine. > Pressing a dead key followed by space only sometimes gives the accent > (as it should) and sometimes just a space. What you get seems to be > random; it changes even while the program is running. The following patch fixes this. (It's not against the latest version of fltk, but the relevant file hasn't changed since.) ### start patch ### --- fltk-2.0.x-r5917/src/compose.cxx 2006-06-25 08:11:31.000000000 +0200 +++ fltk-new/src/compose.cxx 2007-11-08 07:38:01.000000000 +0100 @@ -345,19 +345,8 @@ bool fltk::compose(int& del) { for (const char *p = compose_pairs; *p; p += 2) if (p[0] == ascii || p[1] == ascii) { compose_state = ascii; - // prefer the single-character versions: - if (p[1] == ' ') { - int code = (p-compose_pairs)/2+0xA0; - // convert code to utf8: - e_text = textbuffer; - textbuffer[0] = 0xc0 | code>>6; - textbuffer[1] = 0x80 | (code & 0x3f); - textbuffer[2] = 0; - plen = e_length = 2; - return true; - } + return true; } - if (compose_state != 1) return true; #if 0 // The right-hand ctrl and any letter "quotes" the control character: @@ -386,6 +375,24 @@ bool fltk::compose(int& del) { } } + // prefer the single-character versions: + if (ascii == ' ') { + e_text = textbuffer; + if (c1 & 0x80) { + // convert c1 to utf8: + textbuffer[0] = 0xc0 | c1>>6; + textbuffer[1] = 0x80 | (c1 & 0x3f); + textbuffer[2] = 0; + plen = e_length = 2; + } else { + textbuffer[0] = c1; + textbuffer[1] = 0; + plen = e_length = 1; + } + compose_state = 0; + return true; + } + } #if USE_X11 ### end patch ### > I understand that fltk2 processes dead keys on its own. For us, it > would probably be easier if the keyboard was used in a "cooked" mode > based on the X keyboard settings. I'm getting more and more convinced of this opinion. Why does one specify key mapping in XKB files if each application processes them on its own? BTW, I've noticed another bug in fltk compose key processing: I use the Windoze menu key for composing. Although it has the right keysym (0xff20), it is ignored, probably because it is also considered to be a META key, and these keys are handled by fltk in a special way. I'll send an email to fltk-bugs as well. Cheers, -- Matthias Franz

Nov. 8, 2007

forms related segfault

by Johannes.Hofmann＠gmx.de

Hello, when I go to e.g. www.google.com enter a search, click submit and then when the result page shows up hit Enter, I always get a segfault: Program received signal SIGSEGV, Segmentation fault. loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 93 inline Iterator iterator() { Iterator it(createIterator()); return it; } (gdb) bt #0 loutsignal::Emitter::emitVoid (this=0x28661208, signalNo=0, argc=2, argv=0xbfbff2dc) at container.hh:93 #1 0x08084367 in dw::core::ui::Resource::ActivateEmitter::emitActivate ( this=0x28661208, resource=0x28661200) at ui.cc:109 #2 0x080909d3 in fltk::Widget::do_callback (this=0x28661280) at Widget.h:125 #3 0x080ab6d1 in fltk::Input::handle_key (this=0x28661280) at Input.cxx:1267 #4 0x080abe42 in fltk::Input::handle (this=0x28661280, event=8, r=@0xbfbff414) at Input.cxx:1469 #5 0x080ac66b in fltk::Input::handle (this=0x28661280, event=8) at Input.cxx:1384 #6 0x080dfac2 in fltk::Widget::send (this=0x28661280, event=8) at Widget.cxx:805 #7 0x080be6dd in fltk::handle (event=8, window=0x28540000) at run.cxx:1287 #8 0x080c4bf4 in fltk::handle () at run.cxx:1947 #9 0x080c4c38 in do_queued_events () at run.cxx:396 #10 0x080c4f52 in fl_wait (time_to_wait=1.00000002e+20) at run.cxx:456 #11 0x080c4fed in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:457 #12 0x080c5104 in fltk::run () at run.cxx:393 #13 0x0804e714 in main (argc=Error accessing memory address 0x0: Bad address. ) at dillo.cc:107 I think it has to do with the input form of the previous page somehow still being activ. Jorge, do you know what happens to the fltk widgets like buttons or inputs, when a new page gets loaded? Are the deleted, and if so where in the code does this happen? Cheers, Johannes

Nov. 8, 2007

PATCH: adds the ' entity

by jcid＠dillo.org

On Wed, Nov 07, 2007 at 06:36:58PM +0000, Jeremy Henty wrote: > On Wed, Nov 07, 2007 at 02:58:32PM -0300, Jorge Arellano Cid wrote: > > On Sun, Nov 04, 2007 at 09:07:20AM +0000, Jeremy Henty wrote: > > > > > > Is it dillo's policy to include *only* HTML 4.01 entities. > > > > Yes, our current policy is only HTML 4.01 entities. > > The spirit of the idea is similar to: > > > > http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos > > Thanks for the link. I see that ' *is* valid XML. Is that > relevant to dillo? Yes, but in the future. To parse xhtml, we have to validate the page, and that is currently not implemented in the parser. > > Of course sometimes standards are so badly violated that we can't > > but end supporting bad HTML (but raising a warning). > > Yes, I'm very aware that parsing real-life HTML is a thankless task. :-P -- Cheers Jorge.-

Nov. 7, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

Hi Jorge, I fully agree with your comments on my buffering patch. We should focus on the real solution, which is to fix the fltk library and then use their code for offscreen drawing. Whoever needs it can apply the patch manually. Regarding the frequent redraws I made the following observations: * Redraw requests are accumulated by fltk and then result in a single redraw when fltk thinks it should actually do the drawing. * Current code issues a full redraw request even if only part of the screen needs redrawing. This is a commented deficiancy and can be fixed quite easily. However there are so many full redraw requests, that one will hardly see any difference by that change. * Most full redraw requests come from Layout::queueResize() which in turn causes Layout::resizeIdle() to be called when fltk is idle for a moment. Every change of the size of a widget may change the whole layout on the screen and therefore require a complete redraw. If I understand the code correctly this is the similar in dillo1. So what can we do? For the second point I can provide a patch that accumulates screen regions that need redrawing until fltk actually redraws. The last point is more difficult to improve. For example think of a long page containing just text. Every time a new chunk comes in over the net, dillo creates a redraw request for the whole screen, even though there is already enough text to fill the screen so that the new data does not actually change the layout of the part that is currently visible. But how can we know, whether new data changes the layout of the currently visible part or not? The only rather simple improvement I can think of is that we could use the image sizes provided in the <img/> tags and only issue a Layout::queueResize() if the image proves to be of a different size. Currently there is a Layout::queueResize() for every image as it gets loaded. Regards, Johannes

Nov. 7, 2007

PATCH: adds the ' entity

by onepoint＠starurchin.org

On Wed, Nov 07, 2007 at 02:58:32PM -0300, Jorge Arellano Cid wrote: > On Sun, Nov 04, 2007 at 09:07:20AM +0000, Jeremy Henty wrote: > > > > Is it dillo's policy to include *only* HTML 4.01 entities. > > Yes, our current policy is only HTML 4.01 entities. > The spirit of the idea is similar to: > > http://fishbowl.pastiche.org/2003/07/01/the_curse_of_apos Thanks for the link. I see that ' *is* valid XML. Is that relevant to dillo? > Of course sometimes standards are so badly violated that we can't > but end supporting bad HTML (but raising a warning). Yes, I'm very aware that parsing real-life HTML is a thankless task. Regards, Jeremy Henty

Nov. 7, 2007