- Dillo-dev - lists.mailman3.com

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sun, Feb 15, 2009 at 09:17:09AM -0300, Jorge Arellano Cid wrote: > But, I miss the URL to reproduce the BUG. That's what I meant in > the previous email; please excuse me if it wasn't clear. Oh, I see. Unfortunately I don't have that information, the code just parses the output of Valgrind. When an error occurs there is no indication which of the current pages produced it. Worse, valgrind only reports leaks after the program exits. I haven't been able to find a specific example that reproduces any of these problems. I strongly suspect that the errors we are seeing now are non-deterministic and come from race-like conditions between different pages. Every time I run dillo on a single page the valgrind report is clean. Maybe there's some deep valgrind magic that would yield more information, but if so I don't know of it. Any ideas? Regards, Jeremy Henty

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 11:15:34PM +0000, corvid wrote: > Johannes wrote: > > On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote: > > > Johannes wrote: > > > > > > > [paste] > > > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > > > > What is it doing wrong? > > > > > > > > > > > > > > > > I have set these values in dillorc: > > > > > > > > font_min_size=10 > > > > > > > > font_max_size=12 > > > > > > > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > > > > > > > My style.css looks like this: > > > > > > > > > > > > > > > > * { > > > > > > > > font-family: ProFont !important; > > > > > > > > font-size: 9pt; > > > > > > > > } > > > > > > > > > > > > > > > > body { > > > > > > > > background-color: white !important; > > > > > > > > } > > > > > > > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > > > > selected the specific range in this screenshot: > > > > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > > > > When having disabled the style.css, the font sizes are the same as > > > > > > before. > > > > > > > > I think this is some sort of weirdness with either ProFont, fltk or > > > > both in combination. > > > > I can't get ProFont working at all. It only shows 1px high lines. > > > > Can you confirm that the font_min_size works properly with > > > > non-bitmap fonts? > > > > Regarding font_max_size I wasn't sure whether we want another option > > > > or should just set a reasonable fixed upper limit. > > > > But now that someone even made a patch for font_max_size it seems a > > > > good idea to have an option... > > > > > > When I quickly tried font_min_size of 30 and > > > nothing about fonts in my style.css, > > > I saw regular-sized fonts as well. > > > (I'd never even heard of ProFont.) > > > > Ah now I see. The check only happened when the font-size was > > _changed_ > > Please try attached patch. > > It appears to work for me. Committed. Thanks, Johannes

Feb. 16, 2009

Repush and scroll position

by Johannes.Hofmann＠gmx.de

On Thu, Feb 12, 2009 at 05:43:08PM -0300, Jorge Arellano Cid wrote: > On Thu, Feb 12, 2009 at 03:12:10PM +0100, Hofmann Johannes wrote: > > On Thu, Feb 12, 2009 at 02:12:36PM +0000, Jeremy Henty wrote: > > > On Wed, Feb 11, 2009 at 05:06:55PM -0300, Jorge Arellano Cid wrote: > > > > > > > Patch b134ea74331b is to make repush remmeber the scrolling > > > > position. This is, if you load a page, start scrolling and the > > > > stylesheet arrives after that, it will no longer go back to the > > > > top. > > > > > > > > Please test. > > > > > > Works for me with Slashdot. Very nice! > > > > Yes, works great. > > > > One minor thing, which also happens when going back/forward: > > > > It seems that the page is first drawn with scroll position 0 and then > > immediately scrolled down to the remembered scroll position. > > Any ideas where the first redraw comes from? Maybe we can eliminate > > that? > > I thought that with the implementation of cancelQueueDraw(), > and the respective call from scrollTo() it would work, but I was > wrong. > > The attached patch implements cancelQueueDraw() and adds some > debugging messages that show interesting facts: > > Nav_open_url: new url='dpi:/bm/' > FltkViewBase::cancelQueueDraw() > Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw > FltkViewBase::cancelQueueDraw() > FltkViewBase::cancelQueueDraw() > FltkViewBase::draw > Nav_open_url: new url='http://localhost/htdocs/redraw.html' > FltkViewBase::cancelQueueDraw() > Layout::scrollTo0 __NOT__ calling view->cancelQueueDraw > FltkViewBase::cancelQueueDraw() > FltkViewBase::cancelQueueDraw() > FltkViewBase::draw > FltkViewBase::draw > FltkViewBase::draw > FltkViewBase::draw > > 1.- There's no need for an explicit call to cancelQueueDraw() > from Layout::scrollTo0(). It happens anyway. > 2.- For bookmarks there's just one draw() call. > 3.- For coming back to a scrolled page, there're four calls!!! > 4.- I'm using a test page with no repush(): > > <html><body><img src="image1.png"> > <ul><li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > <li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1<li>1 > </ul></body></html> > > This could take some time, so I'm handing it back to you now... It seems that the problem comes from the fact that we scroll to a position that is not valid at the time we do the scrolling (when the page is still empty). In that case Layout::adjustScrollPos() changes the remembered scroll position to 0,0. Only later we scroll to the desired position. This also has to do with how idle functions are handled. Attached patch seems to fix this problem, but I'm not yet proposing it for inclusion, as I don't understand the details. If anyone want's to take a look - please go ahead! Cheers, Johannes

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Johannes wrote: > On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote: > > Johannes wrote: > > > > > [paste] > > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > > > What is it doing wrong? > > > > > > > > > > > > > > I have set these values in dillorc: > > > > > > > font_min_size=10 > > > > > > > font_max_size=12 > > > > > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > > > > > My style.css looks like this: > > > > > > > > > > > > > > * { > > > > > > > font-family: ProFont !important; > > > > > > > font-size: 9pt; > > > > > > > } > > > > > > > > > > > > > > body { > > > > > > > background-color: white !important; > > > > > > > } > > > > > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > > > selected the specific range in this screenshot: > > > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > > > When having disabled the style.css, the font sizes are the same as > > > > > before. > > > > > > I think this is some sort of weirdness with either ProFont, fltk or > > > both in combination. > > > I can't get ProFont working at all. It only shows 1px high lines. > > > Can you confirm that the font_min_size works properly with > > > non-bitmap fonts? > > > Regarding font_max_size I wasn't sure whether we want another option > > > or should just set a reasonable fixed upper limit. > > > But now that someone even made a patch for font_max_size it seems a > > > good idea to have an option... > > > > When I quickly tried font_min_size of 30 and > > nothing about fonts in my style.css, > > I saw regular-sized fonts as well. > > (I'd never even heard of ProFont.) > > Ah now I see. The check only happened when the font-size was > _changed_ > Please try attached patch. It appears to work for me.

Feb. 16, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > summary: Fixed handling of META's content-type with no MIME type > (e.g. only charset). Is that legal? It doesn't sound legal.

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 09:13:50PM +0000, corvid wrote: > Johannes wrote: > > > [paste] > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > > What is it doing wrong? > > > > > > > > > > > > I have set these values in dillorc: > > > > > > font_min_size=10 > > > > > > font_max_size=12 > > > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > > > My style.css looks like this: > > > > > > > > > > > > * { > > > > > > font-family: ProFont !important; > > > > > > font-size: 9pt; > > > > > > } > > > > > > > > > > > > body { > > > > > > background-color: white !important; > > > > > > } > > > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > > selected the specific range in this screenshot: > > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > > When having disabled the style.css, the font sizes are the same as > > > > before. > > > > I think this is some sort of weirdness with either ProFont, fltk or > > both in combination. > > I can't get ProFont working at all. It only shows 1px high lines. > > Can you confirm that the font_min_size works properly with > > non-bitmap fonts? > > Regarding font_max_size I wasn't sure whether we want another option > > or should just set a reasonable fixed upper limit. > > But now that someone even made a patch for font_max_size it seems a > > good idea to have an option... > > When I quickly tried font_min_size of 30 and > nothing about fonts in my style.css, > I saw regular-sized fonts as well. > (I'd never even heard of ProFont.) Ah now I see. The check only happened when the font-size was _changed_ Please try attached patch. Cheers, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Johannes wrote: > [paste] > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > > while having set font-size for * in style.css. > > > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > > What is it doing wrong? > > > > > > > > > > I have set these values in dillorc: > > > > > font_min_size=10 > > > > > font_max_size=12 > > > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > > > My style.css looks like this: > > > > > > > > > > * { > > > > > font-family: ProFont !important; > > > > > font-size: 9pt; > > > > > } > > > > > > > > > > body { > > > > > background-color: white !important; > > > > > } > > > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > > selected the specific range in this screenshot: > > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > > > Any ideas on how to fix this? > > > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > > > > That is possible, but setting font_min_size and font_max_size > > > to a higher value (e.g. 50 and 100) does not fix this issue. > > > When having disabled the style.css, the font sizes are the same as > > > before. > > I think this is some sort of weirdness with either ProFont, fltk or > both in combination. > I can't get ProFont working at all. It only shows 1px high lines. > Can you confirm that the font_min_size works properly with > non-bitmap fonts? > Regarding font_max_size I wasn't sure whether we want another option > or should just set a reasonable fixed upper limit. > But now that someone even made a patch for font_max_size it seems a > good idea to have an option... When I quickly tried font_min_size of 30 and nothing about fonts in my style.css, I saw regular-sized fonts as well. (I'd never even heard of ProFont.)

Feb. 15, 2009

My valgrind logs, for all to see.

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 02:14:53AM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 07:04:21PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > > > Would having a single page with anchors for each link be enough, > > > or do you want separate pages for each one? > > > > A single page seems easier. > > Actually, I've gone for a summary page with links to a separate page > for each error. I've put some information from the stack traces into > the link texts. I think it works rather well, eg. you can clearly see > that most of the errors are coming from CSS handling (and some of > those leaks are not as small as I thought). Please comment. > > http://starurchin.org/dillo/valgrind.html I just committed two fixes for CSS related leaks. Not sure if that's all. Regards, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 07:16:55PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > > I was just looking at some of the prefs that I > > > > > > > don't think are doing anything right now, e.g., > > > > > > > link_color, force_my_colors... > > > > > > > I could stuff them into buildUserStyle(), but > > > > > > > I don't know which should prevail in case of > > > > > > > conflicts. > > > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > > I've been wondering whether it might be reasonable to > > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > > a dillo user to be able to deal with a well-commented > > > > > > > sample style.css instead. > > > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > > just adds confusion. We need to document this properly as you > > > > > > said. > > > > > > > > > > If I have a style.css containing: > > > > > > > > > > * {font-size: 30px} > > > > > > > > > > and a page containing: > > > > > > > > > > regular regular large > > > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > > > Sorry, I think I don't fully understand the question. > > > > > > > > * {font-size: 30px !important} > > > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > > it. What am I missing? > > > > > > If I do this, it doesn't use 30px until the first tag it sees. > > > > BTW, there's BUG#892 (prefs' bg_color is not working). > > Speaking of which, the submitter tells me that font_min_size > doesn't work sometimes. Pasted in: > > > > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > > There is also a problem with the lately introduced font_min_size > > > > > > while having set font-size for * in style.css. > > > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > > What is it doing wrong? > > > > > > > > I have set these values in dillorc: > > > > font_min_size=10 > > > > font_max_size=12 > > > > > > > > For font_max_size, I used the attached patch. > > > > > > > > My style.css looks like this: > > > > > > > > * { > > > > font-family: ProFont !important; > > > > font-size: 9pt; > > > > } > > > > > > > > body { > > > > background-color: white !important; > > > > } > > > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > > selected the specific range in this screenshot: > > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > > > Any ideas on how to fix this? > > > > > > Ah, I believe font_min_size is in pixels. > > > > > > > That is possible, but setting font_min_size and font_max_size > > to a higher value (e.g. 50 and 100) does not fix this issue. > > When having disabled the style.css, the font sizes are the same as > > before. I think this is some sort of weirdness with either ProFont, fltk or both in combination. I can't get ProFont working at all. It only shows 1px high lines. Can you confirm that the font_min_size works properly with non-bitmap fonts? Regarding font_max_size I wasn't sure whether we want another option or should just set a reasonable fixed upper limit. But now that someone even made a patch for font_max_size it seems a good idea to have an option... Cheers, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Jorge wrote: > On Sun, Feb 15, 2009 at 05:07:28PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Feb 14, 2009 at 04:07:15PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sun, Feb 01, 2009 at 07:20:33PM +0000, corvid wrote: > > > > > > I was just looking at some of the prefs that I > > > > > > don't think are doing anything right now, e.g., > > > > > > link_color, force_my_colors... > > > > > > I could stuff them into buildUserStyle(), but > > > > > > I don't know which should prevail in case of > > > > > > conflicts. > > > > > > > > > > > > I can't remember whether I've already mentioned that > > > > > > I've been wondering whether it might be reasonable to > > > > > > rip a bunch of color stuff out of dillorc and expect > > > > > > a dillo user to be able to deal with a well-commented > > > > > > sample style.css instead. > > > > > > > > > > Good point. I always favor simplicity so I think we should have just > > > > > one way to modify the style. Having two (style.css and preferences) > > > > > just adds confusion. We need to document this properly as you > > > > > said. > > > > > > > > If I have a style.css containing: > > > > > > > > * {font-size: 30px} > > > > > > > > and a page containing: > > > > > > > > regular regular large > > > > > > > > Can it be interpreted as "make everything big"? > > > > > > Sorry, I think I don't fully understand the question. > > > > > > * {font-size: 30px !important} > > > > > > would set a fixed font size of 30px. The itself doesn't alter > > > it. What am I missing? > > > > If I do this, it doesn't use 30px until the first tag it sees. > > BTW, there's BUG#892 (prefs' bg_color is not working). Speaking of which, the submitter tells me that font_min_size doesn't work sometimes. Pasted in: > On Fr, 13 Feb 2009 20:33, corvid wrote: > > > > > There is also a problem with the lately introduced font_min_size > > > > > while having set font-size for * in style.css. > > > > > > > > I just gave it a try and it seemed to be working for me. > > > > What is it doing wrong? > > > > > > I have set these values in dillorc: > > > font_min_size=10 > > > font_max_size=12 > > > > > > For font_max_size, I used the attached patch. > > > > > > My style.css looks like this: > > > > > > * { > > > font-family: ProFont !important; > > > font-size: 9pt; > > > } > > > > > > body { > > > background-color: white !important; > > > } > > > > > > Now every font size is supposed to be between 10pt and 12pt (the > > > font-size: 9pt should be overwritten by font_min_size). But if I now > > > visit heise.de, there is text which is even smaller than 9pt. I have > > > selected the specific range in this screenshot: > > > http://img5.imageshack.us/img5/1082/200902131918591280x800sok3.png > > > > > > Any ideas on how to fix this? > > > > Ah, I believe font_min_size is in pixels. > > > > That is possible, but setting font_min_size and font_max_size > to a higher value (e.g. 50 and 100) does not fix this issue. > When having disabled the style.css, the font sizes are the same as > before.

Feb. 15, 2009