- Dillo-dev - lists.mailman3.com

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