- Dillo-dev - lists.mailman3.com

feature freeze

by corvid＠lavabit.com

Kelson wrote: > So long as Dillo doesn't have client-side scripting, the attribute can > just be ignored. I was looking through the RFCs to see what the rule was regarding unknown attributes, and I was able to find in rfc2965, for Set-Cookie2: "The user agent MUST ignore attribute-value pairs whose attribute it does not recognize", and in rfc2109, "An 'old' client that receives a 'new' cookie will ignore attributes it does not understand..." So it does sound like dillo can ignore unknown attributes rather than regarding them as errors. PS The cookie RFCs do not seem very clearly written in general.

Oct. 3, 2008

findbar sometimes stops accepting input

by corvid＠lavabit.com

I've seen this a couple times now...I can't remember whether it started before the last revision to findbar.cc. I can still highlight the findbar text, but I can't change it. I think closing/reopening the bar has always fixed it so far.

Oct. 3, 2008

feature freeze

by onepoint＠starurchin.org

On Thu, Oct 02, 2008 at 03:20:02PM -0700, Kelson Vibber wrote: > [snip: excellent summary of the purpose of the HttpOnly cookie attr] > > So long as Dillo doesn't have client-side scripting, the attribute > can just be ignored. OK, patch attached. (NB: the patch context depends on my previous MSG-enhancing patch, but I think it will apply with a little fuzz even without it.) And now I must away to correct every Wikipedia update since I last logged in. I may be some time. :-) Regards, Jeremy Henty

Oct. 3, 2008

feature freeze

by kelson＠pobox.com

Jeremy Henty wrote: > Dillo won't let me login to Wikipedia! Of course this may be a *good* > thing. :-) After making the MSG a little more verbose (patch > attached) it reports that it is rejecting the HttpOnly attribute (log > attached). I *think* this attribute is a security feature to avoid > hacks that trick your browser into relaying cookie info from an http > connection to an https connection. What should dillo do here? The HttpOnly flag indicates that the cookie should only be passed via HTTP requests and not accessible by client-side scripts. The idea is to make cross-site scripting attacks harder by preventing an injected script from accessing a site's authentication tokens or other data stored in cookies. So long as Dillo doesn't have client-side scripting, the attribute can just be ignored. More info: http://msdn.microsoft.com/en-us/library/ms533046.aspx http://www.owasp.org/index.php/HTTPOnly The second link includes a table of current support in various browsers. -- Kelson Vibber Hyperborea.org - SpeedForce.org - AlternativeBrowserAlliance.com

Oct. 3, 2008

feature freeze

by onepoint＠starurchin.org

On Thu, Oct 02, 2008 at 02:01:35PM -0400, Jorge Arellano Cid wrote: > OK, so we have: Dillo won't let me login to Wikipedia! Of course this may be a *good* thing. :-) After making the MSG a little more verbose (patch attached) it reports that it is rejecting the HttpOnly attribute (log attached). I *think* this attribute is a security feature to avoid hacks that trick your browser into relaying cookie info from an http connection to an https connection. What should dillo do here? No matter what dillo should do, I think this diagnostics patch is good because it makes the MSG far more useful. Regards, Jeremy Henty

Oct. 2, 2008

feature freeze

by onepoint＠starurchin.org

On Thu, Oct 02, 2008 at 08:01:58PM +0200, Johannes Hofmann wrote: > 6.- redraw storms related to the MenuTabPager (noticed by Jeremy) > [...] > 6: Using the ShrinkTabPager avoids the problem Here's a (tiny) patch to use the ShrinkTabPager . Personally I find dillo almost unusable without it, but that may be because I like to open lots of tabs. Regards, Jeremy Henty

Oct. 2, 2008

crash with reload and textarea

by Johannes.Hofmann＠gmx.de

On Thu, Oct 02, 2008 at 07:12:31PM +0000, corvid wrote: > It doesn't seem to want to break for me, but > I wonder whether it bears some similarity to > this whole deal with my pending callbacks: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005000.html > Don't think so. The textarea thing turned out to be a small fltk2 bug: http://www.fltk.org/str.php?L2055 Cheers, Johannes

Oct. 2, 2008

patch: close windows from menubar

by corvid＠lavabit.com

BTW, I notice that ctrl-Q and alt-Q, listed in the menu, don't do anything.

Oct. 2, 2008

feature freeze

by corvid＠lavabit.com

I wrote: > WM decorations: Unfortunate, yeah. > I still use xwd. I don't know what people use nowadays. > Probably something heavyweight. Guess what? xwd has a -frame option. Sigh. I never even checked.

Oct. 2, 2008

feature freeze

by Johannes.Hofmann＠gmx.de

On Thu, Oct 02, 2008 at 06:27:11PM +0000, corvid wrote: > Jorge wrote: > > OK, so we have: > > > > 1.- the mini_bug.xpm FLTK2 fix. > > 2.- the focused textarea callback issue. > > 3.- Alt-X crash in the menu. > > 4.- hardcoded 128 tabs. > > 5.- leaving-the-window nav_expecting problem. > > > > > > Status: > > > > 1: There's a simple workaround. > > 2: Waiting for comment from Johannes. > > 3: There's a simple workaround. Valgrind may shed some light... > > We know the problem. No valgrind necessary. > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004981.ht… > > > 4: We may ship with dillo-hardcoded maxtabs. Right? > > 5: Doesn't happen with XFCE... Will test icewm and fvwm. > > > > > > BTW, I noticed the nice new screnshots. Good! > > From a purely aesthetic point of view, > > why are WM decorations left out? > > WM decorations: Unfortunate, yeah. > I still use xwd. I don't know what people use nowadays. > Probably something heavyweight. > dwm (www.suckless.org) wc -l dwm.c 1742 dwm.c :-) Cheers, Johannes

Oct. 2, 2008

feature freeze

by corvid＠lavabit.com

Jorge wrote: > OK, so we have: > > 1.- the mini_bug.xpm FLTK2 fix. > 2.- the focused textarea callback issue. > 3.- Alt-X crash in the menu. > 4.- hardcoded 128 tabs. > 5.- leaving-the-window nav_expecting problem. > > > Status: > > 1: There's a simple workaround. > 2: Waiting for comment from Johannes. > 3: There's a simple workaround. Valgrind may shed some light... We know the problem. No valgrind necessary. http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004981.ht… > 4: We may ship with dillo-hardcoded maxtabs. Right? > 5: Doesn't happen with XFCE... Will test icewm and fvwm. > > > BTW, I noticed the nice new screnshots. Good! > From a purely aesthetic point of view, > why are WM decorations left out? WM decorations: Unfortunate, yeah. I still use xwd. I don't know what people use nowadays. Probably something heavyweight.

Oct. 2, 2008

feature freeze

by Johannes.Hofmann＠gmx.de

On Thu, Oct 02, 2008 at 02:01:35PM -0400, Jorge Arellano Cid wrote: > On Thu, Oct 02, 2008 at 05:44:32PM +0000, corvid wrote: > > Jorge wrote: > > > More or less we entered "feature freeze" mode implicitly. > > > > > > What is left pending? > > > > > > I remember: > > > > > > - the mini_bug.xpm FLTK2 fix. > > > - the focused textarea callback issue. > > > > My alt-X crash in the menu. I guess I'll look into giving it a timeout. > > > > I think the 128 tabs and some other hardcoded 128 in there that Johannes found > > are still there. > > > > My leaving-the-window nav_expecting problem would be nice if possible. > > OK, so we have: > > 1.- the mini_bug.xpm FLTK2 fix. > 2.- the focused textarea callback issue. > 3.- Alt-X crash in the menu. > 4.- hardcoded 128 tabs. > 5.- leaving-the-window nav_expecting problem. 6.- redraw storms related to the MenuTabPager (noticed by Jeremy) > > > Status: > > 1: There's a simple workaround. > 2: Waiting for comment from Johannes. > 3: There's a simple workaround. Valgrind may shed some light... > 4: We may ship with dillo-hardcoded maxtabs. Right? > 5: Doesn't happen with XFCE... Will test icewm and fvwm. > 6: Using the ShrinkTabPager avoids the problem Cheers, Johannes

Oct. 2, 2008

feature freeze

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 05:44:32PM +0000, corvid wrote: > Jorge wrote: > > More or less we entered "feature freeze" mode implicitly. > > > > What is left pending? > > > > I remember: > > > > - the mini_bug.xpm FLTK2 fix. > > - the focused textarea callback issue. > > My alt-X crash in the menu. I guess I'll look into giving it a timeout. > > I think the 128 tabs and some other hardcoded 128 in there that Johannes found > are still there. > > My leaving-the-window nav_expecting problem would be nice if possible. OK, so we have: 1.- the mini_bug.xpm FLTK2 fix. 2.- the focused textarea callback issue. 3.- Alt-X crash in the menu. 4.- hardcoded 128 tabs. 5.- leaving-the-window nav_expecting problem. Status: 1: There's a simple workaround. 2: Waiting for comment from Johannes. 3: There's a simple workaround. Valgrind may shed some light... 4: We may ship with dillo-hardcoded maxtabs. Right? 5: Doesn't happen with XFCE... Will test icewm and fvwm. BTW, I noticed the nice new screnshots. Good! From a purely aesthetic point of view, why are WM decorations left out? -- Cheers Jorge.-

Oct. 2, 2008

crash with reload and textarea

by Johannes.Hofmann＠gmx.de

On Thu, Oct 02, 2008 at 12:51:16PM -0400, Jorge Arellano Cid wrote: > On Thu, Oct 02, 2008 at 05:38:18PM +0200, Johannes Hofmann wrote: > > 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: > > There seems to be a bug in FLTK2's Input::replace(), > called by Input::insert(). > > The attached workaround solves it for me. Please check. No, that doesn't help. Perhaps I wasn't clear about the textarea thing. I meant something like: <html> <body> <form> <textarea></textarea> </form> </body> </html> On that page if I enter something, keep the focus in the textarea widget, hit Ctrl-r and then click somewhere I get the crash. Cheers, Johannes

Oct. 2, 2008

feature freeze

by corvid＠lavabit.com

Jorge wrote: > More or less we entered "feature freeze" mode implicitly. > > What is left pending? > > I remember: > > - the mini_bug.xpm FLTK2 fix. > - the focused textarea callback issue. My alt-X crash in the menu. I guess I'll look into giving it a timeout. I think the 128 tabs and some other hardcoded 128 in there that Johannes found are still there. My leaving-the-window nav_expecting problem would be nice if possible.

Oct. 2, 2008

Javascript engine

by jcid＠dillo.org

Hi, Does anybody know about a lightweight javascript engine we can use with dillo? From what I've seen, SEE (Simple ECMAScript Engine), looks like a good candidate. Disclaimer: I'm a newbie on JavaScript. -- Cheers Jorge.-

Oct. 2, 2008

crash with reload and textarea

by jcid＠dillo.org

On Thu, Oct 02, 2008 at 05:38:18PM +0200, Johannes Hofmann wrote: > 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: There seems to be a bug in FLTK2's Input::replace(), called by Input::insert(). The attached workaround solves it for me. Please check. -- Cheers Jorge.-

Oct. 2, 2008

feature freeze

by jcid＠dillo.org

Hi, More or less we entered "feature freeze" mode implicitly. What is left pending? I remember: - the mini_bug.xpm FLTK2 fix. - the focused textarea callback issue. -- Cheers Jorge.-

Oct. 2, 2008

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

what crashes remain?

by corvid＠lavabit.com

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

Oct. 1, 2008

[patch] share button images between UIs

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 10:54:41PM +0200, Johannes Hofmann wrote: > On Wed, Oct 01, 2008 at 04:38:42PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 02:58:44PM -0400, Jorge Arellano Cid wrote: > > > On Wed, Oct 01, 2008 at 07:36:54PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > this is independent from the recent crashes. > > > > This patch shares the images between multiple UIs. > > > > > > > > What do you think? > > > > > > Committed! > > > > > > Except that "img on/off" doesn't switch the icon. > > > Please send me a patch for this. > > > > Don't worry, it's fixed in CVS now. > > > > Ah thanks. A similar fix is necessary for small icons. > Patch attached. Committed. -- Cheers Jorge.-

Oct. 1, 2008

an experiment regarding cross site request forgery

by corvid＠lavabit.com

Justus wrote: > Johannes Hofmann wrote: > > Perhaps we should be more careful when to send out a cookie. > > What about not sending cookies with image requests, if the host of > > the image url is different from the one in the main page? > > What do other browser do about this? > > Yes, I think this is the way to go. One need to decide when to send out > authentication credentials (legitimate session) and when to strip them > (CSRF attempt). Martin Johns and I developed a firefox extension [0] > that does exactly this. Please see [1] pages 29 - 37 or [2] for more > information. [1] is also a pretty good introduction to CSRF. Please note > that the browser independent proxy solution is deprecated (but should > work unless the twisted framework changed its api too much) and the > firefox extension is somewhat unmaintained at the moment... Having done some reading now: So for an HTTP redirect or an image request, A->B, I gather up the cookies that I would send when asking for B and discard those that I would not send if I were asking for A?

Oct. 1, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

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

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > Jorge 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? > > Seems to be working well so far. > Is there any danger in adding something like > a_Nav_cancel_expect to a_UIcmd_stop()? It looks safe to do. It even looks like the right thing to do. Just committed: - Disallowed loading images when expecting is set. - Added a cancel_expect call to the Stop button. -- Cheers Jorge.-

Oct. 1, 2008

[patch] share button images between UIs

by Johannes.Hofmann＠gmx.de

On Wed, Oct 01, 2008 at 04:38:42PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 01, 2008 at 02:58:44PM -0400, Jorge Arellano Cid wrote: > > On Wed, Oct 01, 2008 at 07:36:54PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > this is independent from the recent crashes. > > > This patch shares the images between multiple UIs. > > > > > > What do you think? > > > > Committed! > > > > Except that "img on/off" doesn't switch the icon. > > Please send me a patch for this. > > Don't worry, it's fixed in CVS now. > Ah thanks. A similar fix is necessary for small icons. Patch attached. Cheers, Johannes

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 02:48:10PM +0000, corvid wrote: > Jorge wrote: > > 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). > > Yes. > > 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? -- Cheers Jorge.-

Oct. 1, 2008

[patch] share button images between UIs

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 02:58:44PM -0400, Jorge Arellano Cid wrote: > On Wed, Oct 01, 2008 at 07:36:54PM +0200, Johannes Hofmann wrote: > > Hi, > > > > this is independent from the recent crashes. > > This patch shares the images between multiple UIs. > > > > What do you think? > > Committed! > > Except that "img on/off" doesn't switch the icon. > Please send me a patch for this. Don't worry, it's fixed in CVS now. -- Cheers Jorge.-

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

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! BTW, does a: - new_w = strlen(str)*8 + 20; + new_w = strlen(str)*8 + 40; in ui.cc solve the problem for you? If true, I can make a patch using measure(). -- Cheers Jorge.-

Oct. 1, 2008

[patch] share button images between UIs

by jcid＠dillo.org

On Wed, Oct 01, 2008 at 07:36:54PM +0200, Johannes Hofmann wrote: > Hi, > > this is independent from the recent crashes. > This patch shares the images between multiple UIs. > > What do you think? Committed! Except that "img on/off" doesn't switch the icon. Please send me a patch for this. -- Cheers Jorge.-

Oct. 1, 2008

[patch] share button images between UIs

by corvid＠lavabit.com

Johannes wrote: > this is independent from the recent crashes. > This patch shares the images between multiple UIs. > > What do you think? Good!

Oct. 1, 2008

[patch] share button images between UIs

by Johannes.Hofmann＠gmx.de

Hi, this is independent from the recent crashes. This patch shares the images between multiple UIs. What do you think? Cheers, Johannes

Oct. 1, 2008

Basic authentication

by Christian.Kellermann＠nefkom.net

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. Kind regards, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

Oct. 1, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

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

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

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? -- Cheers Jorge.-

Oct. 1, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

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? Update: This only seems to happen when fltk was compiled with the --disable-xft switch. Cheers, Johannes

Oct. 1, 2008

what crashes remain?

by Johannes.Hofmann＠gmx.de

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

Oct. 1, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > 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). Yes. 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()? That was turning nav_expecting back on. The following patch has gotten rid of those for me:

Oct. 1, 2008

what crashes remain?

by jcid＠dillo.org

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). -- Cheers Jorge.-

Oct. 1, 2008

segfault -- callback + closed window?

by jcid＠dillo.org

On Tue, Sep 30, 2008 at 03:16:30PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 30, 2008 at 06:39:44PM +0200, Johannes Hofmann wrote: > > On Tue, Sep 30, 2008 at 12:41:21PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 30, 2008 at 12:03:57PM -0400, Jorge Arellano Cid wrote: > > > > On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > > > > > I hit ',' a few times, going back past a page with a > > > > > > big progressive jpeg webcomic, and hit ^Q to close the window > > > > > > while dillo was thinking its way past that image. > > > > > > > > > > > > Got: > > > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > > [Switching to Thread 16384 (LWP 2782)] > > > > > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > > at Widget.cxx:575 > > > > > > 575 widget->damage_ |= DAMAGE_CHILD; > > > > > > (gdb) bt > > > > > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > > at Widget.cxx:575 > > > > > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > > > > > at ui.cc:1109 > > > > > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > > > > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > > > > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > > > > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > > > > > > > > > > > > > Maybe that's just a part of life with callbacks... > > > > > > > > > > > > > > > > I no longer see this crash when removing the buttons_sens workaround > > > > > in uicmd.cc as in attached patch. > > > > > Does someone remember why it was introduced? > > > > > > > > It comes from dillo1. > > > > > > > > Committed. > > > > > > > > BTW, this is exactly what I meant with a UI getting the wrong bw. > > > > I think this should be fixed before the release. > > > > > > Update: I have a patch that works in my tree. It gets rid of > > > bw as the window's user_data(). > > > Just allow me some time to test/polish. > > > > > > > Cool. Just wanted to start it myself. > > Please try the attached patch, not tested, I'm on my way > to the airport. I just committed a more polished version. It gets rid of the ui->vbw(), the user_data() setting on FOCUS event and has a new version of win_cb(). Please give it some good testing. -- Cheers Jorge.-

Oct. 1, 2008

an experiment regarding cross site request forgery

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On Tue, Sep 30, 2008 at 12:56:05PM +0000, corvid wrote: >> Cross site request forgery is the one where the bad person sticks >> an image tag or some javascript or whatever on a page, >> and your privileges are used to do something. Johannes Hofmann wrote: > To me the cross site request forgery issue looks more like an issue of > the cookie system. No. CSRF is caused by browsers sending authentication credentials implicitly with every request to an host. Those credentials might be cookies, http AUTH headers, ssl client certificates or even your IP address in some (stupid) intranet solutions. Joerg Sonnenberger wrote: > There's nothing wrong with that. Such an image URL is a simple GET > request. Any web application doing a modification is broken by design > and there are good reasons for allowing such URLs. The problem is > allowing POST actions to a different site than the one issuing it. This is true, GET requests shouldn't be state changing. But there are ways to create POST requests automatically (most ''active content'' can do this) or by tricking the user into clicking on the submit button by styling them via css (this is called "clickjacking" nowadays... yay for more buzzwords) and using some social engineering ("click the monkey to win big $$$). Disallowing cross domain POST requests seems very restrictive but would solve the problem. Johannes Hofmann wrote: > Perhaps we should be more careful when to send out a cookie. > What about not sending cookies with image requests, if the host of > the image url is different from the one in the main page? > What do other browser do about this? Yes, I think this is the way to go. One need to decide when to send out authentication credentials (legitimate session) and when to strip them (CSRF attempt). Martin Johns and I developed a firefox extension [0] that does exactly this. Please see [1] pages 29 - 37 or [2] for more information. [1] is also a pretty good introduction to CSRF. Please note that the browser independent proxy solution is deprecated (but should work unless the twisted framework changed its api too much) and the firefox extension is somewhat unmaintained at the moment... Justus 0: http://www.nongnu.org/requestrodeo/ 1: http://www.informatik.uni-hamburg.de/SVS/personnel/martin/psj06johns-e.pdf 2: http://www.informatik.uni-hamburg.de/SVS/papers/2006_owasp_RequestRodeo.pdf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI41/IoPmwNWhsaZYRAhXNAJ0WbzFz51LEObLbF8/oEPkUuZtT4ACfbCNG KDOXrmHCAOyhR15a+p5tgR0= =Kokv -----END PGP SIGNATURE-----

Oct. 1, 2008

segfault -- callback + closed window?

by jcid＠dillo.org

On Tue, Sep 30, 2008 at 06:39:44PM +0200, Johannes Hofmann wrote: > On Tue, Sep 30, 2008 at 12:41:21PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 30, 2008 at 12:03:57PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 30, 2008 at 05:22:08PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > On Mon, Sep 29, 2008 at 07:38:20PM +0000, corvid wrote: > > > > > I hit ',' a few times, going back past a page with a > > > > > big progressive jpeg webcomic, and hit ^Q to close the window > > > > > while dillo was thinking its way past that image. > > > > > > > > > > Got: > > > > > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > > > [Switching to Thread 16384 (LWP 2782)] > > > > > 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > at Widget.cxx:575 > > > > > 575 widget->damage_ |= DAMAGE_CHILD; > > > > > (gdb) bt > > > > > #0 0x080fc708 in fltk::Widget::redraw (this=0x81cb680, flags=8 '\b') > > > > > at Widget.cxx:575 > > > > > #1 0x0804f679 in UI::button_set_sens (this=0x82ce9d8, btn=UI_STOP, sens=0) > > > > > at ui.cc:1109 > > > > > #2 0x08054c59 in a_UIcmd_set_buttons_sens_cb (vbw=0x81ad858) at uicmd.cc:835 > > > > > #3 0x080e47f9 in fltk::wait () at TabGroup.cxx:116 > > > > > #4 0x080e489d in fltk::run () at TabGroup.cxx:116 > > > > > #5 0x0804efab in main (argc=1, argv=0xbffffb44) at dillo.cc:127 > > > > > > > > > > > > > > > Maybe that's just a part of life with callbacks... > > > > > > > > > > > > > I no longer see this crash when removing the buttons_sens workaround > > > > in uicmd.cc as in attached patch. > > > > Does someone remember why it was introduced? > > > > > > It comes from dillo1. > > > > > > Committed. > > > > > > BTW, this is exactly what I meant with a UI getting the wrong bw. > > > I think this should be fixed before the release. > > > > Update: I have a patch that works in my tree. It gets rid of > > bw as the window's user_data(). > > Just allow me some time to test/polish. > > > > Cool. Just wanted to start it myself. Please try the attached patch, not tested, I'm on my way to the airport. -- Cheers Jorge.-

Sept. 30, 2008