February 2009 - Dillo-dev - lists.mailman3.com

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