- Dillo-dev - lists.mailman3.com

Leaking image structures

by Johannes.Hofmann＠gmx.de

On Wed, Feb 04, 2009 at 02:47:51PM +0000, Jeremy Henty wrote: > > One of the biggest leaks that valgrind reports is image structures. > I'm attaching logs that show memory being allocated by a_Png_new() and > cousins and not being freed. There are also frequent leaks of memory > allocated by the image libraries from within the various image > callbacks, but I suspect these are just another effect of the Dillo > image structures not being freed. > > Unfortunately I'm having a hard time tracking these leaks down. They > regularly appear after long browsing sessions, but I haven't found any > single page that reproduces them. I suspect they are caused by some > race condition inside the CCC rather than the HTML parser. I am > browsing with image loading enabled, and if I understand the code > correctly that means that the Web structures in the CCC own all the > references to image structures. > > The fact that image structures are reference counted makes it hard to > know when the structures should be freed anyway. Indeed, does Dillo > even ensure that image structures are freed? Maybe this is just a > symptom of incomplete cleanup at exit rather than a true leak? > > I've looked over the code and can't see any obvious leaks so I'm > rather stuck. Any tips for tracking this down? Even if it's not a > true leak it would be good to have a fix that cleaned up the valgrind > logs. I guess there is a leak when image loading is off. In that case images are not put in the html->images list and therefore not unrefed when leaving the page. Can you please try attached patch with valgrind and image loading on and off. Regards, Johannes

Feb. 17, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Tue, Feb 17, 2009 at 05:54:17PM +0000, Jeremy Henty wrote: > On Tue, Feb 17, 2009 at 06:40:01PM +0100, Joerg Sonnenberger wrote: > > > Please ensure that this is not part of releases and/or if the .hg > > directory is missing. > > It already does this. If you are not in a Mercurial repository (or if > Mercurial is not installed) then the "if hg id ..." test fails and HG > is #defined to 0 instead of 1. The extra logging code is wrapped in a > "#if HG" so it will be removed by the preprocessor. I just tested > this by temporarily renaming .hg and rebuilding and it worked as > intended. Point is, release build should never differ whether hg is installed or not. I know that hg does the check internally, but that also depends on that no other hg binary can be found. Joerg

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 06:40:01PM +0100, Joerg Sonnenberger wrote: > Please ensure that this is not part of releases and/or if the .hg > directory is missing. It already does this. If you are not in a Mercurial repository (or if Mercurial is not installed) then the "if hg id ..." test fails and HG is #defined to 0 instead of 1. The extra logging code is wrapped in a "#if HG" so it will be removed by the preprocessor. I just tested this by temporarily renaming .hg and rebuilding and it worked as intended. Regards, Jeremy Henty

Feb. 17, 2009

Fun with autocnf and mercurial

by joerg.sonnenberger＠web.de

On Tue, Feb 17, 2009 at 05:26:36PM +0000, Jeremy Henty wrote: > Yes, that's much better. Revised patch attached. Please ensure that this is not part of releases and/or if the .hg directory is missing. Joerg

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

On Tue, Feb 17, 2009 at 05:26:29PM +0100, Hofmann Johannes wrote: > I like the idea, but wouldn't something like "hg id" be more > appropriate? It shows the current revision which is not necessarily > tip. Yes, that's much better. Revised patch attached. Regards, Jeremy Henty

Feb. 17, 2009

Fun with autocnf and mercurial

by Johannes.Hofmann＠gmx.de

On Mon, Feb 16, 2009 at 11:09:21PM +0000, Jeremy Henty wrote: > > Here's a patch for discussion. Since I am parsing Dillo logs for > debugging, I thought it would be neat if Dillo logged the mercurial > revision. Patch attached. > > Thoughts? Does anyone know a better way to get the revision for a > particular tag? Piping "hg tags" through a sed script is rather > kludgy but I can't find a way to get mercurial to tell me directly. I like the idea, but wouldn't something like "hg id" be more appropriate? It shows the current revision which is not necessarily tip. Cheers, Johannes

Feb. 17, 2009

Leaking image structures

by corvid＠lavabit.com

I wrote: > Probably not related, but occasionally progressive jpegs > haven't been displaying some of the later scans. It does this when the image is being scaled.

Feb. 17, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > I also want to maybe re-use this widget for the XHTML parsing > dilemma. This is: to render or not to render XHTML. Last time I > read the specs, XHTML must be validated and not rendered when not > valid. In practice, when facing non-valid XHTML, Firefox renders > it and doesn't even warn. If we render, and warn, and show the > BUGs found in the bug-meter, we'd be closer to the original idea. From a little reading, I get the impression that it has to be well-formed in an xml sense to be rendered, but you can have HTMLish errors like, oh, putting random things in <select> and still render it.

Feb. 17, 2009

Fun with autocnf and mercurial

by onepoint＠starurchin.org

Here's a patch for discussion. Since I am parsing Dillo logs for debugging, I thought it would be neat if Dillo logged the mercurial revision. Patch attached. Thoughts? Does anyone know a better way to get the revision for a particular tag? Piping "hg tags" through a sed script is rather kludgy but I can't find a way to get mercurial to tell me directly. I log the qparent revision as well as the tip revision because I manage patches with Mercurial queues, so my qparent revision is the vanilla tip revision that I am currently based on. Also, I used printf() to log the revisions because neither MSG nor MSG_WARN produced anything. I don't know why. Can anyone explain? Regards, Jeremy Henty

Feb. 17, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > Don't worry man. This is more or less cooked. > > From the link suggested by Rogut?s Sparnuotos: > > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html > > I got to: > > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H76.html > > which is a W3C's page with an example that uses quotes. Ergo, > we will support it. Not parsing the major/minor part because the quotes confused us, though? The type could differ -- I remember that crash Jeremy found where meta changed it to application/xhtml+xml...

Feb. 16, 2009

META charset without MIME type

by jcid＠dillo.org

On Mon, Feb 16, 2009 at 07:41:05PM +0000, corvid wrote: > I wrote: > > Jorge wrote: > > > On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > > > > 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. > > > > > > Verbatim from HTML-4.01 SPEC: > > > > > > META: > > > [...] > > > content = cdata [CS] > > > > > > This attribute specifies a property's value. This specification > > > does not list legal values for this attribute. > > > > Right, MIME types are specified elsewhere and not here in the HTML spec. > > > > I imagine this has to do with furaisanjin's "'", and a quick look into > > the spec suggests that should be getting turned into a "'" if it's an > > attr. I'll see if I can find what's going on there. > > furaisanjin's was inside an attribute, and the content type one delimits > an attribute. So the spec says > > By default, SGML requires that all attribute values be delimited using > either double quotation marks (ASCII decimal 34) or single quotation > marks (ASCII decimal 39). Single quote marks can be included within > the attribute value when the value is delimited by double quote marks, > and vice versa. Authors may also use numeric character references to > represent double quotes (") and single quotes ('). > > And the question is whether that last sentence is talking about > attribute delimiters, attribute values, or both. I don't know! > It looks like a person would have to make the questionable decision > to digest the super-mega-horror that is SGML in order to find out. Don't worry man. This is more or less cooked. From the link suggested by Rogut?s Sparnuotos: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html I got to: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H76.html which is a W3C's page with an example that uses quotes. Ergo, we will support it. Currently I'm in the process of implementing the "instant client-side redirect" thing, and also want to replace the custom HTML that's injected into the page (the META refresh warning) with a widget (most probably inside the control panel, hidden when not needed). I also want to maybe re-use this widget for the XHTML parsing dilemma. This is: to render or not to render XHTML. Last time I read the specs, XHTML must be validated and not rendered when not valid. In practice, when facing non-valid XHTML, Firefox renders it and doesn't even warn. If we render, and warn, and show the BUGs found in the bug-meter, we'd be closer to the original idea. Comments? -- Cheers Jorge.-

Feb. 16, 2009

META charset without MIME type

by corvid＠lavabit.com

I wrote: > Jorge wrote: > > On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > > > 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. > > > > Verbatim from HTML-4.01 SPEC: > > > > META: > > [...] > > content = cdata [CS] > > > > This attribute specifies a property's value. This specification > > does not list legal values for this attribute. > > Right, MIME types are specified elsewhere and not here in the HTML spec. > > I imagine this has to do with furaisanjin's "'", and a quick look into > the spec suggests that should be getting turned into a "'" if it's an > attr. I'll see if I can find what's going on there. furaisanjin's was inside an attribute, and the content type one delimits an attribute. So the spec says By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa. Authors may also use numeric character references to represent double quotes (") and single quotes ('). And the question is whether that last sentence is talking about attribute delimiters, attribute values, or both. I don't know! It looks like a person would have to make the questionable decision to digest the super-mega-horror that is SGML in order to find out.

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

Jorge wrote: > Now, if we're to put them in CSS, we must provide > well-commented sample stylesheets, and also give some directions > in the FAQ. It should be simple for the user to know how to set > his own stylesheet options without previous CSS knowledge, and > also how to disable the remote CSS when a page doesn't look good. > > It'd be great to specify, for instance, a "reading" stylesheet > (for low contrast and highcontrast) from our website and to let > the user tweak it. Then when he gets to a long page that he wants > to read (not just skim), he could disable remote CSS and use the > one he prefers. Some days ago, I started trying to put together a sample style sheet (attached). I got as far as putting in the things that I would find valuable to know, but I _have_ been exposed to CSS a bit in recent months, so it was hard to see how much would have to be spelled out to an intelligent layman and how much would be obvious from context and insulting to spell out. So I...I got stuck. (Strays from topic a bit: The world is filled with things aimed toward experts and filled with things aimed toward ignorant people who can be kept ignorant and separated from their money, but the intelligent layman does not have his needs met.)

Feb. 16, 2009

META charset without MIME type

by corvid＠lavabit.com

Jorge wrote: > On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > > 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. > > Verbatim from HTML-4.01 SPEC: > > META: > [...] > content = cdata [CS] > > This attribute specifies a property's value. This specification > does not list legal values for this attribute. Right, MIME types are specified elsewhere and not here in the HTML spec. I imagine this has to do with furaisanjin's "'", and a quick look into the spec suggests that should be getting turned into a "'" if it's an attr. I'll see if I can find what's going on there. PS I was just recently trying to figure out exactly whether quoted attributes can contain '<' or '>', and it's amazing how hard it can be to get a straight answer from the spec sometimes. (I think quite possibly so, but they started talking about CDATA for the content of script and style tags in a way that made the whole thing sort of unclear to me.)

Feb. 16, 2009

ChangeLog link

by jcid＠dillo.org

Hi, Does anybody know how to ask hgweb for the "tip" ChangeLog file? (The current link is set to a specific version). -- Cheers Jorge.-

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Mon, Feb 16, 2009 at 09:48:23AM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote: > > On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid 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). > > > > Jorge, what do you think about this? Can we go the style.css > > way and remove all dillorc options for stuff that can also be done > > with style.css? > > I'm very happy with the latest patches on font size, it's very > important: > > http://www.useit.com/alertbox/designmistakes.html > > Reading that page is assuring. We're providing the necessary > controls for people expressing their need for them! > > WRT your question, yes, it'd be good to go the CSS way, but > also to keep it simple for a non-CSS-savvy user to set. This is, > maybe font_{min_size, max_size, factor} are well placed in > dillorc. For text background and color, linkcolor, visited > linkcolor they seem to belong in CSS. Exactly. font_{min_size, max_size, factor} can't be expressed in CSS, so they must stay in dillorc. Whatever can be expressed in CSS should be done in style.css. > > Now, if we're to put them in CSS, we must provide > well-commented sample stylesheets, and also give some directions > in the FAQ. It should be simple for the user to know how to set > his own stylesheet options without previous CSS knowledge, and > also how to disable the remote CSS when a page doesn't look good. > > It'd be great to specify, for instance, a "reading" stylesheet > (for low contrast and highcontrast) from our website and to let > the user tweak it. Then when he gets to a long page that he wants > to read (not just skim), he could disable remote CSS and use the > one he prefers. As you say, it's mostly a question of documentation. Cheers, Johannes > > A few days ago I got to read the above link and relized the > actual relevance of this issue. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 16, 2009

META charset without MIME type

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 11:11:59PM +0000, corvid wrote: > 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. Verbatim from HTML-4.01 SPEC: META: [...] content = cdata [CS] This attribute specifies a property's value. This specification does not list legal values for this attribute. -- Cheers Jorge.-

Feb. 16, 2009

a policy for dillorc vs. style.css conflicts?

by jcid＠dillo.org

On Sun, Feb 15, 2009 at 07:54:15PM +0100, Hofmann Johannes wrote: > On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid 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). > > Jorge, what do you think about this? Can we go the style.css > way and remove all dillorc options for stuff that can also be done > with style.css? I'm very happy with the latest patches on font size, it's very important: http://www.useit.com/alertbox/designmistakes.html Reading that page is assuring. We're providing the necessary controls for people expressing their need for them! WRT your question, yes, it'd be good to go the CSS way, but also to keep it simple for a non-CSS-savvy user to set. This is, maybe font_{min_size, max_size, factor} are well placed in dillorc. For text background and color, linkcolor, visited linkcolor they seem to belong in CSS. Now, if we're to put them in CSS, we must provide well-commented sample stylesheets, and also give some directions in the FAQ. It should be simple for the user to know how to set his own stylesheet options without previous CSS knowledge, and also how to disable the remote CSS when a page doesn't look good. It'd be great to specify, for instance, a "reading" stylesheet (for low contrast and highcontrast) from our website and to let the user tweak it. Then when he gets to a long page that he wants to read (not just skim), he could disable remote CSS and use the one he prefers. A few days ago I got to read the above link and relized the actual relevance of this issue. -- Cheers Jorge.-

Feb. 16, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sun, Feb 15, 2009 at 06:13:27PM +0100, Hofmann Johannes wrote: > Do the dates on the page mean that the CSS related leaks mostly > started with dillo sources from after 2009-02-12? No. I show each error once at the most recent time that it appeared in any log. There is no indication of how long the error has been appearing (although I could add it if it would be useful). All you can infer is that each error was unfixed on the day it was logged (at least in my repository, which I try to keep up to date). Also, statistically, errors near the top of the page are probably fairly commonm, and those near the bottom are probably either fixed or rare. Regards, Jeremy Henty

Feb. 16, 2009

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

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

On Sun, Feb 15, 2009 at 03:57:46PM -0300, Jorge Arellano Cid 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). Jorge, what do you think about this? Can we go the style.css way and remove all dillorc options for stuff that can also be done with style.css? Cheers, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by jcid＠dillo.org

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

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 Thanks for testing! Unfortunately I don't have valgrind running here. Do the dates on the page mean that the CSS related leaks mostly started with dillo sources from after 2009-02-12? Regards, Johannes

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

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. Ah ok, so "regular regular large" is the whole page without <html><body>... In that case I would have thought that html.cc generates fake <html> and <body> elements - which seems not to be the case currently. Opinions? > > > > > I was also thinking that we would need to get the color and > > > size from StyleEngine for plain and root png/gif backgrounds... > > > > Not sure about plain. Which color should StyleEngine choose? Or do > > you mean we should simulate a dummy DocTree for plain (e.g. > > <html><body><pre> ... </pre></body></html>)? > > I don't know what is most appropriate, but it would be good for a user > still to be able to control it somehow. I agree, maybe plain should really call StyleEngine::startElement() for <html>, <body>, <pre> and then use StyleEngine::style() to get the backgroundColor and color? Maybe even the font? > > > Alternatively we could move plain handling into a dpi together with > > the source view ... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

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. > > I was also thinking that we would need to get the color and > > size from StyleEngine for plain and root png/gif backgrounds... > > Not sure about plain. Which color should StyleEngine choose? Or do > you mean we should simulate a dummy DocTree for plain (e.g. > <html><body><pre> ... </pre></body></html>)? I don't know what is most appropriate, but it would be good for a user still to be able to control it somehow. > Alternatively we could move plain handling into a dpi together with > the source view ...

Feb. 15, 2009

[patch] Search Previous

by corvid＠lavabit.com

Johannes wrote: > I didn't touch the caseSens==true case, because I wasn't sure > whether we want to retain the possibility to search for e.g. \t or > \n in plain text or not. I just wanted to mention that DilloPlain::write() calls a_Misc_expand_tabs().

Feb. 15, 2009

a policy for dillorc vs. style.css conflicts?

by Johannes.Hofmann＠gmx.de

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? > > I was also thinking that we would need to get the color and > size from StyleEngine for plain and root png/gif backgrounds... Not sure about plain. Which color should StyleEngine choose? Or do you mean we should simulate a dummy DocTree for plain (e.g. <html><body><pre> ... </pre></body></html>)? Alternatively we could move plain handling into a dpi together with the source view ... Cheers, Johannes

Feb. 15, 2009

[patch] Search Previous

by Johannes.Hofmann＠gmx.de

On Sat, Feb 14, 2009 at 03:16:56AM +0000, corvid wrote: > Jo?o wrote: > > Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > > > Jo?o wrote: > > > > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > > > > Jo?o wrote: > > > > > > I've been trying to understand what's going on in CharIterator::prev() > > > > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > > > > > > > In the following code: > > > > > > > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > > > > (isspace (c1) && isspace (c2)); } > > > > > > > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > > > > according to my tests, is wrecking the search-previous functionality. > > > > > > > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > > > > > > > > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > > > > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > > > > a tab too (for example)? Maybe I missed the point. :S > > > > > > I think we want to treat something like tab and space as the same. > > > > > > > > > > Oh and one more thing. If our purpose is to treat all whitespace equaly > > (tabs=Spaces...), why do we _only_ do that when not doing a > > case-sensitive comparison? > > > > A way to verify that (isspace (c1) && isspace (c2)) is causing the fail > > is to search for ' ' backwards with case-sens* on --- it finds it. > > I don't really know that code in any detail whatsoever. I think > Johannes implemented it. Yes, I had added the (isspace (c1) && isspace (c2)) part to treat all whitespace equally. I didn't touch the caseSens==true case, because I wasn't sure whether we want to retain the possibility to search for e.g. \t or \n in plain text or not. Cheers, Johannes

Feb. 15, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

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 It looks much more insightful. 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. That's the starting point for debugging. Even if only a few have their URLs that's a good start. We can point new developers to this page too, as usually this bugs are not too complex to fix. -- Cheers Jorge.-

Feb. 15, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

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 If you find spurious entries then tell me and I'll add the suppressions to my Dillo/Valgrind script and they won't appear in subsequent log files. I'll do all the ones that come from FLTK, so you needn't point those out. Regards, Jeremy Henty

Feb. 15, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 09:33:27PM +0000, Jeremy Henty wrote: > On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote: > > On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > > > > > For your information. > > > > > > http://starurchin.org/dillo/valgrind.html > > > > > > It lists the valgrind errors from my most recent Dillo sessions. > > > It's just one big static HTML page at the moment. Feel free to > > > suggest how it could be more useful. > > > > One URL that reproduces each leak would be very helpful. > > 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. > > Repeated leaks can be omitted. > > It should already be doing that. I extract the suppression (the part > in { ... }) and eliminate duplicates based on that. It's not perfect > because different code paths may trigger the same error. I'm hoping > it proves to be good enough. I can't see an easy way to do better. > Suggestions are welcome. Usually when fixing one of these bugs, a few others dissappear. But you're right is hard to tell before the fix. You can erase the ones belonging to FLTK. -- Cheers Jorge.-

Feb. 14, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

On Sat, Feb 14, 2009 at 05:04:27PM -0300, Jorge Arellano Cid wrote: > On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > > > For your information. > > > > http://starurchin.org/dillo/valgrind.html > > > > It lists the valgrind errors from my most recent Dillo sessions. > > It's just one big static HTML page at the moment. Feel free to > > suggest how it could be more useful. > > One URL that reproduces each leak would be very helpful. Would having a single page with anchors for each link be enough, or do you want separate pages for each one? > Repeated leaks can be omitted. It should already be doing that. I extract the suppression (the part in { ... }) and eliminate duplicates based on that. It's not perfect because different code paths may trigger the same error. I'm hoping it proves to be good enough. I can't see an easy way to do better. Suggestions are welcome. Regards, Jeremy Henty

Feb. 14, 2009

My valgrind logs, for all to see.

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 06:35:48PM +0000, Jeremy Henty wrote: > > For your information. > > http://starurchin.org/dillo/valgrind.html > > It lists the valgrind errors from my most recent Dillo sessions. It's > just one big static HTML page at the moment. Feel free to suggest how > it could be more useful. One URL that reproduces each leak would be very helpful. Repeated leaks can be omitted. -- Cheers Jorge.-

Feb. 14, 2009

google login redirect

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 05:22:54PM +0200, Rogut??s Sparnuotos wrote: > Jorge Arellano Cid (2009-02-14 11:35): > > 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/ .....> > > > > BTW, does anybody know why some sites are using a refresh with > > delay zero? > > > > I also saw this technique used in gitweb, but don't know what > > problem it is suppossed to solve. > > I think that > * it is used as a supplement to server-side redirect (the Location: header) > * instead of server-side redirect (whatever the reasons [1]) > > In both cases, the user is not supposed to see the redirect happening, > as it is happening for technical (and not necessarily clever) reasons. > > I might be totally wrong, but these are the impressions I got while > investigating how to redirect the user to another page after > a successful POST (so the data is not submitted again in case of > a client-side page refresh). > > > > [1] Following the link, there is this sentence: > http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html > > "However, authors do not always have control over server-side > technologies; in that case, they can use a client-side redirect." Thanks a lot for the useful information! It seems like w3c decided to tolerate META refresh when the delay is zero. i.e. "instant client-side redirect". That explains its usage. OK, I'll work on a patch for this and the related bug that furaisanjin wrote (W3C's example uses a quoted URL). -- Cheers Jorge.-

Feb. 14, 2009

patch: optgroup for OptionMenu

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 03:41:40PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Feb 14, 2009 at 03:13:03AM +0000, corvid wrote: > > > I've had this kicking around in my tree for months...finally got > > > around to implementing the max string width for OptionMenu and > > > doing a little polishing. > > > > > > Here it treats optgroup, option, and /optgroup as types of options > > > because when I tried keeping options inside optgroup structures, it > > > turned out to be messier. > > > The idea is that if this is accepted, I will later do some renaming. > > > > It looks good so far. > > Please set the itemGroup position relative to its parent widget > > and not to cursor. > > I'm not sure what you mean by this. Currently, the item group positions itself relative to the selected item and the cursor. This is: the selected item is drawn under the mouse pointer, and the rest of the widget adjusted around. This is confusing (especially when one is drawn over the other). This is a FLTK feature that can be disabled. The idea is to have the parent menu drawn just under the selection widget, like here: [Option 1 v] .-------------. | Group1 >| | Group2 >| | Group3 >|.----------. '-------------'| Opt1 G3 | |=Opt2=G3==| <- Selected option | Opt3 G3 | '----------' Note 1: in this case a click with the mouse pointer over the "[Option 1 v]" widget is necessary to display the menus, but they draw relative to the parent ("[Option 1 v]") instead of making the selected option appear under the mouse pointer. Note 2: Firefox does an "incorrect" rendering according to this page: http://www.tantek.com/HTML4/OPTGROUP.html -- Cheers Jorge.-

Feb. 14, 2009

My valgrind logs, for all to see.

by onepoint＠starurchin.org

For your information. http://starurchin.org/dillo/valgrind.html It lists the valgrind errors from my most recent Dillo sessions. It's just one big static HTML page at the moment. Feel free to suggest how it could be more useful. You can see we're still getting lots of small leaks from the CSS parser, though the big ones have been fixed by recent commits. Regards, Jeremy Henty

Feb. 14, 2009

a policy for dillorc vs. style.css conflicts?

by corvid＠lavabit.com

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"? I was also thinking that we would need to get the color and size from StyleEngine for plain and root png/gif backgrounds...

Feb. 14, 2009

patch: optgroup for OptionMenu

by corvid＠lavabit.com

Jorge wrote: > On Sat, Feb 14, 2009 at 03:13:03AM +0000, corvid wrote: > > I've had this kicking around in my tree for months...finally got > > around to implementing the max string width for OptionMenu and > > doing a little polishing. > > > > Here it treats optgroup, option, and /optgroup as types of options > > because when I tried keeping options inside optgroup structures, it > > turned out to be messier. > > The idea is that if this is accepted, I will later do some renaming. > > It looks good so far. > Please set the itemGroup position relative to its parent widget > and not to cursor. I'm not sure what you mean by this. > This is confusing. The same or similar trick > used for the file menu may help.

Feb. 14, 2009

google login redirect

by rogutes＠googlemail.com

Jorge Arellano Cid (2009-02-14 11:35): > 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/ .....> > > BTW, does anybody know why some sites are using a refresh with > delay zero? > > I also saw this technique used in gitweb, but don't know what > problem it is suppossed to solve. I think that * it is used as a supplement to server-side redirect (the Location: header) * instead of server-side redirect (whatever the reasons [1]) In both cases, the user is not supposed to see the redirect happening, as it is happening for technical (and not necessarily clever) reasons. I might be totally wrong, but these are the impressions I got while investigating how to redirect the user to another page after a successful POST (so the data is not submitted again in case of a client-side page refresh). [1] Following the link, there is this sentence: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G110.html "However, authors do not always have control over server-side technologies; in that case, they can use a client-side redirect." [2] -- -- Rogut?s Sparnuotos

Feb. 14, 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/ .....> BTW, does anybody know why some sites are using a refresh with delay zero? I also saw this technique used in gitweb, but don't know what problem it is suppossed to solve. -- Cheers Jorge.-

Feb. 14, 2009

[patch] Search Previous

by jcid＠dillo.org

On Sat, Feb 14, 2009 at 12:38:36AM +0000, Jo?o Ricardo Louren?o wrote: > Sex, 2009-02-13 ?s 00:41 +0000, corvid escreveu: > > Jo?o wrote: > > > Qui, 2009-02-12 ?s 23:43 +0000, corvid escreveu: > > > > Jo?o wrote: > > > > > I've been trying to understand what's going on in CharIterator::prev() > > > > > and have been running tests and I have a question regarding iterator.hh. > > > > > > > > > > In the following code: > > > > > > > > > > inline static bool charsEqual (char c1, char c2, bool caseSens) > > > > > { return caseSens ? c1 == c2 : tolower (c1) == tolower (c2) || > > > > > (isspace (c1) && isspace (c2)); } > > > > > > > > > > Why are we checking if c1 and c2 are spaces? This is the code that, > > > > > according to my tests, is wrecking the search-previous functionality. > > > > > > > > We do want to regard whitespace chars as equivalent, don't we? > > > > > > > > > > > > > > hm..Well, but doesn't c1 == c2 do the job? The tolower() call wouldn't > > > 'change' the whitespace, as far as I know. Or do we want to consider ' ' > > > a tab too (for example)? Maybe I missed the point. :S > > > > I think we want to treat something like tab and space as the same. > > > > > > Oh and one more thing. If our purpose is to treat all whitespace equaly > (tabs=Spaces...), why do we _only_ do that when not doing a > case-sensitive comparison? It looks like a bug. > A way to verify that (isspace (c1) && isspace (c2)) is causing the fail > is to search for ' ' backwards with case-sens* on --- it finds it. -- Cheers Jorge.-

Feb. 14, 2009