October 2010 - Dillo-dev - lists.mailman3.com

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

On Thu, Oct 14, 2010 at 07:16:15PM +0100, Jeremy Henty wrote: > > This small bit of HTML (attached) renders with an enormous vertical > extent in Dillo - I have to hold down the mouse in the lower half of > the scrollbar for several seconds before the slider moves even one > pixel! Strangely, if you take out the "<span>"s then the vertical > extent is *much* smaller, although still far too large. What's going > on? Ha! The (incorrect) use of line-height:auto seems to be more common than I thought. Just found it again on dev.mysql.com... Cheers, Johannes

Oct. 17, 2010

Dillo config in LTIB

by vic＠smartqsys.com

Hi, For now I can live without WLAN access. Now that I have Dillo up, I click on a button on a page and have this form handler issue. Is this a configuration issue or a feature not supported by Dillo? Thanks, Vic [root@nxp /]# Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' Dns_server [0]: 192.168.1.5 is 192.168.1.5 Connecting to 192.168.1.5 Unable to convert from character encoding: 'ISO-8859-1' >>> a_Nav_repush <<<< Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/all.css Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/Accounts.Css NumPendingStyleSheets=1 NumPendingStyleSheets=2 HTTP warning: unhandled MIME type: "image/png" >>> a_Nav_repush <<<< Nav_open_url: new url='http://192.168.1.5:88/LoginForm?Ctr_No=1' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/all.css Html_tag_open_link(): addCssUrl http://192.168.1.5:88/styles/Accounts.Css bad font: variable HTTP warning: unhandled MIME type: "image/png" DilloHtmlForm::eventHandler DilloHtmlForm::eventHandler ----- Original Message ----- From: "Vic" <vic(a)smartqsys.com> To: <dillo-dev(a)dillo.org> Sent: Wednesday, October 13, 2010 5:00 PM Subject: Re: [Dillo-dev] Dillo config in LTIB > Hi Jorge, > > The EA lpc3250 is connected to a gateway router with IP 192.168.1.4. > pinging > local LAN hosts is fine but WLAN host are unreachable. I tried editing > etc/resolv.conf with nameserver 192.168.1.4 , but this time after dillo is > up instead and not before launching dillo. It is able to > resolve but this is what I get... > > [root@nxp /]# ping www.dillo.org -c 4 > PING www.dillo.org (134.102.206.165): 56 data bytes > ping: sendto: Network is unreachable > [root@nxp /]# > > Nav_open_url: new url='http://www.dillo.org' > Dns_server [0]: www.dillo.org is 134.102.206.165 > Connecting to 134.102.206.165 > Http_connect_socket ERROR: Network is unreachable > > Thanks, > Vic > > >> >> Message: 1 >> Date: Tue, 12 Oct 2010 09:20:50 -0300 >> From: Jorge Arellano Cid <jcid(a)dillo.org> >> Subject: Re: [Dillo-dev] Dillo config in LTIB >> To: dillo-dev(a)dillo.org >> Message-ID: <20101012122050.GB2862(a)dillo.org> >> Content-Type: text/plain; charset=us-ascii >> >> Hi, >> >> On Mon, Oct 11, 2010 at 08:12:09PM -0700, Vic wrote: >>> Hi, >>> >>> I installed Dillo in LTIB and while the splash page went up, >>> clicking links reported a dns error. I checked out dillorc and >>> saw no setting related to dns. >> >> Dillo uses getaddrinfo(). It depends on the OS. >> >>> Trying a link to localhost also >>> gave I/O errors. >> >> This is strange... >> >>> My trace as follows: >>> >>> Nav_open_url: new url='http://www.dillo.org/' >>> DNS error: TRY_AGAIN >>> Dns_server [0]: www.dillo.org is (nil) >> >> Does "ping www.dillo.org" resolve? >> >> >>> Using localhost: >>> >>> Nav_open_url: new url='http://localhost:88' >>> Dns_server [0]: localhost is 127.0.0.1 >>> Connecting to 127.0.0.1 >>> ** WARNING **: IO_write, closing with pending data not sent >>> ** WARNING **: "GET / HTTP/1.1\x0D >>> Connection: close\x0D >>> Accept-Charset: utf-8,*;q=0.8\x0D >>> Accept-Encoding: gzip\x0D >>> Host: localhost:88\x0D >>> Referer: http://localhost:88/\x0D >>> User-Agent: Dillo/2.1\x0D >>> \x0D >>> " >>> >>> Thanks for any help. >> >> It looks like something external closed the connection. >> Firewall? >> >> -- >> Cheers >> Jorge.- >> >> >> >

Oct. 16, 2010

Polygon::isPointWithin()

by corvid＠lavabit.com

Johannes wrote: > I have commited a fix - please test. Thanks! > PS: To me it seems that the explicit closing of polygon paths in > html.cc:2348 is unnecessary and complicating things. > Can we remove it? Removed.

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 07:31:13PM +0100, Jeremy Henty wrote: > On Fri, Oct 15, 2010 at 11:41:18AM +0200, Johannes Hofmann wrote: > > > I just pushed a fix for the use of uninitialized values issue. > > Great! I just confirmed that it fixes the test case, and it also > fixes the page where I first saw the problem (which is a relief - > Hijinks Ensue is one of my favourite webcomics and it would have been > upsetting if it had been unreadable in Dillo). Good! > > > That fixes your testcase, but the modified one below is still > > broken. > > By "broken" you mean that it should respect the "line-height: 10em;" > style? Yes. I don't think it is very critical, but it should be fixed at some point. Cheers, Johannes

Oct. 15, 2010

Polygon::isPointWithin()

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 05:23:13PM +0000, corvid wrote: > Why isn't this working? It seems like a perfectly ordinary shape... > > <html> <body> > <img src="doesnt_matter.gif" width="250" height="700" usemap="#themap"> > <map name="themap"> > <area shape="poly" coords="1,250, 245,270, 223,513" > href="http://www.dillo.org"> > </map> > </body> </html> > > Dillo doesn't realize it when the cursor is inside the left part of the > polygon. I was hoping that this vector product stuff was Johannes code, > but I see it goes back to the initial revision of the dw2 tree, so who > knows where Sebastian might have gotten the algorithm from... That code is pretty cool - I would be proud of it if had written it ;-) The issue was just a that a product could overflow a 32bit integer. I have commited a fix - please test. Cheers, Johannes PS: To me it seems that the explicit closing of polygon paths in html.cc:2348 is unnecessary and complicating things. Can we remove it?

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by onepoint＠starurchin.org

On Fri, Oct 15, 2010 at 11:41:18AM +0200, Johannes Hofmann wrote: > I just pushed a fix for the use of uninitialized values issue. Great! I just confirmed that it fixes the test case, and it also fixes the page where I first saw the problem (which is a relief - Hijinks Ensue is one of my favourite webcomics and it would have been upsetting if it had been unreadable in Dillo). > That fixes your testcase, but the modified one below is still > broken. By "broken" you mean that it should respect the "line-height: 10em;" style? Regards, Jeremy Henty PS: I now regret using "insanely" in the subject line - it was over the top and might even be considered derogatory. I apologise to anyone who felt it was inappropriate.

Oct. 15, 2010

Polygon::isPointWithin()

by corvid＠lavabit.com

Why isn't this working? It seems like a perfectly ordinary shape... <html> <body> <img src="doesnt_matter.gif" width="250" height="700" usemap="#themap"> <map name="themap"> <area shape="poly" coords="1,250, 245,270, 223,513" href="http://www.dillo.org"> </map> </body> </html> Dillo doesn't realize it when the cursor is inside the left part of the polygon. I was hoping that this vector product stuff was Johannes code, but I see it goes back to the initial revision of the dw2 tree, so who knows where Sebastian might have gotten the algorithm from...

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

On Fri, Oct 15, 2010 at 10:30:01AM +0200, Johannes Hofmann wrote: > Hi Jeremy, > > On Thu, Oct 14, 2010 at 07:16:15PM +0100, Jeremy Henty wrote: > > > > This small bit of HTML (attached) renders with an enormous vertical > > extent in Dillo - I have to hold down the mouse in the lower half of > > the scrollbar for several seconds before the slider moves even one > > pixel! Strangely, if you take out the "<span>"s then the vertical > > extent is *much* smaller, although still far too large. What's going > > on? > > Thanks for the nice test case. valgrind shows, that an > uninitialized value is used somewhere. > The problem seems quite tricky: > A value of 'auto' is not allowed for line-height ('normal' would be > correct), but dillo does not ignore the declaration as it should. > Attached is a slightly modified test case, that shows the issue. > There are two competing declarations for line-height and normally > the last should win, but if it is illegal, the first should be used. > firefox does that correctly and shows the illegal declaration in the > error console. > I will try to fix it. I just pushed a fix for the use of uninitialized values issue. That fixes your testcase, but the modified one below is still broken. Cheers, Johannes > > Cheers, > Johannes > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> > <html> > <head> > <title></title> > <style type="text/css" > > li {line-height: 10em;} > li {line-height: auto;} > </style> > </head> > <body> > Begin > <ul> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > <li><span>AAAAAAAAAA</span></li> > </ul> > End > </body> > </html>

Oct. 15, 2010

[bug]: CSS sets insanely huge vertical extent

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Thu, Oct 14, 2010 at 07:16:15PM +0100, Jeremy Henty wrote: > > This small bit of HTML (attached) renders with an enormous vertical > extent in Dillo - I have to hold down the mouse in the lower half of > the scrollbar for several seconds before the slider moves even one > pixel! Strangely, if you take out the "<span>"s then the vertical > extent is *much* smaller, although still far too large. What's going > on? Thanks for the nice test case. valgrind shows, that an uninitialized value is used somewhere. The problem seems quite tricky: A value of 'auto' is not allowed for line-height ('normal' would be correct), but dillo does not ignore the declaration as it should. Attached is a slightly modified test case, that shows the issue. There are two competing declarations for line-height and normally the last should win, but if it is illegal, the first should be used. firefox does that correctly and shows the illegal declaration in the error console. I will try to fix it. Cheers, Johannes

Oct. 15, 2010

Pending tasks

by jcid＠dillo.org

On Thu, Oct 14, 2010 at 09:49:37AM +0200, Johannes Hofmann wrote: > On Wed, Oct 13, 2010 at 03:13:16PM -0300, Jorge Arellano Cid wrote: > > On Tue, Oct 12, 2010 at 09:54:13PM +0200, Johannes Hofmann wrote: > > *snip* > > > > > > > > > As currently the cell border, padding and margin are drawn by > > > > the cell widget (textblock) inside a table, the general idea is > > > > to make textblock consider "collapse" mode when inside a table. > > > > > > postprocessAttrs() does not take into account in which > > > element we currently are (e.g. <table>, <td>, ...) > > > You could check whether you currently are in a certain element by > > > looking at doctree->top ()->element and do special things for > > > certain elements. > > > However looking at "The collapsing border model" I'm not sure > > > whether you can get away with leaving the dw/* code as it is and > > > just fiddling with the Style objects. > > > For example if you have > > > > > > <td>1</td><td>2</td> > > > > > > There currently is no way to get the style of the first <td> when > > > creating the style of the second <td> in StyleEngine - which you > > > would need to compute the thickness of the border between the two. > > > > Fully agreed. > > > > > Actually we can't play with the values of the Style object in > > > postprocessAttrs() as we like. > > > They must contain what the spec mentions as "computed > > > value". And as I read the spec, the computed value of e.g. > > > border-width does not depend on the value of border-collapse. > > > > I didn't know this ("computed value" requirement). Well, it > > defines better what's to be done if ever. > > > > > > > What *might* work is to take the Style object that StyleEngine gives > > > you and modify it in in case that border-collapse is set before passing > > > it to the table cell in src/table.cc:293. > > > > Do you mean as if it was a nonCssHint? > > I was afraid CSS would take precedence (i.e. if nonCssHint says > > margin is 0 and CSS says it's 20, I'd bet on the second one!). > > No, not via nonCssHints. I meant to directly modify the style before > giving it to the Textblock. Attached is a small patch to demonstrate > what I mean. > With some more work I think we could make it cover the most common > cases of the collapsing border model. > > > > > At this point, if we can set margin to zero for the "separate" > > model, and half the value for "collapsing" it would be quite an > > advance (in rendering). OTOH, it must be commented as a > > workaround because it's not the correct way to implement it. An > > implementation would need major surgery. > > > > > > > > Another approach is to make dw::table render its borders and > > > > margin, and only leave padding to the cell widget. > > > > > > Yes, that's the other way to do it. You could still reuse the border > > > drawing helper routines from style.cc. > > > Nevertheless it might be pretty complex. Not sure if it is really > > > worth it... > > > > Fully agreed. > > > > Most probably a full implementation is not worth ATM, given the > > small use cases out there. A partial workaround may help though. > > Yes, I think it would be reasonable to just cover the common cases > e.g a table with a 1px grid with a single color and style. After some more testing, and some tricks, it looks like common cases could get away with a good workaround. I'll keep working on it. -- Cheers Jorge.-

Oct. 15, 2010