- Dillo-dev - lists.mailman3.com

Valgrind errors
by onepoint＠starurchin.org Jan. 24, 2009

Jan. 24, 2009

I've been valgrinding Dillo to see what I find and this one keeps turning up. Some memory is accessed that was freed by a_Cache_set_content_type(). Regards, Jeremy Henty

4 8

Valgrind error: possible link to Imgbuf crash?
by onepoint＠starurchin.org Jan. 23, 2009

Jan. 23, 2009

Here's another valgrind error that I think might be related to the crashes I have been seeing. The gdb stack trace showed that a_Imgbuf_new() was calling a layout method with an invalid address for the layout object. The valgrind error shows a_Imgbuf_new() reading invalid memory when it calls Widget::getLayout(). It looks to me as though a_Imgbuf_new() is being passed an Image that has already been freed. Regards, Jeremy Henty

1 0

[patch]: control lout's MSG from the preferences
by onepoint＠starurchin.org Jan. 23, 2009

Jan. 23, 2009

This patch makes the dillorc show_msg preference control lout's MSG macros as well as dillo's. Please comment. Regards, Jeremy Henty

2 1

[patch]: fix DBG build of table.cc
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

If you uncomment the #define of DBG in table.cc it won't compile. It looks as though most of the DBG code was fixed not to use the non-existent "result" variable, but one instance was left unchanged. Patch attached. Regards, Jeremy Henty

2 1

Crashes in dw::core::Layout::createImgbuf()
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

For the last few days I have been getting occasional crashes inside dw::core::Layout::createImgbuf() when opening a new tab. It does not seem to be predictable: if I restart Dillo and reopen all the URLs I was just looking at it is fine. The gdb backtrace often shows ridiculous values for this: eg. the attached example has this=0x6. I've seen other impossibly small values for this, but sometimes the value seems more sensible. Any ideas? I'd like to investigate further but I don't know what to look for. Pointers are welcome! Regards, Jeremy Henty

2 2

[bug]: hang in Css_parse_delaration()
by onepoint＠starurchin.org Jan. 22, 2009

Jan. 22, 2009

A simple example that hangs the CSS parser. The contents of the css block are the critical thing: it doesn't seem to matter what the selector is but changing either the parameter or the value inside the block stops the hang. After aborting the stack trace varies, but always seems to be inside Css_parse_declaration(). (I've attached some example stacks.) The real-world page that triggered the bug: http://dialinf.wordpress.com/2009/01/21/ultraproducts-the-category-theoreti… Regards, Jeremy Henty

2 2

[bug]: hang in Css_parse_declaration()
by onepoint＠starurchin.org Jan. 19, 2009

Jan. 19, 2009

The following HTML makes dillo hang and burn 100% CPU. <html> <body> <span style="{}">a</span> </body> </html> The bug does not appear if the span contains no text, or only whitespace. The stack trace always ends inside Css_parse_declaration(). The line number varies, but seems to be always one of 809, 823 or 963. You can see the same bug online at http://www.nation.co.ke/News/-/1056/515354/-/u1acuw/-/index.html Regards, Jeremy Henty

2 2

Re: A couple of patches
by jcid＠dillo.org Jan. 19, 2009

Jan. 19, 2009

Hi Johannes, On Thu, Jan 15, 2009 at 10:07:37AM +0100, Hofmann Johannes wrote: > Hi Jorge, > > On Wed, Jan 14, 2009 at 07:07:00PM -0300, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > Here go couple of patches. Please test and apply. > > Thanks, applied. > > > > > Note: the image background support is partial. It works well > > when coming back to a page. AFAIS the right solution is to decode > > transparent images to RGBA and let FLTK handle it. > > Yes, I think that would be the correct way to do it. > > > > > BTW, the CSS prototype seems stable enough to consider a merge. > > What do you think? > > Yes, it feels pretty stable and now that there is an option to > disable remote stylesheet loading, I think we can consider making > css-prototype the main branch of dillo. > However I'd like to have some issues fixed: > > * should load_stylesheets=NO only disable remote style-sheet loading > (as it does now), or should it disable all remote style processing > (e.g. style given in <style type="text/css"> </style>)? We can add a "parse_embedded_css" option. That way there's no ambiguity. My next task is to add the toolbox button mentioned in: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-December/005531.html It may hold CSS options akin to: [Tb Icon] .-------------------. .---------. | Change charset >|--------------------------------->| UTF-8 | | CSS >|-->.---------------. | Cp 1250 | | Free memory >|-. |* remote CSS | | ... | '-------------------' | |* embedded CSS | '---------' | |* use my CSS | | |* no CSS at all| | '---------------' | .------------------. '->| Images | | Local Files | | Everything unused | '-------------------' Note: '*' means a toggle option Note2: "use my CSS" replaces "Force my colors" We can polish from there. > * form.cc is not yet converted to the new style handling and widget > coloring is broken. OK. > * css-prototype displays e.g. table borders in the current color not > in shaded background-color as dillo-main does. > This is because CSS 2.1 states: > "If an element's border color is not specified with a border > property, user agents must use the value of the element's 'color' > property as the computed value for the border color. " > (http://www.w3.org/TR/CSS21/box.html#border-color-properties) > firefox however also uses a shaded background color. > I'd don't know how to deal with that at the moment. I'd say leave it as the standard says until it becomes an issue. In that case we can follow FF or decide better. > Then there is of course tons of issues with CSS, but we can improve > on that gradually. That's the idea. BTW, I have a question. How can a minimal font size be specified? Currently I have: body {font-size: 18px !important} in style.css, but often pages come with smaller fonts. e.g. http://www.linux.org.uk/Portaloo.cs For me is important because I have a problems reading tiny fonts, and my working laptop has a high screen resolution. -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

3 4

CSS branch merged!
by furaisanjin＠gmail.com Jan. 18, 2009

Jan. 18, 2009

Sorry, I didn't sent e-mail to mailing list. 2009/1/18 furaisanjin <furaisanjin(a)gmail.com>: > Hi all. > > 2009/1/18 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: >> On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: >>> Sorry, I mixed up 2 things. I guess default font is something I >>> specified in ~/.dillo/style.css if dillo can't find any fonts >>> specified in style. It seems that there is some timing issue when the >>> page is loaded. The first time somehow the page is unreadable but if I >>> goto to bookmark page and come back to the page, the page is readable. >> >> Argh, timing issues are bad. Can you please point me to a page where >> this happens? > > It seems that there are lots. I notice that Html_tag_open_meta doesn't > repush when charset is detected anymore. So I modified codes like > this. > > /* Cannot ask cache whether the content type was changed, as > * this code in another bw might have already changed it for us. > */ > if (a_Misc_content_type_cmp(html->content_type, new_content)) { > + a_Nav_repush(html->bw); > + html->stop_parser = true; > html->repush_after_head = true; > } > > This helps. I may not need to keep html->repush_after_head = true but > I'm not sure. I was wrong. This doesn't help all cases. The problem seems that when the page is repushed, somehow decoder_charset isn't called so that charset conversion doesn't happens. >>> Another issue is that if style sheet specified none Japanese font and >>> the font exists on my machine, then of course the page isn't readable >>> at all. This isn't dillo problem but style sheet problem. >> >> Do you have an example? How does firefox handle these pages? > > This (http://furaisanjin.blog.so-net.ne.jp) is one example. Firefox > shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/firefox.…) > and this is readable. However dillo shows something like this > (http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/dillo.png) > and I can see only dotted squares. > > Style sheet page contains > > #banner h1{ > margin:0; > padding:80px 0 0 14px; > font-size:36px; > font-family: Helvetica; > } > > and Helvetica isn't suitable for Japanese. Regards, furaisanjin

1 0

CSS branch merged!
by Johannes.Hofmann＠gmx.de Jan. 17, 2009

Jan. 17, 2009

On Sat, Jan 17, 2009 at 11:51:37PM +0900, furaisanjin wrote: > Sorry, I mixed up 2 things. I guess default font is something I > specified in ~/.dillo/style.css if dillo can't find any fonts > specified in style. It seems that there is some timing issue when the > page is loaded. The first time somehow the page is unreadable but if I > goto to bookmark page and come back to the page, the page is readable. Argh, timing issues are bad. Can you please point me to a page where this happens? > > Another issue is that if style sheet specified none Japanese font and > the font exists on my machine, then of course the page isn't readable > at all. This isn't dillo problem but style sheet problem. Do you have an example? How does firefox handle these pages? Regards, Johannes

1 0