- Dillo-dev - lists.mailman3.com

Segfault on sites requiring authentication

by tim.nieradzik＠gmx.de

Whenever I visit http://puppyisos.org/isos (puppy / linux), Dillo segfaults. The reason is that in some cases the variable Client_bw is NULL. However, some functions depend on it and access its member variables. Client_bw is initialized in Cache_process_queue() (src/cache.c). When authentication is required, this variable is passed over to Cache_auth_entry() which sets a timeout. Its callback (Cache_auth_callback()) opens up a dialog asking for the credentials and then calls a_Nav_reload() with the Client_bw as its first parameter. Finally in a_Nav_cancel_expect() Client_bw's member variable nav_expecting is used and as bw is NULL, Dillo segfaults. I came up with a small patch that removes Cache_auth_callback() and Cache_auth_entry() as I have not seen any advantages in delaying the authentication popup. The next thing I did was to show the dialog on condition that Client_bw is not NULL and that we have finished the transfer (At least I hope CA_Close is the proper flag for doing so). There were various unnecessary checks in src/nav.c. They compared bw with NULL. In my opinion the affected functions (a_Nav_expect_done, a_Nav_push and a_Nav_repush) should never be called if you cannot be sure that bw is not NUL. What is your view on this subject? Unfortunately, my approach does not solve the original problem that caused Client_bw being NULL. Furthermore, the patch introduces a new bug: The dialog pops up when reloading the site but after having entered the correct credentials or having pressed the ``Cancel'' button, it appears again. Any ideas? While digging deeper into the code, I noticed that we make heavy use of timers for popups and reloading pages? Is there any special reason for it? --Tim

April 1, 2009

tools button name (a very trivial matter)

by corvid＠lavabit.com

Jorge wrote: > On Sat, Mar 28, 2009 at 12:02:59AM +0000, corvid wrote: > > I was going to update the dillorc comment for load_images > > (still mentions the old dedicated button), and... > > to developers, it's in the Tools button's menu now, > > but to users, it's the Settings button because that's > > what the tooltip says. > > ... and the button text-label is "Tools". > > > We should standardize on one name or the other. > > The tooltips explain briefly what each button does. In this > case it could also be: "Browser settings", "Customize browser > behaviour", "Browser tools", "Browser preferences" or similar. > I'd keep "Tools" as the name of the button and try to find a good > tooltip text. All right, then I can either call it "Browser tools" in the tooltip or be careful always to call it the tools/settings button in documentation.

March 29, 2009

tools button name (a very trivial matter)

by jcid＠dillo.org

On Sat, Mar 28, 2009 at 12:02:59AM +0000, corvid wrote: > I was going to update the dillorc comment for load_images > (still mentions the old dedicated button), and... > to developers, it's in the Tools button's menu now, > but to users, it's the Settings button because that's > what the tooltip says. ... and the button text-label is "Tools". > We should standardize on one name or the other. The tooltips explain briefly what each button does. In this case it could also be: "Browser settings", "Customize browser behaviour", "Browser tools", "Browser preferences" or similar. I'd keep "Tools" as the name of the button and try to find a good tooltip text. Comments/Suggestions/Other_ideas? -- Cheers Jorge.-

March 28, 2009

tools button name (a very trivial matter)

by corvid＠lavabit.com

I was going to update the dillorc comment for load_images (still mentions the old dedicated button), and... to developers, it's in the Tools button's menu now, but to users, it's the Settings button because that's what the tooltip says. We should standardize on one name or the other.

March 28, 2009

memory use

by dillo-dev＠toykeeper.net

* Jorge Arellano Cid <jcid(a)dillo.org> wrote: > BTW, it'd be good to have some memory usage data for dillo-2.1. A while ago, I noticed that dillo was using a lot of memory on a specific page, and I didn't remember it doing that before. So I tested a few versions and found that dillo2 uses more memory initially, but less memory for large tables. Specifically: Memory use (in KiB) (on ubuntu 7.10 x86_64) dillo-0.8.6/src/dillo: 3692 file:///nothing 4900 http://dillo.org/ 45204 http://idlerpg.net/db.php dillo-2.0/src/dillo: 4700 file:///nothing 6564 http://dillo.org/ 36408 http://idlerpg.net/db.php hg/dillo/src/dillo: 4812 file:///nothing 6684 http://dillo.org/ 36756 http://idlerpg.net/db.php > Note: I remmeber having an awful memory footprint on 64bit > Ubuntu. It didn't happen with 32bit. What's the current status, > I don't know. I have both 64-bit and 32-bit ubuntu systems here, if you need measurements. For example, I tried the above on my 32-bit box: Memory use (in KiB) (on ubuntu 8.04 i686) dillo-0.8.6/src/dillo: 4916 file:///nothing 6504 http://dillo.org/ 36824 http://idlerpg.net/db.php dillo-2.0/src/dillo: 3972 file:///nothing 5732 http://dillo.org/ 25144 http://idlerpg.net/db.php hg/dillo/src/dillo: 4036 file:///nothing 5760 http://dillo.org/ 25296 http://idlerpg.net/db.php These are pretty easy to generate with a short script: #!/bin/sh BROWSERs="./dillo-0.8.6/src/dillo ./dillo-2.0/src/dillo ./hg/dillo/src/dillo" URLs="file:///nothing http://dillo.org/ http://idlerpg.net/db.php" for BROWSER in $BROWSERs ; do echo "$BROWSER:" for URL in $URLs ; do $BROWSER $URL < /dev/null > /dev/null 2>&1 & PID=$! sleep 5 MEM=`ps axu | grep " $PID " | grep -v grep | awk '{ print $6 }'` # or: expr `cat /proc/$PID/statm | cut -d ' ' -f 2` \* 4 # (to avoid bad grep matches) kill $PID echo " $MEM $URL" done done I hope this helps. -- Scott

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by jcid＠dillo.org

On Fri, Mar 27, 2009 at 01:07:14PM +0100, Hofmann Johannes wrote: > Hi, > > On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > > dpi.c: In function ?a_Dpi_bye_dpid?: > > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > > Can you please check whether attached patches fix the warnings? > > @all: please have a look at the dpi.c fix. It looks OK to me. I'd just: s/p1/nl/ -- Cheers Jorge.-

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Mar 27, 2009 at 12:00:46AM +0100, Michal Nowak wrote: > Found this three warnings when compiling with gcc-4.3.2-7.i386: > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c > dpi.c: In function ?Dpi_get_dpid_uds_dir?: > dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result > dpi.c: In function ?a_Dpi_bye_dpid?: > dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result > > g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc > ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: > ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false Can you please check whether attached patches fix the warnings? @all: please have a look at the dpi.c fix. Cheers, Johannes

March 27, 2009

Warnings in src/IO/dpi.c and lout/misc.hh

by newman.x＠gmail.com

Found this three warnings when compiling with gcc-4.3.2-7.i386: gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dpi.o -MD -MP -MF .deps/dpi.Tpo -c -o dpi.o dpi.c dpi.c: In function ?Dpi_get_dpid_uds_dir?: dpi.c:382: warning: ignoring return value of ?fgets?, declared with attribute warn_unused_result dpi.c: In function ?a_Dpi_bye_dpid?: dpi.c:733: warning: ignoring return value of ?write?, declared with attribute warn_unused_result g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/include/libpng12 -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT styleengine.o -MD -MP -MF .deps/styleengine.Tpo -c -o styleengine.o styleengine.cc ../lout/misc.hh: In member function ?void StyleEngine::apply(dw::core::style::StyleAttrs*, CssPropertyList*)?: ../lout/misc.hh:181: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false -- Regards, Michal Nowak

March 27, 2009

google login redirect

by furaisanjin＠gmail.com

2009/3/27 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Just committed a patch for this. > ?Please test. I did login and logout several times and the redirect template showed correct link. This works. Regards, furaisanijn

March 26, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:44:49PM +0900, furaisanjin wrote: > Hi all. > > I have noticed that google login redirect is something like this. > > <meta http-equiv="refresh" content="0; url='http://www.google.com/ .....> > > So generated redirect template looks like > > <table width='100%'><tr><td bgcolor='#ee0000'>Warning:</td> > <td bgcolor='#8899aa' width='100%'> > This page uses the NON-STANDARD meta refresh tag.<br> The HTML 4.01 SPEC > (sec 7.4.4) recommends explicitly to avoid it.</td></tr> > <tr><td bgcolor='#a0a0a0' colspan='2'>The author wanted you to go > <a href=''http://www.google.com/ ... > > So dillo just navigates to the same page. This is the reason why we can't login. Just committed a patch for this. Please test. -- Cheers Jorge.-

March 26, 2009