- Dillo-dev - lists.mailman3.com

load_images and multiple windows

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 06, 2008 at 09:00:33PM +0200, Johannes Hofmann wrote: > > Should load_images be a per window variable, or should we update the > > buttons in all other windows? > > A per window setting looks OK to me. That way people that use > it only on certain pages (like me) are happy, and those that prefer > text mode most of the time can have load_images=NO in dillo2rc. I just put this together. I won't make much use of it, so please test.

Sept. 16, 2008

patch: scroll upon resize

by Johannes.Hofmann＠gmx.de

On Mon, Sep 15, 2008 at 06:54:02PM +0000, corvid wrote: > Johannes wrote: > > Yes, that's true. Quite a lot of code actually handles hiding and > > showing of the scrollbars and their influence on the size of the viewable > > area. > > I had proposed a quite radical patch some time ago that moved the > > scrollbars from the viewport to the gui (and thereby from dw2 to > > dillo2). > > This would eliminate all scrollbar related code from dw2. > > However as I'm not confident enough that I did not miss any subtle > > effects and the current code works fine I would keep things as they > > are for the release. > > I can update my patch and put it up for discussion after the > > release. > > It would at least be interesting to see how things are simplified. > > (Is ScrollGroup involved? I've wondered about it ever since I first > noticed it in fltk) No, it isn't. Scrolling is still be done separately. However, all the nasty stuff is hidden in fltk::scrollrect() already. The patch just makes the scrollbars part of the UI. Cheers, Johannes

Sept. 15, 2008

patch: scroll upon resize

by corvid＠lavabit.com

Johannes wrote: > Yes, that's true. Quite a lot of code actually handles hiding and > showing of the scrollbars and their influence on the size of the viewable > area. > I had proposed a quite radical patch some time ago that moved the > scrollbars from the viewport to the gui (and thereby from dw2 to > dillo2). > This would eliminate all scrollbar related code from dw2. > However as I'm not confident enough that I did not miss any subtle > effects and the current code works fine I would keep things as they > are for the release. > I can update my patch and put it up for discussion after the > release. It would at least be interesting to see how things are simplified. (Is ScrollGroup involved? I've wondered about it ever since I first noticed it in fltk)

Sept. 15, 2008

patch: scroll upon resize

by Johannes.Hofmann＠gmx.de

Hi, On Mon, Sep 15, 2008 at 02:57:27AM +0000, corvid wrote: > You know how > - you are scrolled down or to the right > - you make the viewport larger > - the scrollbar disappears > - you can only get the rest of the document back by hitting some > arrow keys or something Yes, I know... > > This seems to fix it, although my usual dw disclaimer applies: > I don't know whether this is necessarily the right place for > the change. I was thinking about something like this before. The only problem I see is with tiling window managers like e.g. dwm: With these windows often get resized, then resized back to their old size. Currently such a resize cycle does not change the scrolling position, which is quite nice. But as most people use ordinary window managers, I'd say we should commit this fix. Perhaps we will find something later that also keeps the scrolling position after resizing back to the original size. > > PS When making the viewport very narrow and then maximizing, I notice > that the location bar does not go back to showing the whole address. > I don't know whether that's dillo's fault or fltk's fault. > > PPS Amazing how much code we need for dealing with scrolling and scrollbars... Yes, that's true. Quite a lot of code actually handles hiding and showing of the scrollbars and their influence on the size of the viewable area. I had proposed a quite radical patch some time ago that moved the scrollbars from the viewport to the gui (and thereby from dw2 to dillo2). This would eliminate all scrollbar related code from dw2. However as I'm not confident enough that I did not miss any subtle effects and the current code works fine I would keep things as they are for the release. I can update my patch and put it up for discussion after the release. Cheers, Johannes

Sept. 15, 2008

[patch] findbar appearance

by Johannes.Hofmann＠gmx.de

Hi, attached path adjusts the findbar to match the appearance of the panel. Cheers, Johannes

Sept. 15, 2008

patch: scroll upon resize

by corvid＠lavabit.com

You know how - you are scrolled down or to the right - you make the viewport larger - the scrollbar disappears - you can only get the rest of the document back by hitting some arrow keys or something This seems to fix it, although my usual dw disclaimer applies: I don't know whether this is necessarily the right place for the change. PS When making the viewport very narrow and then maximizing, I notice that the location bar does not go back to showing the whole address. I don't know whether that's dillo's fault or fltk's fault. PPS Amazing how much code we need for dealing with scrolling and scrollbars...

Sept. 15, 2008

patch: small mem leaks

by corvid＠lavabit.com

Jeremy kindly provided the memory checking output that went with the valgrind logs from the other day. (I knew about the FullScreen one, but might as well comment it out until someone hooks it up.)

Sept. 13, 2008

More Cache memory corruption

by jcid＠dillo.org

On Thu, Sep 11, 2008 at 10:31:37PM +0000, corvid wrote: > Jeremy wrote: > > Now the bad news: this HTML almost invariably crashes Dillo: > > > > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > <html xmlns="http://www.w3.org/1999/xhtml"> > > <head> > > <meta > > http-equiv="Content-Type" > > content="application/xhtml+xml; charset=iso-8859-1" > > /> > > </head> > > <body> > > </body> > > </html> > > > > The culprit is the <meta...> tag. Dillo always crashes in one of two > > ways: segmentation fault or glibc detecting memory corruption and > > aborting. In each case the backtrace from gdb is the same (verified > > by running Dillo 100 times (it only failed to crash twice)). The > > backtraces show that the Cache_* functions are freeing things they > > should not. Valgrind confirms this. I'm attaching backtraces and a > > valgrind log. > > That's not bad news. Getting to fix a bug is a good thing. > Try the attached patch. > > Meta causes a repush, which eventually finds its way to > Cache_delayed_process_queue_callback(). In Cache_process_queue(), the fact > that the content type is not viewable causes an abort and the cache entry > is removed. This is bad for my subsequent Cache_unref_data(entry). > (The entries currently have reference counting so that I know when I can > get rid of the UTF8-ized data.) > > > If you put some text above the meta tag, you still have some text visible > that you can right-click to pop up the page menu. Trying the menu options > doesn't crash anything, but...hmmm...are there are implications to not > having a cache entry backing the page? Hmm, that needs to be investigated... I'll hold the patch a bit just in case you find something. -- Cheers Jorge.-

Sept. 12, 2008

[PATCH] Missing include directive for OpenBSD?

by jcid＠dillo.org

On Fri, Sep 12, 2008 at 08:39:10AM +0200, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080908 17:18]: > > > > Yes, in dillo2's tree src/colors.h has a check that OpenBSD 4.3 > > is happy with. Please test it. > > Ok, so I duplicated this check to the dw2 tree and rebuild. I can > confirm that this works for OpenBSD 4.3. Committed. -- Cheers Jorge.-

Sept. 12, 2008

More Cache memory corruption

by onepoint＠starurchin.org

On Thu, Sep 11, 2008 at 10:31:37PM +0000, corvid wrote: > Try the attached patch. That fixes it. Thanks! I'm afraid I don't have any answers to your questions: I'm not familiar enough with the cache code. Regards, Jeremy Henty

Sept. 12, 2008