- Dillo-dev - lists.mailman3.com

[Patch]: [v2]: fix URL leak in Html_tag_open_link()

by Johannes.Hofmann＠gmx.de

On Sun, Feb 01, 2009 at 02:18:10PM -0300, Jorge Arellano Cid wrote: > On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > > > OK, I'm fairly sure this version is not as utterly broken as the > > previous one. :-) > > Committed > (with just a small change) > > > > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > > preference twice? > > The repush scheme include parsing the HTML header twice. > (not a big deal). I think Jeremy is referring to if (!prefs.load_stylesheets) return; in Html_tag_open_link() which seems redundant, as there is /* Remote stylesheets enabled? */ dReturn_if_fail (prefs.load_stylesheets); some lines above. Cheers, Johannes

Feb. 1, 2009

What's left to do for dillo-2.1?

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). That reminds me, it would be good to add some checking for malicious values before release.

Feb. 1, 2009

Close-tab Button

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 12:06:49AM +0000, Jo?o Ricardo Louren?o wrote: > Greetings to all. > > As a simple introduction may I say I thank you all for your work on > Dillo. > > Currently, I am trying to implement the Close-Tab button. I've been > discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to > dillo-dev. > > FLTK Tabs don't support a close-tab button, as many of you have seen, > and the idea was to have a button at the end of the tabs list. > > For that, I created an fltk::Button widget in CustTabGroup. I position > this widget at the end of the tabs list and, then, I add() it to the > CustTabGroup's parent() (UI). > > After that, I set the UI's resizer() to be an InvisibleBox positioned in > such a way that it doesn't resize the button itself, but only moves it. > > Refreshing the button (when changing/adding/closing tabs) is done in the > handle() method of the CustTabGroup. > > Just a second ago I solved one of the problems, which was the fact that > tab_height() returned 0 in the constructor and resize() didn't work. I > worked around that by constructing the button only in event() if > tab_height()>0 and it hasn't been constructed yet. This way we can use > the correct height for the button. > > It may not seem reliable to do so many things in handle(). Any > suggestions? We need to get something working, review it, and then we may ask in fltk.general whether it could have side effects. > It is functional, only you can say if it fully suits Dillo's needs > though. Please post the patch here so we can look at it. > Unfortunately, there are some problems: > > The first one is the most-relevant one. When the list of tabs grows it > can go over the button. I have been trying to fix this, but I can't seem > to do it. > A possible way could (maybe) be to 'trick' the pager into thinking it > has less space left to draw the tabs, and that could possibly be > achieved using update_positions(), although I am having some problems > with that. Or maybe just tweaking the value. After all it's a workaround. > The second problem is a minor one, but annoying. I believe when CSS > rendering is triggered, the render area flickers and that is normal. > However, the way I implemented this (probably because of it being in > handle()) makes the Button also flash. A side affect of being a child of UI. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

patch: 30x response without Location == segfault

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 05:45:43AM +0000, corvid wrote: > (new bug #886) > The submitter got a 300 Multiple Choices > without a Location header. > > from the RFC, > If the server has a preferred choice of representation, it SHOULD > include the specific URI for that representation in the Location > field; user agents MAY use the Location field value for automatic > redirection. > and > Unless it was a HEAD request, the response SHOULD include an entity > containing a list of resource characteristics and location(s) from > which the user or user agent can choose the one most appropriate. > > In this case, http://www.weather.gov/data/current_obs/PAFC.xml > had no Location, and does have a body consisting of an > HTML page giving alternatives. > > PS I think it might become more common for users to encounter > Multiple Choices now that there's a pref for Accept-Language. Committed. Please update the bug tracker. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

[Patch]: [v2]: fix URL leak in Html_tag_open_link()

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 08:32:14AM +0000, Jeremy Henty wrote: > > OK, I'm fairly sure this version is not as utterly broken as the > previous one. :-) Committed (with just a small change) > > BTW, does a_Html_tag_open_link() really need to check the stylesheets > preference twice? The repush scheme include parsing the HTML header twice. (not a big deal). -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

Re: unused parameter warning in http.c

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 10:09:28PM +0000, corvid wrote: > surprised me until I remembered that you turned on -W. > I didn't realize that plain C doesn't allow the name > to be left off in those cases. > > What is the usual trick for this? The manpage talks > about an 'unused' attribute, but that sounds like a gcc-ism. In the past, for C, I've used these couple: 1.- Add a dummy test for the unused var. 2.- Remove the parameter from the function and cast it to match. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

Bad character coding for www.blisty.cz

by corvid＠lavabit.com

Jorge wrote: > On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > > Michal wrote: > > > Hi, > > > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > > following sence (it's in Czech) > > > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > > > but in current hg tip it's displayed as > > > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > > > I noticed this first when the character coding code in post-dillo-2.0 > > > was changed. > > > > > > When the page is saved to disk and opened it works as expected. > > > > > > It appeared that it is somehow related to default dillorc. > > > > > > 1) remove the ~/.dillo directory > > > 2) dillo www.blisty.cz > > > 3) --> PASS > > > 4) quit dillo > > > 5) dillo www.blisty.cz > > > 6) --> FAIL > > > > > > Can anyone, please, have a look at this and say whether is it > > > reproducible and, perhaps, fix it? :) > > > > Breaks for me, too. > > > > Plus having to wait through 116K of download before anything > > appears is no fun. > > It works for me! :-) > > Seriously, I still have a pending item to review here, and it's > when charset appears after the stylesheet in HEAD. This page also > has timing issues: http://www.daemonnews.org > > It looks like queueing the stylesheets and asking for them > after charset or at head close may fix it. Does anyone else experience pages not rendering until download is complete? I see this with the dillo.org pages, for instance, since the meta charset is iso-8859-1.

Feb. 1, 2009

Bad character coding for www.blisty.cz

by jcid＠dillo.org

On Sun, Feb 01, 2009 at 02:24:30AM +0000, corvid wrote: > Michal wrote: > > Hi, > > > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > > following sence (it's in Czech) > > > > "??t??te Britsk? listy speci?ln?? upraven? pro va??e mobiln? telefony a PDA" > > > > but in current hg tip it's displayed as > > > > "???t???te Britsk??? listy speci???ln??? upraven??? pro va???e mobiln??? telefony a PDA" > > > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > > > I noticed this first when the character coding code in post-dillo-2.0 > > was changed. > > > > When the page is saved to disk and opened it works as expected. > > > > It appeared that it is somehow related to default dillorc. > > > > 1) remove the ~/.dillo directory > > 2) dillo www.blisty.cz > > 3) --> PASS > > 4) quit dillo > > 5) dillo www.blisty.cz > > 6) --> FAIL > > > > Can anyone, please, have a look at this and say whether is it > > reproducible and, perhaps, fix it? :) > > Breaks for me, too. > > Plus having to wait through 116K of download before anything > appears is no fun. It works for me! :-) Seriously, I still have a pending item to review here, and it's when charset appears after the stylesheet in HEAD. This page also has timing issues: http://www.daemonnews.org It looks like queueing the stylesheets and asking for them after charset or at head close may fix it. I want to update the image process documentation before getting into this bug. If *somebody* wants to do it before me, go ahead! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Feb. 1, 2009

[Patch]: [v2]: fix URL leak in Html_tag_open_link()

by onepoint＠starurchin.org

OK, I'm fairly sure this version is not as utterly broken as the previous one. :-) BTW, does a_Html_tag_open_link() really need to check the stylesheets preference twice? Jeremy Henty

Feb. 1, 2009

DO NOT: [Dillo-dev] [Patch]: fix URL leak in Html_tag_open_link()

by onepoint＠starurchin.org

Oops, I've got a reproducible crash from this patch. Let we figure out where I messed it up. Jeremy Henty

Feb. 1, 2009

patch: 30x response without Location == segfault

by corvid＠lavabit.com

(new bug #886) The submitter got a 300 Multiple Choices without a Location header. from the RFC, If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. and Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. In this case, http://www.weather.gov/data/current_obs/PAFC.xml had no Location, and does have a body consisting of an HTML page giving alternatives. PS I think it might become more common for users to encounter Multiple Choices now that there's a pref for Accept-Language.

Feb. 1, 2009

Bad character coding for www.blisty.cz

by corvid＠lavabit.com

Michal wrote: > Hi, > > I am affraid there ocurred regression in post-dillo-2.0 when compared to > dillo-2.0. Look on the www.blisty.cz web page, on the top there's > following sence (it's in Czech) > > "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" > > but in current hg tip it's displayed as > > "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" > > and of course, the whole page is displayed like in ISO-8859-1 coding. > > I noticed this first when the character coding code in post-dillo-2.0 > was changed. > > When the page is saved to disk and opened it works as expected. > > It appeared that it is somehow related to default dillorc. > > 1) remove the ~/.dillo directory > 2) dillo www.blisty.cz > 3) --> PASS > 4) quit dillo > 5) dillo www.blisty.cz > 6) --> FAIL > > Can anyone, please, have a look at this and say whether is it > reproducible and, perhaps, fix it? :) Breaks for me, too. Plus having to wait through 116K of download before anything appears is no fun.

Feb. 1, 2009

[Patch]: fix URL leak in Html_tag_open_link()

by onepoint＠starurchin.org

If Html_tag_open_link() gets a link that it decides not to use because of the media attribute, it returns without freeing the URL object it just created. The fix is to postpone creating the URL until after all the checks that might cause the function to return. Patch and test case attached. Regards, Jeremy Henty

Feb. 1, 2009

Close-tab Button

by jorl17.8＠gmail.com

Greetings to all. As a simple introduction may I say I thank you all for your work on Dillo. Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev. FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list. For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI). After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it. Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup. Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button. It may not seem reliable to do so many things in handle(). Any suggestions? It is functional, only you can say if it fully suits Dillo's needs though. Unfortunately, there are some problems: The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that. The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash. Thanks, Jo?o

Feb. 1, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 06:15:50PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > > On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > > > Johannes wrote: > > > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > > > * {font-family: sans !important} > > > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > > > So this should work. > > > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > > > > > Does it work for you? > > > > > > > > > > > > > > Yes, I tried: > > > > > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > > > * {color: red !important} > > > > > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > > > > > All red for me. > > > > > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > > > much except forms code in my tree right now. > > > > > > Still all red. > > > > > > > > > > > > How strange that we would see different behaviour here... > > > > > > I guess I'll have to dive into the code myself... > > > > > > > > > > Please check again with attached patch. > > > > > > > > It's working! > > > > Thanks! Excellent customer service :) > > > > > > It's not the proper solution though. > > > Here's the plan to apply rules according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > > > > > * For each CssRule compute the specificity according to > > > http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > * Store the rules in RuleList sorted by this specificity. > > > > > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > > > potentially matching rules and apply them in the order given by > > > their specificity. > > > > > > If anyone feels like implementing it - go ahead :) > > > > Just implemented that. Please test. > > I don't know what to test but there're > rendering differences with this page: > > http://www.thefreedictionary.com/unneeded > > (comparing with 83d840739a0e as tip) > > HTH. Well, rendering differences are the point here :) For example on cnn.com you can now read the "Home" white on red background, which was red on red before. Thanks for testing, Johannes

Jan. 31, 2009

Bad character coding for www.blisty.cz

by newman.x＠gmail.com

Hi, I am affraid there ocurred regression in post-dillo-2.0 when compared to dillo-2.0. Look on the www.blisty.cz web page, on the top there's following sence (it's in Czech) "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" but in current hg tip it's displayed as "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" and of course, the whole page is displayed like in ISO-8859-1 coding. I noticed this first when the character coding code in post-dillo-2.0 was changed. When the page is saved to disk and opened it works as expected. It appeared that it is somehow related to default dillorc. 1) remove the ~/.dillo directory 2) dillo www.blisty.cz 3) --> PASS 4) quit dillo 5) dillo www.blisty.cz 6) --> FAIL Can anyone, please, have a look at this and say whether is it reproducible and, perhaps, fix it? :) Thanks, -- Regards, Michal Nowak

Jan. 31, 2009

Window icon

by jcid＠dillo.org

Hi, Does anyone feel like hooking the small dillo icon to its window? http://fltk.org/newsgroups.php?s18335+gfltk.general+v18348+T1 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

CSS branch merged!

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > > Johannes wrote: > > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > > * {font-family: sans !important} > > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > > So this should work. > > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > > > Does it work for you? > > > > > > > > > > > > Yes, I tried: > > > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > > * {color: red !important} > > > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > > > All red for me. > > > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > > much except forms code in my tree right now. > > > > > Still all red. > > > > > > > > > > How strange that we would see different behaviour here... > > > > > I guess I'll have to dive into the code myself... > > > > > > > > Please check again with attached patch. > > > > > > It's working! > > > Thanks! Excellent customer service :) > > > > It's not the proper solution though. > > Here's the plan to apply rules according to > > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > > > * For each CssRule compute the specificity according to > > http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > * Store the rules in RuleList sorted by this specificity. > > > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > > potentially matching rules and apply them in the order given by > > their specificity. > > > > If anyone feels like implementing it - go ahead :) > > Just implemented that. Please test. I don't know what to test but there're rendering differences with this page: http://www.thefreedictionary.com/unneeded (comparing with 83d840739a0e as tip) HTH. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 06:53:47PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 02:38:47PM -0300, Jorge Arellano Cid wrote: > > On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > > > agree? What's left to be done? > > > > > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > > > but we won't pass any ACID test soon anyway. > > > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > > > help on that is very welcome :-). > > > > > > > > Ah!, and there's the very important issue of the visited link color. > > > > When coming back to a page, most of the time visited links aren't shown > > > > as such (i.e. drawn in visited color). > > > > > > Do you have an example? CSS allows to specify the visited link > > > color, so it may just have been set by the author to something > > > unexpected. > > > > http://www.linux.org.uk/Portaloo.cs > > > > (but as you said, this one sets to the same color). > > > > http://www.lacuarta.cl > > > > If you click on a red headline and come back, the color is the same. > > I don't know what color is visited set to. > > Yes, that's expected. They set the color for visited links. > firefox also shows them in red. > > > > > > Does > > > > > > :visited {color: #800080 !important} > > > > > > in .dillo/style.css fix the problem? > > > > Yes. > > > > It always shows the same visited-color, but is much better than > > without. Personally, I like best something like the old "contrast > > visited color" ;) > > That's problematic. I don't know how to express this in CSS and > hacking this around CSS seems ugly. > Maybe adding some special dillo specific CSS extension would be > possible. > But before doing that we should make sure that it really can't be > done with standard CSS. Also we should check what other browsers do. Yes. In its current state: :visited {color: #800080 !important} is enough for a release. Maybe in the future we can modify the custom dillo stylesheet with a computed visited color, on-the-fly for each page. Is that possible? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 02:38:47PM -0300, Jorge Arellano Cid wrote: > On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > > agree? What's left to be done? > > > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > > but we won't pass any ACID test soon anyway. > > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > > help on that is very welcome :-). > > > > > > Ah!, and there's the very important issue of the visited link color. > > > When coming back to a page, most of the time visited links aren't shown > > > as such (i.e. drawn in visited color). > > > > Do you have an example? CSS allows to specify the visited link > > color, so it may just have been set by the author to something > > unexpected. > > http://www.linux.org.uk/Portaloo.cs > > (but as you said, this one sets to the same color). > > http://www.lacuarta.cl > > If you click on a red headline and come back, the color is the same. > I don't know what color is visited set to. Yes, that's expected. They set the color for visited links. firefox also shows them in red. > > > Does > > > > :visited {color: #800080 !important} > > > > in .dillo/style.css fix the problem? > > Yes. > > It always shows the same visited-color, but is much better than > without. Personally, I like best something like the old "contrast > visited color" ;) That's problematic. I don't know how to express this in CSS and hacking this around CSS seems ugly. Maybe adding some special dillo specific CSS extension would be possible. But before doing that we should make sure that it really can't be done with standard CSS. Also we should check what other browsers do. Cheers, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > agree? What's left to be done? > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > but we won't pass any ACID test soon anyway. > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > help on that is very welcome :-). > > > > Ah!, and there's the very important issue of the visited link color. > > When coming back to a page, most of the time visited links aren't shown > > as such (i.e. drawn in visited color). > > Do you have an example? CSS allows to specify the visited link > color, so it may just have been set by the author to something > unexpected. http://www.linux.org.uk/Portaloo.cs (but as you said, this one sets to the same color). http://www.lacuarta.cl If you click on a red headline and come back, the color is the same. I don't know what color is visited set to. > Does > > :visited {color: #800080 !important} > > in .dillo/style.css fix the problem? Yes. It always shows the same visited-color, but is much better than without. Personally, I like best something like the old "contrast visited color" ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

Re: Dillo Source code

by jcid＠dillo.org

Hi Jo?o, On Fri, Jan 30, 2009 at 09:38:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > I have never worked with tabs in FLTK, but I've been browsing the > > > documentation and have been trying to understand them. As for the > > > button, I've nearly got it, the only problem is finding a way to prevent > > > tabs from going over the button and that doesn't seem to be happening. > > > An alternative would be to have the button in the 'tool-bar' or limit > > > the number of tabs (doesn't seem nice right?). I'm trying to figure out > > > pagers to set some kind of limit... > > > > The button outside the tab-labels area would be confusing... > > > > > One other problem seems to be the fact that the button keeps resizing, > > > that's probably bad FLTK coding on my side, let's hope I can figure it > > > out. > > > > FLTK-2.0 widgets have a handle() method that handles events. > > They also have a draw() method that draws the widget. My first > > idea was to draw the button in the draw() method of the pager, > > and to hook its functionality in the handle() method. > > This is the way I'd explore. > > > > The canonical way would be to try to add a child button widget > > in the pager. It may not be possible though. > > Yes, I did try to think of adding a button widget in the pager, though > digging with the pager itself is quite a mess I'm trying to work out. > For now, I'm trying to move my hackish code into CustTabGroup and the > problem is that I can't seem to get the tab height... > > What I am doing (for now, which still suffers from the resizing bug, > since I did not touch pagers) is adding an fltk::Button, positioning it > correctly and making it visible. In order to have it visible I add() it > to the parent of a CustTabGroup instance (a UI, I believe), and this UI > is the one that resizes it, I should figure out a way of preventing > that. Is there another way of making it visible, not having it resize? > It's something I never dug before. I don't know why it is resizing. FLTK2 widgets need an explicit resize() call to enable it. Although there're exceptions. If you add it with a fixed size int the UI that should be it. > Adding a child button widget in the pager seems difficult in the 'real' > meaning of the word 'add'. As a pager isn't a group that seems > difficult, unless I do not use a widget but draw() it myself and then > handle() it correctly. Yes, the second option is where I'd start. There's the fltk.general forum for question like this: http://fltk.org/newsgroups.php?gfltk.general+T I haven't tried there yet and it would be interseting to know their advice. > > On to another issue. > > > > Browsing the code I noticed: > // WORKAROUND: limit the number of tabs because of a fltk bug > if (ui->tabs()->children() >= 127) > > And, then, browsing the FLTK code I found: > > static int p[128]; > ... > void TabGroup::draw() { > ... > int w[128]; > ... //code using w and p... > > I guess the problem is p being limited to 128...Probably fixing this > issue has been discussed earlier, but a hipothesis would be overriding > Fltk's code for TabGroup, anyway, that doesn't seem nice. Maybe we could > ask the FLTK people to change it, if they agreed with it. Having more > than 127 tabs open seems impossible but we never know. FLTK2 is beong stalled for some time now. The team is focused on the 1.3.x branch. I wouldn't expect a patch unless we send it to them. At some point in the future we may be switching to 1.3.x. (they seem to want to develop a compatibility layer for FLTK-2.0, so ATM it's better to wait). I'd focus on the close-tab issue. ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > agree? What's left to be done? > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > but we won't pass any ACID test soon anyway. > > I'd like to get the font-size issue on wikipedia.org fixed however - > > help on that is very welcome :-). > > Ah!, and there's the very important issue of the visited link color. > When coming back to a page, most of the time visited links aren't shown > as such (i.e. drawn in visited color). Do you have an example? CSS allows to specify the visited link color, so it may just have been set by the author to something unexpected. Does :visited {color: #800080 !important} in .dillo/style.css fix the problem? Cheers, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). Ah!, and there's the very important issue of the visited link color. When coming back to a page, most of the time visited links aren't shown as such (i.e. drawn in visited color). -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). and there's the "minimal_font_size" pref. I may look into this after dicache... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? It looks like the main part is done. The close-tab icon is still missing (Jo?o Ricardo is working on it). I'm yet to push more dicache/image cleanups and to update the respective docs. There're more valgrind issues to look into. It would also be interesting to look at the addblock code; corvid made a prototype based on RE. I have the feeling (i.e. not backed with actual data) that maybe an option to not load resources from sites other than where the page is hosted, would get rid of most of the problems cheaply. Another posibility is to filter by host (dStrncasecmp() against URL_HOST), and maybe also offer RE filtering for more fine tunning (comments encouraged). CSS, we need Johannes green light on this. More stabilizing & testing. After that, custom packages need to be built for Debian, Ubuntu, RedHat... We may be more or less one month away... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? I agree. Of course there is a lot todo regarding CSS conformance, but we won't pass any ACID test soon anyway. I'd like to get the font-size issue on wikipedia.org fixed however - help on that is very welcome :-). Regards, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by onepoint＠starurchin.org

I get the feeling we are close to releasing dillo-2.1. Do others agree? What's left to be done? Regards, Jeremy Henty

Jan. 31, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > * {font-family: sans !important} > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > So this should work. > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > Does it work for you? > > > > > > > > > > Yes, I tried: > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > * {color: red !important} > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > All red for me. > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > much except forms code in my tree right now. > > > > Still all red. > > > > > > > > How strange that we would see different behaviour here... > > > > I guess I'll have to dive into the code myself... > > > > > > Please check again with attached patch. > > > > It's working! > > Thanks! Excellent customer service :) > > It's not the proper solution though. > Here's the plan to apply rules according to > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > * For each CssRule compute the specificity according to > http://www.w3.org/TR/CSS21/cascade.html#specificity > > * Store the rules in RuleList sorted by this specificity. > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > potentially matching rules and apply them in the order given by > their specificity. > > If anyone feels like implementing it - go ahead :) Just implemented that. Please test. Cheers, Johannes

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

Hi Andreas, On Fri, Jan 30, 2009 at 05:24:56PM +0100, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 30 Jan 2009 12:22:46 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > confirms that Mercurial itself is really fast and I've seen other > > > reports criticising FreeHG's performance. Perhaps we should think > > > about moving host? It's not always easy to find time to devote to > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > for a connection to the server. I'm committed enough to grit my teeth > > > and wait but I can see it putting off would-be contributors. > > > > > > Just a thought, > > > > Yes, I've also had trouble with it, and when normal it's slower > > than our Wearlab's CVS. > > > > A couple of days ago (while developoing/reviewing patches) I > > digged a bit on it and it seems that bitbucket is much faster. We > > can try bitbucket while we find a long term solution (e.g. FSF's > > savannah is offering Mercurial and Git repos, but the applying > > process may take some time). > > > > At some point in time we should move out from the Wearlab, as > > it may be closed soon. Currently we need webserver/CGI/python > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > we may use another bugtracker too. > > > The server which actually hosts the dillo debian and openmoko > packages should be an alternative. > At least performance and bandwidth should be no problem. Maybe moving > hg there is a starting point. Does this server belong to the Wearlab? If not, what's its expected lifespan? Or are you suggesting it as an interim solution for mercurial hosting? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

FreeHG performance

by akemnade＠tzi.de

Hi Jorge, On Fri, 30 Jan 2009 12:22:46 -0300 Jorge Arellano Cid <jcid(a)dillo.org> wrote: > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > often I get a 404 Not Found and right now it's hanging. Everyone > > confirms that Mercurial itself is really fast and I've seen other > > reports criticising FreeHG's performance. Perhaps we should think > > about moving host? It's not always easy to find time to devote to > > Dillo so it's rather aggravating when that time is wasted just waiting > > for a connection to the server. I'm committed enough to grit my teeth > > and wait but I can see it putting off would-be contributors. > > > > Just a thought, > > Yes, I've also had trouble with it, and when normal it's slower > than our Wearlab's CVS. > > A couple of days ago (while developoing/reviewing patches) I > digged a bit on it and it seems that bitbucket is much faster. We > can try bitbucket while we find a long term solution (e.g. FSF's > savannah is offering Mercurial and Git repos, but the applying > process may take some time). > > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. > The server which actually hosts the dillo debian and openmoko packages should be an alternative. At least performance and bandwidth should be no problem. Maybe moving hg there is a starting point. Greetings Andreas Kemnade

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 12:22:46PM -0300, Jorge Arellano Cid wrote: > [...] > At some point in time we should move out from the Wearlab, as > it may be closed soon. Currently we need webserver/CGI/python > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > we may use another bugtracker too. Oh, I forgot email! (that's paramount :) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > Am I the only one getting very poor performance from FreeHG ? Quite > often I get a 404 Not Found and right now it's hanging. Everyone > confirms that Mercurial itself is really fast and I've seen other > reports criticising FreeHG's performance. Perhaps we should think > about moving host? It's not always easy to find time to devote to > Dillo so it's rather aggravating when that time is wasted just waiting > for a connection to the server. I'm committed enough to grit my teeth > and wait but I can see it putting off would-be contributors. > > Just a thought, Yes, I've also had trouble with it, and when normal it's slower than our Wearlab's CVS. A couple of days ago (while developoing/reviewing patches) I digged a bit on it and it seems that bitbucket is much faster. We can try bitbucket while we find a long term solution (e.g. FSF's savannah is offering Mercurial and Git repos, but the applying process may take some time). At some point in time we should move out from the Wearlab, as it may be closed soon. Currently we need webserver/CGI/python shell accounts and a DCVS (Hg or Git). CGI is quite useful, but we may use another bugtracker too. Suggestions? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009

Still leaking CSS values

by onepoint＠starurchin.org

On Fri, Jan 30, 2009 at 01:25:19PM +0100, Hofmann Johannes wrote: > Should be fixed in tip now. It is! (After three tries to "hg pull" from freehg.org, see my grumbling elsewhere.) Regards, Jeremy Henty

Jan. 30, 2009

FreeHG performance

by onepoint＠starurchin.org

Am I the only one getting very poor performance from FreeHG ? Quite often I get a 404 Not Found and right now it's hanging. Everyone confirms that Mercurial itself is really fast and I've seen other reports criticising FreeHG's performance. Perhaps we should think about moving host? It's not always easy to find time to devote to Dillo so it's rather aggravating when that time is wasted just waiting for a connection to the server. I'm committed enough to grit my teeth and wait but I can see it putting off would-be contributors. Just a thought, Jeremy Henty

Jan. 30, 2009

Still leaking CSS values

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 06:34:22PM +0000, Jeremy Henty wrote: > > The "0123456789" value in the stylesheet leaks. Test case and > valgrind log attached. Should be fixed in tip now. It turned out to be a bug in the CSS parser. While tracking this down, I found a simple way to reduce the number of CSS rules (by eliminating those that have an empty property list). Regards, Johannes

Jan. 30, 2009

Still leaking CSS values

by onepoint＠starurchin.org

The "0123456789" value in the stylesheet leaks. Test case and valgrind log attached. Regards, Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by onepoint＠starurchin.org

On Thu, Jan 29, 2009 at 04:08:12PM +0100, Hofmann Johannes wrote: > Never mind. I think I've got it. See attached patch. That did it! That is, it removed the "definitely lost" errors. The "indirectly lost errors" are still there. I'm still not sure how to interpret them. They could be artifacts of the other leaks that I am currently suppressing. Attached the log and the test HTML I was using. Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by jcid＠dillo.org

On Thu, Jan 29, 2009 at 03:40:28PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 11:38:34AM -0300, Jorge Arellano Cid wrote: > > On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > > > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > > > free any existing value but I'm not sure I understand how these > > > > > > > > classes are meant to manage their memory. > > > > > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > > > not an enum or length). To know this we could depend on the > > > > > > > corresponding CssProperty::Name (freeing it for > > > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > > > Type could fit in two shorts. > > > > > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > > > adding fields rather than resorting to packing tricks. But that's > > > > > > only a mild preference: either seems OK. > > > > > > > > > > Went with the former for now, but we will need to switch to the > > > > > latter to support "inherit" or properties that can hold strings _or_ > > > > > enums. > > > > > Please check current tip. > > > > > > > > These patches produce lots of warnings in the test directory: > > > > > > I can't reproduce the warnings, > > > > I'm using: > > gcc version 4.3.2 > > CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > > > > > but I think I know the reason. It's > > > changeset 9a7684395cca. > > > Can you please check attached patch which tries to fix the > > > underlying issue in an other way. > > > Comments are welcome! We could also backout > > > 9a7684395cca and leave things as they were before, but deleting > > > memory allocated with strdup() is a bug. > > > > Yes, that's a bug. > > > > I think the solution is much simpler. The attached patch, > > applied on current tip, solves the issue. Please try it and > > commit if you like it. ;) > > Right. It's really not worth the effort to avoid this cast. > > Committed! Good. BTW, when receiving spare patches, after applying them and testing, this command comes very handy to commit: hg ci -u <User Info> e.g. hg ci -u "corvid <corvid(a)lavabit.com>" -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 03:52:45PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 02:48:54PM +0000, Jeremy Henty wrote: > > On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > > > Next try. Please check attached patch. > > > > No difference. :-( > > Does this also happen if you just start dillo with the > splash screen and quit again (without accessing any websites)? > Or which websites do you access to reproduce this? Never mind. I think I've got it. See attached patch. Cheers, Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 02:48:54PM +0000, Jeremy Henty wrote: > On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > > Next try. Please check attached patch. > > No difference. :-( Does this also happen if you just start dillo with the splash screen and quit again (without accessing any websites)? Or which websites do you access to reproduce this? Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by onepoint＠starurchin.org

On Thu, Jan 29, 2009 at 02:54:23PM +0100, Hofmann Johannes wrote: > Next try. Please check attached patch. No difference. :-( Jeremy Henty

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 11:38:34AM -0300, Jorge Arellano Cid wrote: > On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > > free any existing value but I'm not sure I understand how these > > > > > > > classes are meant to manage their memory. > > > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > > not an enum or length). To know this we could depend on the > > > > > > corresponding CssProperty::Name (freeing it for > > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > > Type could fit in two shorts. > > > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > > adding fields rather than resorting to packing tricks. But that's > > > > > only a mild preference: either seems OK. > > > > > > > > Went with the former for now, but we will need to switch to the > > > > latter to support "inherit" or properties that can hold strings _or_ > > > > enums. > > > > Please check current tip. > > > > > > These patches produce lots of warnings in the test directory: > > > > I can't reproduce the warnings, > > I'm using: > gcc version 4.3.2 > CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > > > but I think I know the reason. It's > > changeset 9a7684395cca. > > Can you please check attached patch which tries to fix the > > underlying issue in an other way. > > Comments are welcome! We could also backout > > 9a7684395cca and leave things as they were before, but deleting > > memory allocated with strdup() is a bug. > > Yes, that's a bug. > > I think the solution is much simpler. The attached patch, > applied on current tip, solves the issue. Please try it and > commit if you like it. ;) Right. It's really not worth the effort to avoid this cast. Committed! Thanks, Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by jcid＠dillo.org

On Thu, Jan 29, 2009 at 02:33:30PM +0100, Hofmann Johannes wrote: > On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > > free any existing value but I'm not sure I understand how these > > > > > > classes are meant to manage their memory. > > > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > > not an enum or length). To know this we could depend on the > > > > > corresponding CssProperty::Name (freeing it for > > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > > The latter is cleaner and would not need more memory, as Name and > > > > > Type could fit in two shorts. > > > > > > > > So, which should it be? I favour the former as I think that if we > > > > want to keep the Value struct lean then it is nicer to do it by not > > > > adding fields rather than resorting to packing tricks. But that's > > > > only a mild preference: either seems OK. > > > > > > Went with the former for now, but we will need to switch to the > > > latter to support "inherit" or properties that can hold strings _or_ > > > enums. > > > Please check current tip. > > > > These patches produce lots of warnings in the test directory: > > I can't reproduce the warnings, I'm using: gcc version 4.3.2 CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > but I think I know the reason. It's > changeset 9a7684395cca. > Can you please check attached patch which tries to fix the > underlying issue in an other way. > Comments are welcome! We could also backout > 9a7684395cca and leave things as they were before, but deleting > memory allocated with strdup() is a bug. Yes, that's a bug. I think the solution is much simpler. The attached patch, applied on current tip, solves the issue. Please try it and commit if you like it. ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 01:03:29PM +0000, Jeremy Henty wrote: > On Thu, Jan 29, 2009 at 01:25:29PM +0100, Hofmann Johannes wrote: > > > Can you please retry with the user-agent style parsing disabled: > > > > diff -r 4b5125e3ca89 src/css.cc > > --- a/src/css.cc Thu Jan 29 12:38:20 2009 +0100 > > +++ b/src/css.cc Thu Jan 29 13:24:16 2009 +0100 > > @@ -327,7 +327,7 @@ CssContext::CssContext () { > > sheet[CSS_PRIMARY_USER] = userStyle; > > sheet[CSS_PRIMARY_USER_IMPORTANT] = userImportantStyle; > > > > - buildUserAgentStyle (); > > + //buildUserAgentStyle (); > > buildUserStyle (); > > } > > That takes out most of the "indirectly lost" memory but doesn't affect > the "definitely lost" stuff that valgrind generates the suppression > for. Log attached. Next try. Please check attached patch. Thanks for testing this, Johannes

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 09:37:31AM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > > I thought the problem was that CssPropertyList::set() does not > > > > > free any existing value but I'm not sure I understand how these > > > > > classes are meant to manage their memory. > > > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > > not an enum or length). To know this we could depend on the > > > > corresponding CssProperty::Name (freeing it for > > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > > The latter is cleaner and would not need more memory, as Name and > > > > Type could fit in two shorts. > > > > > > So, which should it be? I favour the former as I think that if we > > > want to keep the Value struct lean then it is nicer to do it by not > > > adding fields rather than resorting to packing tricks. But that's > > > only a mild preference: either seems OK. > > > > Went with the former for now, but we will need to switch to the > > latter to support "inherit" or properties that can hold strings _or_ > > enums. > > Please check current tip. > > These patches produce lots of warnings in the test directory: I can't reproduce the warnings, but I think I know the reason. It's changeset 9a7684395cca. Can you please check attached patch which tries to fix the underlying issue in an other way. Comments are welcome! We could also backout 9a7684395cca and leave things as they were before, but deleting memory allocated with strdup() is a bug. Cheers, Johannes > > make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo-wc/test' > dw_anchors_test.cc: In function 'int main(int, char**)': > dw_anchors_test.cc:120: warning: deprecated conversion from string constant to > 'char*' > dw_example.cc: In function 'int main(int, char**)': > dw_example.cc:49: warning: deprecated conversion from string constant to > 'char*' > dw_find_test.cc: In function 'int main(int, char**)': > dw_find_test.cc:93: warning: deprecated conversion from string constant to > 'char*' > dw_links.cc: In function 'int main(int, char**)': > dw_links.cc:88: warning: deprecated conversion from string constant to 'char*' > dw_links2.cc: In function 'int main(int, char**)': > dw_links2.cc:116: warning: deprecated conversion from string constant to > 'char*' > dw_images_simple.cc: In function 'int main(int, char**)': > dw_images_simple.cc:110: warning: deprecated conversion from string constant to > 'char*' > dw_images_scaled.cc: In function 'int main(int, char**)': > dw_images_scaled.cc:112: warning: deprecated conversion from string constant to > 'char*' > dw_images_scaled2.cc: In function 'int main(int, char**)': > dw_images_scaled2.cc:87: warning: deprecated conversion from string constant to > 'char*' > dw_lists.cc: In function 'int main(int, char**)': > dw_lists.cc:53: warning: deprecated conversion from string constant to 'char*' > dw_table_aligned.cc: In function 'int main(int, char**)': > dw_table_aligned.cc:56: warning: deprecated conversion from string constant to > 'char*' > dw_table.cc: In function 'int main(int, char**)': > dw_table.cc:61: warning: deprecated conversion from string constant to 'char*' > dw_border_test.cc: In function 'int main(int, char**)': > dw_border_test.cc:57: warning: deprecated conversion from string constant to > 'char*' > dw_resource_test.cc: In function 'int main(int, char**)': > dw_resource_test.cc:54: warning: deprecated conversion from string constant to > 'char*' > dw_ui_test.cc: In function 'int main(int, char**)': > dw_ui_test.cc:60: warning: deprecated conversion from string constant to > 'char*' > make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo-wc/test' > > when compiled with: > CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl > > Please update test/ too. > > -- > Cheers > Jorge.- > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by onepoint＠starurchin.org

On Thu, Jan 29, 2009 at 01:25:29PM +0100, Hofmann Johannes wrote: > Can you please retry with the user-agent style parsing disabled: > > diff -r 4b5125e3ca89 src/css.cc > --- a/src/css.cc Thu Jan 29 12:38:20 2009 +0100 > +++ b/src/css.cc Thu Jan 29 13:24:16 2009 +0100 > @@ -327,7 +327,7 @@ CssContext::CssContext () { > sheet[CSS_PRIMARY_USER] = userStyle; > sheet[CSS_PRIMARY_USER_IMPORTANT] = userImportantStyle; > > - buildUserAgentStyle (); > + //buildUserAgentStyle (); > buildUserStyle (); > } That takes out most of the "indirectly lost" memory but doesn't affect the "definitely lost" stuff that valgrind generates the suppression for. Log attached. Regards, Jeremy Henty

Jan. 29, 2009

dw::Image objects leak their mapKey

by jcid＠dillo.org

On Wed, Jan 28, 2009 at 09:25:02PM +0000, Jeremy Henty wrote: > On Wed, Jan 28, 2009 at 05:48:20PM -0300, Jorge Arellano Cid wrote: > > In the second part of the patch, Why not: > > > > void Image::setUseMap (ImageMapsList *list, object::Object *key) > > { > > mapList = list; > > + if (mapKey && mapKey != key) > > + delete mapKey; > > mapKey = key; > > } > > Because I'm ridiculously paranoid about data members pointing to > free()-ed values for even a nanosecond. You decide whether Dillo > needs to be similarly paranoid/ridiculous. :-) Interesting. With multithreading, if mapKey was a shared resource, it could be a problem. In that case a mutex solves the problem, making the operation "atomic". AFAIS, with: > if (key != mapKey) { > object::Object *oldKey = mapKey; > mapKey = key; > if (oldKey) > delete oldKey; > } If oldKey was a shared resource, there's still the problem of being preempted in the middle of the destructor (delete oldKey). If another thread uses the object then, BUM! Again, a mutex solves the problem. The simpler version was committed. ;-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by jcid＠dillo.org

On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > On Tue, Jan 27, 2009 at 09:08:56AM +0100, Hofmann Johannes wrote: > > > On Tue, Jan 27, 2009 at 07:45:42AM +0000, Jeremy Henty wrote: > > > > I thought the problem was that CssPropertyList::set() does not > > > > free any existing value but I'm not sure I understand how these > > > > classes are meant to manage their memory. > > > > > > CSS values are stored in CssProperty::Value, which is a union. The > > > fix is to free Value.strVal, whenever Value contains a strVal (and > > > not an enum or length). To know this we could depend on the > > > corresponding CssProperty::Name (freeing it for > > > CSS_PROPERTY_FONT_FAMILY, but not for others), or add a Type member. > > > The latter is cleaner and would not need more memory, as Name and > > > Type could fit in two shorts. > > > > So, which should it be? I favour the former as I think that if we > > want to keep the Value struct lean then it is nicer to do it by not > > adding fields rather than resorting to packing tricks. But that's > > only a mild preference: either seems OK. > > Went with the former for now, but we will need to switch to the > latter to support "inherit" or properties that can hold strings _or_ > enums. > Please check current tip. These patches produce lots of warnings in the test directory: make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo-wc/test' dw_anchors_test.cc: In function 'int main(int, char**)': dw_anchors_test.cc:120: warning: deprecated conversion from string constant to 'char*' dw_example.cc: In function 'int main(int, char**)': dw_example.cc:49: warning: deprecated conversion from string constant to 'char*' dw_find_test.cc: In function 'int main(int, char**)': dw_find_test.cc:93: warning: deprecated conversion from string constant to 'char*' dw_links.cc: In function 'int main(int, char**)': dw_links.cc:88: warning: deprecated conversion from string constant to 'char*' dw_links2.cc: In function 'int main(int, char**)': dw_links2.cc:116: warning: deprecated conversion from string constant to 'char*' dw_images_simple.cc: In function 'int main(int, char**)': dw_images_simple.cc:110: warning: deprecated conversion from string constant to 'char*' dw_images_scaled.cc: In function 'int main(int, char**)': dw_images_scaled.cc:112: warning: deprecated conversion from string constant to 'char*' dw_images_scaled2.cc: In function 'int main(int, char**)': dw_images_scaled2.cc:87: warning: deprecated conversion from string constant to 'char*' dw_lists.cc: In function 'int main(int, char**)': dw_lists.cc:53: warning: deprecated conversion from string constant to 'char*' dw_table_aligned.cc: In function 'int main(int, char**)': dw_table_aligned.cc:56: warning: deprecated conversion from string constant to 'char*' dw_table.cc: In function 'int main(int, char**)': dw_table.cc:61: warning: deprecated conversion from string constant to 'char*' dw_border_test.cc: In function 'int main(int, char**)': dw_border_test.cc:57: warning: deprecated conversion from string constant to 'char*' dw_resource_test.cc: In function 'int main(int, char**)': dw_resource_test.cc:54: warning: deprecated conversion from string constant to 'char*' dw_ui_test.cc: In function 'int main(int, char**)': dw_ui_test.cc:60: warning: deprecated conversion from string constant to 'char*' make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo-wc/test' when compiled with: CFLAGS="-g -O0 -W" CXXFLAGS="-g -O0 -W" ./configure --enable-ssl Please update test/ too. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 29, 2009

CSS leaks: WAS Re: [Dillo-dev] <ol>'s leak the labels of their items

by Johannes.Hofmann＠gmx.de

On Thu, Jan 29, 2009 at 11:43:36AM +0000, Jeremy Henty wrote: > On Wed, Jan 28, 2009 at 10:44:11PM +0100, Hofmann Johannes wrote: > > On Wed, Jan 28, 2009 at 01:06:51PM +0000, Jeremy Henty wrote: > > > Went with the former for now, but we will need to switch to the > > latter to support "inherit" or properties that can hold strings _or_ > > enums. > > Please check current tip. > > I still see a leak. I'm attaching a test case, the valgrind log and a > suppression that stops the report. Not sure about those. Maybe it's reporting the strings allocated for the user-agent style? Those are allocated once and never freed. Can you please retry with the user-agent style parsing disabled: diff -r 4b5125e3ca89 src/css.cc --- a/src/css.cc Thu Jan 29 12:38:20 2009 +0100 +++ b/src/css.cc Thu Jan 29 13:24:16 2009 +0100 @@ -327,7 +327,7 @@ CssContext::CssContext () { sheet[CSS_PRIMARY_USER] = userStyle; sheet[CSS_PRIMARY_USER_IMPORTANT] = userImportantStyle; - buildUserAgentStyle (); + //buildUserAgentStyle (); buildUserStyle (); } Cheers, Johannes

Jan. 29, 2009