- Dillo-dev - lists.mailman3.com

crash with reload and textarea

by Johannes.Hofmann＠gmx.de

Hi, when using MALLOC_OPTIONS=GJPRZ on DragonFly which enables malloc debugging I get a crash when hitting Ctrl+r to reload a page with entered text in a textarea if the focus is still in the textarea. It seems that the Ctrl+r causes a callback on the already deleted fltk Input widget: Program received signal SIGBUS, Bus error. 0x0805310d in fltk::Widget::do_callback (this=0x284f5600) at /home/hofmann/soft//include/fltk/Widget.h:127 127 voiddo_callback()when{ callback_(this,user_data_); } (gdb) bt #0 0x0805310d in fltk::Widget::do_callback (this=0x284f5600) at /home/hofmann/soft//include/fltk/Widget.h:127 #1 0x080b75e3 in changed_stuff (i=0x28471480) at Input.cxx:49 #2 0x080b85dc in fltk::Input::replace (this=0x28471480, b=0, e=0, text=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond", ilen=66) at Input.cxx:826 #3 0x080bc4d8 in fltk::Input::insert (this=0x28471480, t=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond", l=66) at ../fltk/Input.h:86 #4 0x080b78f1 in fltk::Input::insert (this=0x28471480, text=0x2856d280 "http://www.shiningsilence.com/dbsdlog/2008/10/01/3185.html#respond") at Input.cxx:852 #5 0x08057aee in a_Web_dispatch_by_type (Type=0x2856f260 "text/html; charset=UTF-8", Web=0x2855a980, Call=0x2855a9d0, Data=0x2855a9d4) at web.cc:95 #6 0x08059b25 in Cache_process_queue (entry=0x285010c0) at cache.c:1050 On Linux export MALLOC_CHECK_=2 or valgrind should show similar results. Cheers, Johannes

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 04:50:55PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 07:21:35PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > > > > > If I stick > > > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Cheers > > > > > > > > > Jorge.- > > > > > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > > > */ > > > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > > > { > > > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > > > + > > > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > > > if (images->get(i)->image) { > > > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > > > (i.e. without the above patch). > > > > > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > > > are related to xpmImage from fltk. > > > > > > > Could someone with a linux machine please check current dillo with > > > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > > > I don't understand all that completely, but other crashes might be > > > > > > > related to this. > > > > > > > > > > > > OK, I'll check with valgrind... > > > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > > > > > But it really only happens when fltk was compiled with > > > > > --disable-xft > > > > > > > > I did that and FLTK's tests don't use xft, but my > > > > dillo-fltk still uses them! > > > > > > > > > > Did you call ./configure for dillo again? > > > > Yes. I forgot to make install FLTK, now it works. :) > > > > > > > > > > > > > > > > > BTW, does a: > > > > > > > > - new_w = strlen(str)*8 + 20; > > > > + new_w = strlen(str)*8 + 40; > > > > > > > > in ui.cc solve the problem for you? > > > > > > No, it doesn't. I think it's a fltk problem. > > > > Yes, valgrind reports an invalid write of size 1. > > See the attached file. > > > > It looks like unless FLTK2 is patched, we'll have a w=15 minibug > > as workaround. > > > > -- > > Cheers > > Jorge.- > > > ==17533== Invalid write of size 1 > > ==17533== at 0x4893E4: argb32_converter(unsigned char const*, unsigned char*, int) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4BA415: fltk::xpmImage::fetch(fltk::Image&, char const* const*) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4BA45C: fltk::xpmImage::fetch() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x488AFB: fltk::Image::fetch_if_needed() const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x488B76: fltk::Image::_measure(int&, int&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x4B85D9: fltk::Widget::draw_label(fltk::Rectangle const&, int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x47AA90: fltk::Button::draw(int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > > > > Thanks. I think I've found the problem. It's now in the fltk > bugtracker: http://fltk.org/str.php?L2054 > Let's hope the fix get's commited soon. Excellent! Maybe you can write a note to fltk-dev so Bill S. notices quickly. -- Cheers Jorge.-

Oct. 2, 2008

Shift + {Left, Right}

by jcid＠dillo.org

Hi there, Just committed a patch for making: SHIFT + {Left, Right} work even with the findbar focused. It took a long time to get it to work, but it improves Tab navigation a lot! Note: in uicmd.cc, + focus(child(i)); selected_child(child(i)); makes SHIFT+Right keep focus. SHIFT+Left doesn't work. I don't know why... -- Cheers Jorge.-

Oct. 2, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 07:21:35PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > > Hi, > > > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > > > If I stick > > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > > > -- > > > > > > > > Cheers > > > > > > > > Jorge.- > > > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > > */ > > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > > { > > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > > + > > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > > if (images->get(i)->image) { > > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > > (i.e. without the above patch). > > > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > > are related to xpmImage from fltk. > > > > > > Could someone with a linux machine please check current dillo with > > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > > I don't understand all that completely, but other crashes might be > > > > > > related to this. > > > > > > > > > > OK, I'll check with valgrind... > > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > > > But it really only happens when fltk was compiled with > > > > --disable-xft > > > > > > I did that and FLTK's tests don't use xft, but my > > > dillo-fltk still uses them! > > > > > > > Did you call ./configure for dillo again? > > Yes. I forgot to make install FLTK, now it works. :) > > > > > > > > > > > > BTW, does a: > > > > > > - new_w = strlen(str)*8 + 20; > > > + new_w = strlen(str)*8 + 40; > > > > > > in ui.cc solve the problem for you? > > > > No, it doesn't. I think it's a fltk problem. > > Yes, valgrind reports an invalid write of size 1. > See the attached file. > > It looks like unless FLTK2 is patched, we'll have a w=15 minibug > as workaround. > > -- > Cheers > Jorge.- > ==17533== Invalid write of size 1 > ==17533== at 0x4893E4: argb32_converter(unsigned char const*, unsigned char*, int) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4BA415: fltk::xpmImage::fetch(fltk::Image&, char const* const*) (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4BA45C: fltk::xpmImage::fetch() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x488AFB: fltk::Image::fetch_if_needed() const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x488B76: fltk::Image::_measure(int&, int&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x4B85D9: fltk::Widget::draw_label(fltk::Rectangle const&, int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x47AA90: fltk::Button::draw(int) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48645A: fltk::Group::draw() (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > ==17533== by 0x48597F: fltk::Group::draw_child(fltk::Widget&) const (in /home/jcid/C/Dillo/d2/dillo2-cur/src/dillo-fltk) > Thanks. I think I've found the problem. It's now in the fltk bugtracker: http://fltk.org/str.php?L2054 Let's hope the fix get's commited soon. Cheers, Johannes

Oct. 2, 2008

Basic authentication

by jcid＠dillo.org

Hi Christian, On Thu, Oct 02, 2008 at 09:15:58AM +0200, Christian Kellermann wrote: > * corvid <corvid(a)lavabit.com> [081002 06:41]: > > Christian wrote: > > > Dear List, > > > > > > since I have not found any traces of discussion on this list about > > > this topic I dare to ask where to place code handling basic > > > authentication in dillo's source? As I see it the cache module is > > > responsible for handling server responses. So I would at a first > > > try add the code there. How can I connect to a UI dialog from here > > > to get the necessary credentials? Maybe a possible solution looks > > > like this: > > > > > > - react to 403 header and look for Authorization request > > > - if there is one ask the user for username/pass > > > + resend the request with the Authorisation header added > > > + or display the 403 if the user aborts > > > > > > > > > What do you think? I will come up with some example code to illustrate > > > the idea in case this is not very clear. > > > > (We'll see what Jorge has to say, but...) > > cache.c seems like the right place to me, with a dialog called by way of > > uicmd.cc. The auth data would be stored away somewhere (a new file?), > > which a_Http_make_query_str() could call like it calls a_Cookies_get_query(). > > > > This sounds good. Yes, following the cookies model, without the dpi part, is a good idea. > What I am thinking about at the moment is how to > keep the user/password combination attached to a certain URL for > future reference? As I see it the connection structure gets dropped > as soon as the transfer of one entity is finished... A new file (auth.c or basic_auth.c) looks like a good place for the auth-specific functions and data. i.e. you can store a URL to user/password/whatever table there, and query it when the AUTH flag is set. > To be more > specific I have been trying something like this: > > > Index: src/cache.c > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/cache.c,v > retrieving revision 1.33 > diff -b -u -p -r1.33 cache.c > --- src/cache.c 14 Sep 2008 20:26:08 -0000 1.33 > +++ src/cache.c 2 Oct 2008 07:13:11 -0000 > @@ -617,7 +617,7 @@ static Dlist *Cache_parse_multiple_field > static void Cache_parse_header(CacheEntry_t *entry) > { > char *header = entry->Header->str; > - char *Length, *Type, *location_str, *encoding, *charset; > + char *Length, *Type, *location_str, *encoding, *charset, *auth; > #ifndef DISABLE_COOKIES > Dlist *Cookies; > #endif > @@ -657,6 +657,23 @@ static void Cache_parse_header(CacheEntr > } > dFree(location_str); > > + } else if (strncmp(header + 9, "401", 3) == 0) { > + auth = Cache_parse_field(header, "WWW-Authenticate"); > + if ( auth ) { > + if (strncmp(auth, "Basic", 5) == 0) { > + entry->Flags |= CA_AuthNeeded; > + entry->Flags |= CA_AuthBasic; > + MSG_HTTP("Basic Authentication request\n"); > + } else if (strncmp(auth, "Digest", 6) == 0) { > + entry->Flags |= CA_AuthNeeded; > + entry->Flags |= CA_AuthDigest; > + MSG_HTTP("Digest Authentication request\n"); > + } else { > + MSG_ERR("Unknown authentication method in request " > + "'%s'.\n", auth); > + } > + MSG_HTTP(" for %s!\n", URL_STR(entry->Url)); > + } > } else if (strncmp(header + 9, "404", 3) == 0) { > entry->Flags |= CA_NotFound; > } > @@ -1037,6 +1054,11 @@ static void Cache_process_queue(CacheEnt > entry->ExpectedSize / (1024*1024)); > AbortEntry = OfferDownload = TRUE; > } > + if (entry->Flags & CA_AuthNeeded) { > + if (!Client->Callback) { > + Client->Callback = Cache_null_client; > + } > + } > } else { > /* For non root URLs, ignore redirections and 404 answers */ > if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) > Index: src/cache.h > =================================================================== > RCS file: /sfhome/cvs/dillo/dillo2/src/cache.h,v > retrieving revision 1.5 > diff -b -u -p -r1.5 cache.h > --- src/cache.h 2 Jun 2008 02:27:43 -0000 1.5 > +++ src/cache.h 2 Oct 2008 07:13:11 -0000 > @@ -33,6 +33,9 @@ extern "C" { > #define CA_InternalUrl 0x800 /* URL content is generated by dillo */ > #define CA_HugeFile 0x1000 /* URL content is too big */ > #define CA_IsEmpty 0x2000 /* True until a byte of content arrives */ > +#define CA_AuthNeeded 0x4000 /* Set if server requests authentication */ > +#define CA_AuthBasic 0x8000 /* Set if server requests basic authentication */ > +#define CA_AuthDigest 0x10000 /* Set if server requests digest authentication */ > > /* > * Callback type for cache clients > > > The bit in Cache_process_queue should be the place where the handling > is done, at least so I thought. Maybe that is not a good idea... > Also I am a but uneasy with introducing new flags but it somehow > fits the overall scheme. Maybe it's possible to make it with just one flag: CA_AuthNeeded. Storing the details in the auth table. > Any suggestions? Yes, go ahead with the prototype implementation, and if you need more advice, just ask. Currently we're quite busy with the release schedule (a few days to go), so please be patient... -- Cheers Jorge.-

Oct. 2, 2008

Basic authentication

by Christian.Kellermann＠nefkom.net

* corvid <corvid(a)lavabit.com> [081002 06:41]: > Christian wrote: > > Dear List, > > > > since I have not found any traces of discussion on this list about > > this topic I dare to ask where to place code handling basic > > authentication in dillo's source? As I see it the cache module is > > responsible for handling server responses. So I would at a first > > try add the code there. How can I connect to a UI dialog from here > > to get the necessary credentials? Maybe a possible solution looks > > like this: > > > > - react to 403 header and look for Authorization request > > - if there is one ask the user for username/pass > > + resend the request with the Authorisation header added > > + or display the 403 if the user aborts > > > > > > What do you think? I will come up with some example code to illustrate > > the idea in case this is not very clear. > > (We'll see what Jorge has to say, but...) > cache.c seems like the right place to me, with a dialog called by way of > uicmd.cc. The auth data would be stored away somewhere (a new file?), > which a_Http_make_query_str() could call like it calls a_Cookies_get_query(). > This sounds good. What I am thinking about at the moment is how to keep the user/password combination attached to a certain URL for future reference? As I see it the connection structure gets dropped as soon as the transfer of one entity is finished... To be more specific I have been trying something like this: Index: src/cache.c =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.c,v retrieving revision 1.33 diff -b -u -p -r1.33 cache.c --- src/cache.c 14 Sep 2008 20:26:08 -0000 1.33 +++ src/cache.c 2 Oct 2008 07:13:11 -0000 @@ -617,7 +617,7 @@ static Dlist *Cache_parse_multiple_field static void Cache_parse_header(CacheEntry_t *entry) { char *header = entry->Header->str; - char *Length, *Type, *location_str, *encoding, *charset; + char *Length, *Type, *location_str, *encoding, *charset, *auth; #ifndef DISABLE_COOKIES Dlist *Cookies; #endif @@ -657,6 +657,23 @@ static void Cache_parse_header(CacheEntr } dFree(location_str); + } else if (strncmp(header + 9, "401", 3) == 0) { + auth = Cache_parse_field(header, "WWW-Authenticate"); + if ( auth ) { + if (strncmp(auth, "Basic", 5) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthBasic; + MSG_HTTP("Basic Authentication request\n"); + } else if (strncmp(auth, "Digest", 6) == 0) { + entry->Flags |= CA_AuthNeeded; + entry->Flags |= CA_AuthDigest; + MSG_HTTP("Digest Authentication request\n"); + } else { + MSG_ERR("Unknown authentication method in request " + "'%s'.\n", auth); + } + MSG_HTTP(" for %s!\n", URL_STR(entry->Url)); + } } else if (strncmp(header + 9, "404", 3) == 0) { entry->Flags |= CA_NotFound; } @@ -1037,6 +1054,11 @@ static void Cache_process_queue(CacheEnt entry->ExpectedSize / (1024*1024)); AbortEntry = OfferDownload = TRUE; } + if (entry->Flags & CA_AuthNeeded) { + if (!Client->Callback) { + Client->Callback = Cache_null_client; + } + } } else { /* For non root URLs, ignore redirections and 404 answers */ if (entry->Flags & CA_Redirect || entry->Flags & CA_NotFound) Index: src/cache.h =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/cache.h,v retrieving revision 1.5 diff -b -u -p -r1.5 cache.h --- src/cache.h 2 Jun 2008 02:27:43 -0000 1.5 +++ src/cache.h 2 Oct 2008 07:13:11 -0000 @@ -33,6 +33,9 @@ extern "C" { #define CA_InternalUrl 0x800 /* URL content is generated by dillo */ #define CA_HugeFile 0x1000 /* URL content is too big */ #define CA_IsEmpty 0x2000 /* True until a byte of content arrives */ +#define CA_AuthNeeded 0x4000 /* Set if server requests authentication */ +#define CA_AuthBasic 0x8000 /* Set if server requests basic authentication */ +#define CA_AuthDigest 0x10000 /* Set if server requests digest authentication */ /* * Callback type for cache clients The bit in Cache_process_queue should be the place where the handling is done, at least so I thought. Maybe that is not a good idea... Also I am a but uneasy with introducing new flags but it somehow fits the overall scheme. Any suggestions? Kind regards, Christian P.S.: This patch is a work in progress and more of an example than anything. -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Oct. 2, 2008

Basic authentication

by corvid＠lavabit.com

Christian wrote: > Dear List, > > since I have not found any traces of discussion on this list about > this topic I dare to ask where to place code handling basic > authentication in dillo's source? As I see it the cache module is > responsible for handling server responses. So I would at a first > try add the code there. How can I connect to a UI dialog from here > to get the necessary credentials? Maybe a possible solution looks > like this: > > - react to 403 header and look for Authorization request > - if there is one ask the user for username/pass > + resend the request with the Authorisation header added > + or display the 403 if the user aborts > > > What do you think? I will come up with some example code to illustrate > the idea in case this is not very clear. (We'll see what Jorge has to say, but...) cache.c seems like the right place to me, with a dialog called by way of uicmd.cc. The auth data would be stored away somewhere (a new file?), which a_Http_make_query_str() could call like it calls a_Cookies_get_query().

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 11:11:23PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 03:01:19PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 06:14:47PM +0200, Johannes Hofmann wrote: > > > On Wed, Oct 01, 2008 at 11:45:53AM -0400, Jorge Arellano Cid wrote: > > > > On Wed, Oct 01, 2008 at 04:47:05PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > On Wed, Oct 01, 2008 at 10:33:20AM -0400, Jorge Arellano Cid wrote: > > > > > > Hi, > > > > > > > > > > > > On Sat, Sep 27, 2008 at 05:38:03PM -0400, Jorge Arellano Cid wrote: > > > > > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > > > > > It's still possible to crash dillo if you click on a remote link and > > > > > > > > quickly click on some images to load them. Doesn't crash every time, > > > > > > > > but typically within four tries or so. I had assumed it was the same > > > > > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > > > > > > > > > If I stick > > > > > > > > a_Bw_stop_clients(bw, BW_Img); > > > > > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > > > > > earlier today, so there's something wrong with just doing that. > > > > > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > > > > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > > > > > > > > > I've tried several different ways but can't get to crash it. > > > > > > > > > > > > > > Does the attached patch help? > > > > > > > > > > > > > > -- > > > > > > > Cheers > > > > > > > Jorge.- > > > > > > > > > > > > > diff -pru dillo2/src/html.cc dillo2-cur/src/html.cc > > > > > > > --- dillo2/src/html.cc 2008-09-27 15:11:08.000000000 -0400 > > > > > > > +++ dillo2-cur/src/html.cc 2008-09-27 17:34:21.000000000 -0400 > > > > > > > @@ -711,6 +711,8 @@ bool_t DilloHtml::unloadedImages() > > > > > > > */ > > > > > > > void DilloHtml::loadImages (const DilloUrl *pattern) > > > > > > > { > > > > > > > + dReturn_if_fail (bw->nav_expecting == FALSE); > > > > > > > + > > > > > > > for (int i = 0; i < images->size(); i++) { > > > > > > > if (images->get(i)->image) { > > > > > > > if ((!pattern) || (!a_Url_cmp(images->get(i)->url, pattern))) { > > > > > > > > > > > > Can you still crash dillo this way, with the latest CVS? > > > > > > (i.e. without the above patch). > > > > > > > > > > I'm currently seeing all sorts of crashes and I suspect that they > > > > > are related to xpmImage from fltk. > > > > > Could someone with a linux machine please check current dillo with > > > > > valgrind especially when the new mini_bug_xpm is shown? > > > > > > > > > > Also changing mini_bug_xpm to 15x15 seems to fix things for me. > > > > > I don't understand all that completely, but other crashes might be > > > > > related to this. > > > > > > > > OK, I'll check with valgrind... > > > > Does changing mini_ok_xpm to 16x16 fix it too? > > > > > > No it doesn't, that's what I thought first too :-) > > > > > > But it really only happens when fltk was compiled with > > > --disable-xft > > > > I did that and FLTK's tests don't use xft, but my > > dillo-fltk still uses them! > > > > Did you call ./configure for dillo again? Yes. I forgot to make install FLTK, now it works. :) > > > > > > > BTW, does a: > > > > - new_w = strlen(str)*8 + 20; > > + new_w = strlen(str)*8 + 40; > > > > in ui.cc solve the problem for you? > > No, it doesn't. I think it's a fltk problem. Yes, valgrind reports an invalid write of size 1. See the attached file. It looks like unless FLTK2 is patched, we'll have a w=15 minibug as workaround. -- Cheers Jorge.-

Oct. 2, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > > yesterday). You know how leaving the window sometimes causes an extra > > > > Nav_open_url()? > > > > > > No, I don't know. > > > How is it triggered? > > > > Really? I've gotten them often throughout this whole fltk era. > > Taking out my fix, here's a breakpoint on Nav_open_url, > > triggered by leaving the window: > > > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > > #7 0x080e56f4 in fix_focus () at run.cxx:108 > > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > > #12 0x080e79fe in fltk::run () at run.cxx:399 > > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 > > From the bt it's clear it happens, But how do I trigger/reproduce it. > I've tried moving the mouse pointer out of the window, focusing another > window, etc. With no luck. The reliable way that I'm using (haven't checked how many of these steps/precautions are strictly necessary) - type an url into the Location CustInput and press enter. - don't touch the mouse - when the page has finished loading completely - move the mouse out of the window In case there's some WM interaction, I have fvwm.

Oct. 2, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 09:46:06PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > > > Also, I found out why loading was sometimes randomly disabled (as mentioned > > > yesterday). You know how leaving the window sometimes causes an extra > > > Nav_open_url()? > > > > No, I don't know. > > How is it triggered? > > Really? I've gotten them often throughout this whole fltk era. > Taking out my fix, here's a breakpoint on Nav_open_url, > triggered by leaving the window: > > Breakpoint 1, Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > 201 MSG("Nav_open_url: new url='%s'\n", URL_STR_(url)); > #0 Nav_open_url (bw=0x81b18e8, url=0x81c3998, offset=0) at nav.c:201 > #1 0x0805cd4d in a_Nav_push (bw=0x81b18e8, url=0x81c3998) at nav.c:350 > #2 0x080554ae in a_UIcmd_open_urlstr (vbw=0x81b18e8, urlstr=0x81c44b8 "http://www.dillo.org") at uicmd.cc:323 > #3 0x08053c12 in location_cb (wid=0x816c6a8, data=0x815c2d8) at ui.cc:245 > #4 0x08055fa7 in fltk::Widget::do_callback (this=0x816c6a8) at ../fltk/Widget.h:127 > #5 0x080e093c in call_pending_if_not (i=0x0) at run.cxx:804 > #6 0x080e124c in fltk::focus (o=0x0) at run.cxx:868 > #7 0x080e56f4 in fix_focus () at run.cxx:108 > #8 0x080e676f in fltk::handle () at x11/run.cxx:1603 > #9 0x080e7520 in do_queued_events () at x11/run.cxx:399 > #10 0x080e784c in fl_wait (time_to_wait=1.00000002e+20) at x11/run.cxx:459 > #11 0x080e78e7 in fltk::wait (time_to_wait=1.00000002e+20) at run.cxx:463 > #12 0x080e79fe in fltk::run () at run.cxx:399 > #13 0x0804efab in main (argc=1, argv=0xbffffb34) at dillo.cc:127 From the bt it's clear it happens, But how do I trigger/reproduce it. I've tried moving the mouse pointer out of the window, focusing another window, etc. With no luck. -- Cheers Jorge.-

Oct. 2, 2008