- Dillo-dev - lists.mailman3.com

[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

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

Jan. 17, 2009

On Sat, Jan 17, 2009 at 11:04:12PM +0900, furaisanjin wrote: > 2009/1/17 Hofmann Johannes <Johannes.Hofmann(a)gmx.de>: > > In this case dillo should try the three fonts given. At least > > "monospace" should exist and be mapped to some default monospace > > font. > > I don't have such font which name is "monospace" on my machine. > fc-list command doesn't show such name. What is the default mono space > font in the current CSS implementation? None. That part is not yet implemented. > > Because some pages written in Japanese contain fonts that I don't have > at all, I can't read such pages. See my answer to Jorge's mail on how to force a fixed font-family. Regards, Johannes

1 0

[patch]: add copyright and license declarations to dpid sources
by onepoint＠starurchin.org Jan. 17, 2009

Jan. 17, 2009

I checked all the *.{c,cc} files and found that a couple of the dpid/ files were missing copyrights too. Patch attached. Regards, Jeremy Henty

2 1

[patch]: add copyright and license declaration to cssparser.cc
by onepoint＠starurchin.org Jan. 17, 2009

Jan. 17, 2009

There's no copyright or license in cssparser.cc . Patch attached. Regards, Jeremy Henty

2 2

Re: patch: some consts
by Johannes.Hofmann＠gmx.de Jan. 17, 2009

Jan. 17, 2009

On Sat, Jan 17, 2009 at 01:09:12AM +0000, corvid wrote: > (and an unrelated static) > It was time for my occasional running of nm... > committed! Thanks, Johannes

1 0

focus after closing tab
by Johannes.Hofmann＠gmx.de Jan. 15, 2009

Jan. 15, 2009

Hi, sometimes when closing a tab it feels that dillo focuses the "wrong" tab. Therefore I made a patch that puts the focus back to the tab from which a tab was opened. That way I always get back to the "base page" when closing a tab. Howerver I'm not sure that this is always right, e.g. when opening multiple tabs from one base page, one might want to read one after the other without going back to the base page. What do you think, which page should be focused when closing a tab: * the tab from which the closed one was opened? * the tab to the left of the closed one? * the most recently opened one? Cheers, Johannes

3 4

Re: focus after closing tab
by sandshrew＠gmail.com Jan. 15, 2009

Jan. 15, 2009

I would vote for "the most recently opened one" too. -- Brain: an apparatus with which we think we think. - A. Bierce

1 0