- Dillo-dev - lists.mailman3.com

bookmark dpi - cleanups
by 4winter＠informatik.uni-hamburg.de March 24, 2009

March 24, 2009

Skipped content of type multipart/mixed

2 1

bug tracker doesn't work with dillo?
by dillo-dev＠toykeeper.net March 24, 2009

March 24, 2009

I went to add a bug to the database today and found that it always returns errors when I attempt to file bugs using dillo. I ended up having to use firefox instead. The specific error is: Request Entity Too Large The requested resource /cgi-bin/bugtrack/Dillo_insert.cgi does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit. I checked with 'wc' and the data wasn't even half the limit. So, dillo is behaving somehow incorrectly. I'm writing here about it instead of filing a new bug because even the short description above is twice as big as the bug tracker allows... and it has no facilities for discussion or notification. -- Scott

2 7

compiling error on FreeBSD 6.4
by furaisanjin＠gmail.com March 24, 2009

March 24, 2009

Hi all. I got compiling error on FreeBSD 6.4. I pulled and updated this morning and then got this error. gmake[3]: Entering directory `/tmp/disk1/src/css/dillo/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I.. -I/usr/local/include/libpng -O2 -fno-strict-aliasing -pipe -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/X11R6/include -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT web.o -MD -MP -MF ".deps/web.Tpo" -c -o web.o web.cc; \ then mv -f ".deps/web.Tpo" ".deps/web.Po"; else rm -f ".deps/web.Tpo"; exit 1; fi In file included from styleengine.hh:7, from web.cc:25: cssparser.hh:27: error: expected unqualified-id before '!' token cssparser.hh:27: error: expected `)' before '!' token gmake[3]: *** [web.o] Error 1 gmake[3]: Leaving directory `/tmp/disk1/src/css/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/tmp/disk1/src/css/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/tmp/disk1/src/css/dillo' gmake: *** [all] Error 2 I have no idea when this happned. Regards, furaisanjin

2 3

[bug]: more CSS margin problems
by onepoint＠starurchin.org March 24, 2009

March 24, 2009

This looks like a horizontal version of the previous problem I reported. The online example is http://rest-client.heroku.com/rdoc/fr_class_index.html The text that sticks out of the left of the coloured area is dead: you can't select it or click it, and if you drag another window over it slowly from from left to right then it doesn't redisplay properly. Minimal example attached. Regards, Jeremy Henty

2 4

http authentication: shred passwords
by 4winter＠informatik.uni-hamburg.de March 22, 2009

March 22, 2009

Skipped content of type multipart/mixed

2 1

[bug]: CSS strangeness: disappearing text
by onepoint＠starurchin.org March 20, 2009

March 20, 2009

Something funny is happening with this URL http://marcofrasca.wordpress.com/2009/03/18/updated-paper/ In Dillo, all of the first paragraph except for the last line has disappeared. Also, if you click and drag around that line you can make it disappear too. It reappears as soon as you drag the window anywhere. I have stripped this down to a minimal example (attached). Both lines of the style file have to be present to get the effect. Interestingly, in Firefox this example also only shows the bottom line of the paragraph, but it puts it right at the top of the screen. So it looks as though Dillo sort of understands that most of the paragraph is invisible, but does not put it in the right place? Regards, Jeremy Henty

2 1

[patch]: fix compiler warning in CustShrinkTabPager
by onepoint＠starurchin.org March 19, 2009

March 19, 2009

The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual. This patch adds the virtual destructor and stops the warning. NB: there may be a case for rejecting this patch if we're really concerned about the performance of virtual functions (one extra indirection per call). FLTK deliberately avoids virtual destructors whenever possible for just this reason. I seriously doubt that this patch makes any impact on Dillo, but that's just IMHO. Regards, Jeremy Henty

2 2

Re: Approval
by jcid＠dillo.org March 19, 2009

March 19, 2009

Hi, On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote: > Hi Jorge, > > > Please send it to me and I'll send you a dillo.org based URL > > so you can refer to it. > > Unfortunately I had already deleted the mail but here are some > information from my maildrop log that might be useful for you: > > Date: Mon Mar 9 17:00:12 2009 > From: dillo-dev-bounces(a)dillo.org > Subj: Your message to Dillo-dev awaits moderator approval > Size: 1902 Message found and approved. > By the way, I think I have found three bugs in Dillo. Whenever I > visit the site https://oss.gonicus.de/labs/gosa/wiki, it asks me > whether I want to accept the certificate about 10 times (probably > for each picture and CSS file). A way to solve it would be to > remember the selection for all links on this page but this could > become to a big security risk as people could misuse this behaviour > for phishing sites. This is BUG#868 in the tracker. The solution is to turn the https dpi into a server (it's a filter now). This is not complex but takes time. I don't want to delay the next release even more so most probably it will be in the release after dillo-2.1. > The other bug appears on http://urldecode.info/ where no pictures > are displayed. My vague assumption is that Dillo cannot handle > images whose headers contain a "Location" header. Dillo just checks > whether the Content-Length header contains anything (this is why it > works for 0). It seems to me that Dillo downloads the picture > properly but does not show it because it thinks the size is supposed > to be 0. Yes, historically dillo doesn't follow image redirections. Over time this has helped to reduce advertising (most image redirections are advertising). > [...] > A possible solution would be to overwrite all headers by the ones > from the redirected URL ("Location" header). Or would it be better > to delete all available headers when a "Location" headers was found? For "root" URLs, redirection is working, the same/similar method my be re-used for images. The point is whether it's desirable to do it. For instance, with a load_remote_images pref, it would work, but lot's of advertising would pass too. When disabled, sites as the one you cite won't work. If we let the user toggle this pref from "Tools" it would feel clumsy to do it for a favorite site. Now, we may solve all this with URL filtering. Let's say filtering has higher priority, and we have "allow" and "deny" options (just think of hosts not RE by now to discard performance issues). In the above described case I'd choose to set: allow file content = urldecode.info load_image_redirections = NO meaning that when visiting urldecode.info, remote image redirections will be loaded. The API should allow setting this automatically from the tools menu (e.g. "allow remote images" option with a short dialog: Do you want to enable remote image loading permanently for site xxx.yyy.zzz? [Allow] [Cancel]) URL filtering based on regular expressions is expensive in CPU terms, that's why I like the idea of HOST-based filtering. With it you can deny as a general rule and have some allow exceptions. (BTW, as a last resource if all this is not enough, RE support may be added on top). > The third issue (which only occurs in the Hg tree) looks like a > timing bug. When visiting http://www.golem.de/0903/65726.html not > all of the pictures are shown but when reloading the page, they are. > Interestingly, it works perfectly if I save the page to disk and > then view it manually in Dillo. This needs some ivestigation... > When is the final version planned to be released? I'll have more time in April, so probably April. > In my opinion we > should wait a few weeks because Dillo crashes regularly on my > machines (always running the trunk version). This is strange, I very seldom get a dillo crash. Can you post example URLs, more details of your OS/FLTK-version/settings? > Therefore a release > candidate every two would be useful for the users to give feedback > and to report further bugs. After all of the major bugs have been > fixed, we could announce the final version. That's the idea. > Is it planned to include > the key bindings patch into this version? This should not be a big > deal for the users as the configuration files are backward > compatible. No, it's not planned. Now if the patch is simple, clean and straightforward and I can review it before rc1, and behaves well in testing, then it may go in. > What really annoys me is that when Dillo crashes, the CPU usage > climbs onto 100%. The only way I can fix this is to kill all > Dillo-related processes. This way, I lose my tabs. A session-saver > like in Mozilla Firefox would be a useful feature but I am not sure > whether it is worth the "bloatage". AFAIS, one of the main features of Dillo is its stability, so please give us more information on this. > PS: What is the accurate way to find those memory leaks? I remember > Jeremy speaking about Valgrind which he used to create his "crash > reports". Valgrind is cetainly a great tool for the job. -- Cheers Jorge.-

2 1

[patch]: remove the BW_* flags
by onepoint＠starurchin.org March 19, 2009

March 19, 2009

a_Bw_stop_clients() is always called with the BW_Root and BW_Img flags set, so we can remove those flags. That leaves only the BW_Force flag, so we can remove that too and change the flags argument to a boolean that indicates whether to force. Regards, Jeremy Henty

3 6

[patch]: fix comment for DLWin::del()
by onepoint＠starurchin.org March 18, 2009

March 18, 2009

The comment for DLWin::del() was copied and pasted from DLWin::new(), but never corrected! Regards, Jeremy Henty

2 2