- Dillo-dev - lists.mailman3.com

[hughsient@gmail.com: Please create an AppData file for Dillo]

by jcid＠dillo.org

Hi, Does somebody have experience with this? -- Cheers Jorge.-

May 28, 2014

dillo on NetBSD/evbarm(earmhf) with RaspberryPI

by jcid＠dillo.org

On Wed, May 14, 2014 at 10:12:03AM +0900, Jun Ebihara wrote: > I'm work for dillo with NetBSD/evbarm on RaspberryPI. > > On NetBSD/evbarm(earmhf), dillo fails to start up > because some HTML tables calclation problem. > With apply patch contains this article,Dillo works fine on my RaspberryPI. > > http://mail-index.netbsd.org/port-arm/2014/04/22/msg002386.html > > thanx. Thanks, we'll look at it ASAP. (BTW, I've already read the patch but I'm currently working on a few bugs in the image code). -- Cheers Jorge.-

May 14, 2014

dillo on NetBSD/evbarm(earmhf) with RaspberryPI

by jun＠soum.co.jp

I'm work for dillo with NetBSD/evbarm on RaspberryPI. On NetBSD/evbarm(earmhf), dillo fails to start up because some HTML tables calclation problem. With apply patch contains this article,Dillo works fine on my RaspberryPI. http://mail-index.netbsd.org/port-arm/2014/04/22/msg002386.html thanx. -- Jun Ebihara

May 14, 2014

Reddit regression

by onepoint＠starurchin.org

Sebastian Geerken wrote: > On Mon, May 05, 2014, Sebastian Geerken wrote: > > On Mo, Mai 05, 2014, Jeremy Henty wrote: > > > > > > Things are progressing nicely (I have already abandoned two problem > > > reports because they were fixed in the meantime) but there has been an > > > unfortunate regression - a few days ago Reddit comment threads started > > > thrashing the CPU. Example: > > > > > > http://www.reddit.com/r/haskell/comments/24rcf0/hourglass_a_new_simpler_tim… > > > > > > This is bad news for me as I follow a lot of subreddits. I hope it > > > can be fixed soon. If there is anything I can do to help find the > > > problem please say so. > > > > Aside from testing, perhaps simplification of pages, see attached > > example, which has all stripped off which is not neccessary to > > reproduce the bug. (It is largely intuition to get there, so perhaps > > it is best when I do this.) > > > > Expect a fix soon. > > Fixed. Marvellous! Regards, Jeremy Henty

May 7, 2014

Reddit regression

by sgeerken＠dillo.org

On Mon, May 05, 2014, Sebastian Geerken wrote: > On Mo, Mai 05, 2014, Jeremy Henty wrote: > > > > Things are progressing nicely (I have already abandoned two problem > > reports because they were fixed in the meantime) but there has been an > > unfortunate regression - a few days ago Reddit comment threads started > > thrashing the CPU. Example: > > > > http://www.reddit.com/r/haskell/comments/24rcf0/hourglass_a_new_simpler_tim… > > > > This is bad news for me as I follow a lot of subreddits. I hope it > > can be fixed soon. If there is anything I can do to help find the > > problem please say so. > > Aside from testing, perhaps simplification of pages, see attached > example, which has all stripped off which is not neccessary to > reproduce the bug. (It is largely intuition to get there, so perhaps > it is best when I do this.) > > Expect a fix soon. Fixed. Interestingly, the fix was in some rather old part of dw; the old implementation did not seem to work properly with extremes (e. g. <button> within <table>), so it is strange that this bug was invisble until now. Sebastian

May 6, 2014

Reddit regression

by sgeerken＠dillo.org

On Mo, Mai 05, 2014, Jeremy Henty wrote: > > Things are progressing nicely (I have already abandoned two problem > reports because they were fixed in the meantime) but there has been an > unfortunate regression - a few days ago Reddit comment threads started > thrashing the CPU. Example: > > http://www.reddit.com/r/haskell/comments/24rcf0/hourglass_a_new_simpler_tim… > > This is bad news for me as I follow a lot of subreddits. I hope it > can be fixed soon. If there is anything I can do to help find the > problem please say so. Aside from testing, perhaps simplification of pages, see attached example, which has all stripped off which is not neccessary to reproduce the bug. (It is largely intuition to get there, so perhaps it is best when I do this.) Expect a fix soon. Sebastian

May 5, 2014

Reddit regression

by onepoint＠starurchin.org

Things are progressing nicely (I have already abandoned two problem reports because they were fixed in the meantime) but there has been an unfortunate regression - a few days ago Reddit comment threads started thrashing the CPU. Example: http://www.reddit.com/r/haskell/comments/24rcf0/hourglass_a_new_simpler_tim… This is bad news for me as I follow a lot of subreddits. I hope it can be fixed soon. If there is anything I can do to help find the problem please say so. Regards, Jeremy Henty

May 5, 2014

character references, trailing ';', urls

by jcid＠dillo.org

On Mon, May 05, 2014 at 02:25:01AM +0000, eocene wrote: > Jorge wrote: > > On Mon, May 05, 2014 at 12:54:06AM +0000, eocene wrote: > > > Jorge wrote: > > > > On Sun, May 04, 2014 at 09:09:48PM +0000, eocene wrote: > > > > > This msg says that it was changed because it wasn't required under > > > > > certain conditions. HTML4 spec gives it as: > > > > > > > > > > Note. In SGML, it is possible to eliminate the final ";" after a > > > > > character reference in some cases (e.g., at a line break or > > > > > immediately before a tag). In other circumstances it may not be > > > > > eliminated (e.g., in the middle of a word). We strongly suggest > > > > > using the ";" in all cases to avoid problems with user agents that > > > > > require this character to be present. > > > > > > > > > > > > > > > ...and there's an "IIRC" in the msg that XHTML requires it. > > > > > > > > > > The HTML5 spec requires a terminating ';' in all cases. > > > > > > > > Then, it looks like requiring it again in this case may be > > > > the way to go (I seem to recall there were lots of unterminated NBSP). > > > > > > Are you saying always for html5, (probably) always for xhtml, and for > > > attributes with html4? > > > > I'm saying we should find a simple heuristic that copes with > > the current situation. > > If you want simple, I can just require it unconditionally and > find out what happens. Your first suggestion looks quite reasonable. Please try it and make some field tests. I'm currently working on the double imgbuf problem... -- Cheers Jorge.-

May 5, 2014

character references, trailing ';', urls

by eocene＠gmx.com

Jorge wrote: > On Mon, May 05, 2014 at 12:54:06AM +0000, eocene wrote: > > Jorge wrote: > > > On Sun, May 04, 2014 at 09:09:48PM +0000, eocene wrote: > > > > This msg says that it was changed because it wasn't required under > > > > certain conditions. HTML4 spec gives it as: > > > > > > > > Note. In SGML, it is possible to eliminate the final ";" after a > > > > character reference in some cases (e.g., at a line break or > > > > immediately before a tag). In other circumstances it may not be > > > > eliminated (e.g., in the middle of a word). We strongly suggest > > > > using the ";" in all cases to avoid problems with user agents that > > > > require this character to be present. > > > > > > > > > > > > ...and there's an "IIRC" in the msg that XHTML requires it. > > > > > > > > The HTML5 spec requires a terminating ';' in all cases. > > > > > > Then, it looks like requiring it again in this case may be > > > the way to go (I seem to recall there were lots of unterminated NBSP). > > > > Are you saying always for html5, (probably) always for xhtml, and for > > attributes with html4? > > I'm saying we should find a simple heuristic that copes with > the current situation. If you want simple, I can just require it unconditionally and find out what happens. > > > A long long time ago people thought that SGML was the final > > > solution, then XML, then HTML5, now they're looking for an > > > alternative technology to base the web upon... > > > > Where have they been talking about an alternative technology? > > I remember short ago, reading somewhere in the news that there > were funds and a call for people with expertise to work on > designing an alternative technology for the web (to try to tackle > the enormous amount of complexity full blown browsers have become > not to mention the disparate user experience this creates). I wish them luck. HTML5 is the most ridiculous possible document.

May 5, 2014

character references, trailing ';', urls

by jcid＠dillo.org

On Mon, May 05, 2014 at 12:54:06AM +0000, eocene wrote: > Jorge wrote: > > On Sun, May 04, 2014 at 09:09:48PM +0000, eocene wrote: > > > This msg says that it was changed because it wasn't required under > > > certain conditions. HTML4 spec gives it as: > > > > > > Note. In SGML, it is possible to eliminate the final ";" after a > > > character reference in some cases (e.g., at a line break or > > > immediately before a tag). In other circumstances it may not be > > > eliminated (e.g., in the middle of a word). We strongly suggest > > > using the ";" in all cases to avoid problems with user agents that > > > require this character to be present. > > > > > > > > > ...and there's an "IIRC" in the msg that XHTML requires it. > > > > > > The HTML5 spec requires a terminating ';' in all cases. > > > > Then, it looks like requiring it again in this case may be > > the way to go (I seem to recall there were lots of unterminated NBSP). > > Are you saying always for html5, (probably) always for xhtml, and for > attributes with html4? I'm saying we should find a simple heuristic that copes with the current situation. > > > A long long time ago people thought that SGML was the final > > solution, then XML, then HTML5, now they're looking for an > > alternative technology to base the web upon... > > Where have they been talking about an alternative technology? I remember short ago, reading somewhere in the news that there were funds and a call for people with expertise to work on designing an alternative technology for the web (to try to tackle the enormous amount of complexity full blown browsers have become not to mention the disparate user experience this creates). -- Cheers Jorge.-

May 5, 2014

character references, trailing ';', urls

by eocene＠gmx.com

Jorge wrote: > On Sun, May 04, 2014 at 09:09:48PM +0000, eocene wrote: > > This msg says that it was changed because it wasn't required under > > certain conditions. HTML4 spec gives it as: > > > > Note. In SGML, it is possible to eliminate the final ";" after a > > character reference in some cases (e.g., at a line break or > > immediately before a tag). In other circumstances it may not be > > eliminated (e.g., in the middle of a word). We strongly suggest > > using the ";" in all cases to avoid problems with user agents that > > require this character to be present. > > > > > > ...and there's an "IIRC" in the msg that XHTML requires it. > > > > The HTML5 spec requires a terminating ';' in all cases. > > Then, it looks like requiring it again in this case may be > the way to go (I seem to recall there were lots of unterminated NBSP). Are you saying always for html5, (probably) always for xhtml, and for attributes with html4? > A long long time ago people thought that SGML was the final > solution, then XML, then HTML5, now they're looking for an > alternative technology to base the web upon... Where have they been talking about an alternative technology?

May 5, 2014

character references, trailing ';', urls

by jcid＠dillo.org

On Sun, May 04, 2014 at 09:09:48PM +0000, eocene wrote: > I wrote: > > Jorge wrote: > > > AFAIR the original routine was written to require the trailing ';' > > > and it worked well for some time. Then more pages started to show > > > unterminated entities inside, and it got so annoying we decided to > > > make it more flexible and not to require the ';' when the entity > > > name was found (IIRC). > > > > Yeah, this is why I was considering just changing the get_attr case, > > but of course I don't want to make the code messy and complicated > > unless I need to. > > > > > It'd be good to find the reason for the change before reverting it. > > > I don't remember it now, but I do remember it was because the other way > > > started to be perceived as worst in some sense. > > > > > > Maybe GMANE has the mailing list archives... > > > > I guess I'll put some time into digging around. > > http://lists.dillo.org/pipermail/dillo-dev/2005-January/002502.html > > where we get the end of a conversation between Jorge and Matthias Franz. > > This msg says that it was changed because it wasn't required under > certain conditions. HTML4 spec gives it as: > > Note. In SGML, it is possible to eliminate the final ";" after a > character reference in some cases (e.g., at a line break or > immediately before a tag). In other circumstances it may not be > eliminated (e.g., in the middle of a word). We strongly suggest > using the ";" in all cases to avoid problems with user agents that > require this character to be present. > > > ...and there's an "IIRC" in the msg that XHTML requires it. > > The HTML5 spec requires a terminating ';' in all cases. Then, it looks like requiring it again in this case may be the way to go (I seem to recall there were lots of unterminated NBSP). A long long time ago people thought that SGML was the final solution, then XML, then HTML5, now they're looking for an alternative technology to base the web upon... -- Cheers Jorge.-

May 5, 2014

character references, trailing ';', urls

by eocene＠gmx.com

I wrote: > Jorge wrote: > > AFAIR the original routine was written to require the trailing ';' > > and it worked well for some time. Then more pages started to show > > unterminated entities inside, and it got so annoying we decided to > > make it more flexible and not to require the ';' when the entity > > name was found (IIRC). > > Yeah, this is why I was considering just changing the get_attr case, > but of course I don't want to make the code messy and complicated > unless I need to. > > > It'd be good to find the reason for the change before reverting it. > > I don't remember it now, but I do remember it was because the other way > > started to be perceived as worst in some sense. > > > > Maybe GMANE has the mailing list archives... > > I guess I'll put some time into digging around. http://lists.dillo.org/pipermail/dillo-dev/2005-January/002502.html where we get the end of a conversation between Jorge and Matthias Franz. This msg says that it was changed because it wasn't required under certain conditions. HTML4 spec gives it as: Note. In SGML, it is possible to eliminate the final ";" after a character reference in some cases (e.g., at a line break or immediately before a tag). In other circumstances it may not be eliminated (e.g., in the middle of a word). We strongly suggest using the ";" in all cases to avoid problems with user agents that require this character to be present. ...and there's an "IIRC" in the msg that XHTML requires it. The HTML5 spec requires a terminating ';' in all cases.

May 4, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by Johannes.Hofmann＠gmx.de

On Sat, May 03, 2014 at 01:32:35PM +0200, Sebastian Geerken wrote: > On Do, Mai 01, 2014, Johannes Hofmann wrote: > > On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote: > > > On Thu, May 01, 2014, Sebastian Geerken wrote: > > > > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > > > > Good! > > > > > > > > > > It works OK now. > > > > > > > > > > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > > > > There's no need to enable images, just the main page and remote CSS > > > > > will do. > > > > > > > > > > [2] http://www.emol.com/economia/ > > > > > > > > I cannot reproduce this: with revision 3637, the page looks fine, > > > > without flickering or CPU hogging. (Everything enabled, but turning > > > > off images has the same effect.) > > > > > > Updates: > > > > > > 1. I can neither reproduce it with standard configuration ("mv .dillo > > > .dillo_"). > > > > I still get something like that with http://slashdot.org > > This is working now. Unfortunately, the text is much too wide, which > is due to some CSS definitions "text-indent: 9999px".i (I don't know > whether this is a trick only working in some browsers, or whether > dillo is incomplete and should actually ignore this.) If you put this > in your ~/.dillo/style.css, slashdot becomes readable again: > > ---------------------------------------------------------------------- > .spinner .tag-server-busy.spinner, .fhitem-editor .tag-server-busy, > article footer .tag-server-busy, #edit-busy.busy.spinner, .synd .rss, > .synd .tw, .synd .fb, .synd .gp, ui-icon.pref a, .ui-icon.edit a, > .ui-icon.rss a, #user_bio .prefs a, #commentwrap .ui-icon.search { > text-indent:0px !important; > } > ---------------------------------------------------------------------- Cool, thank you! Regarding this "text-indent: 9999px", I've seen this a couple of time and it seems to be a common trick [1]. Cheers, Johannes [1] http://luigimontanez.com/2010/stop-using-text-indent-css-trick/

May 4, 2014

character references, trailing ';', urls

by eocene＠gmx.com

Jorge wrote: > On Sun, May 04, 2014 at 12:34:24AM +0000, eocene wrote: > > > > I was looking at how badly dillo handles something like: > > > > <a href="http://www.dillo.org?asdf&copy=3&micro=zxcv">link</a> > > > > It becomes a much more common problem with html5, which has a > > _lot_ more character references. > > > > > > I could perhaps stick an argument on the Html_parse_entity() in > > Html_get_attr2(), telling it to insist upon finding a ';'. > > > > If we still had cvs.auriga, I could dig through prehistory and > > try to see whether not demanding ';' termination was initially > > done with the strong belief that it was for the best overall > > (or maybe it was even inherited from gzilla), but we don't have > > cvs.auriga, and we don't have mailing list search working (not > > that that's generally very fun to dig through in any case). > > After all, maybe we should always insist upon proper termination. > > This heuristics are not simple. > > AFAIR the original routine was written to require the trailing ';' > and it worked well for some time. Then more pages started to show > unterminated entities inside, and it got so annoying we decided to > make it more flexible and not to require the ';' when the entity > name was found (IIRC). Yeah, this is why I was considering just changing the get_attr case, but of course I don't want to make the code messy and complicated unless I need to. > It'd be good to find the reason for the change before reverting it. > I don't remember it now, but I do remember it was because the other way > started to be perceived as worst in some sense. > > Maybe GMANE has the mailing list archives... I guess I'll put some time into digging around. Maybe it happens out there and I just don't hear about it, but I wonder why projects don't tend to keep track -- in some organized fashion by topic, like in a wiki or group of static web pages or something -- all of the decisions made on various issues and the reasoning surrounding them, since it's hard to remember details for years, people come and go, etc.

May 4, 2014

character references, trailing ';', urls

by jcid＠dillo.org

Hi, On Sun, May 04, 2014 at 12:34:24AM +0000, eocene wrote: > > I was looking at how badly dillo handles something like: > > <a href="http://www.dillo.org?asdf&copy=3&micro=zxcv">link</a> > > It becomes a much more common problem with html5, which has a > _lot_ more character references. > > > I could perhaps stick an argument on the Html_parse_entity() in > Html_get_attr2(), telling it to insist upon finding a ';'. > > If we still had cvs.auriga, I could dig through prehistory and > try to see whether not demanding ';' termination was initially > done with the strong belief that it was for the best overall > (or maybe it was even inherited from gzilla), but we don't have > cvs.auriga, and we don't have mailing list search working (not > that that's generally very fun to dig through in any case). > After all, maybe we should always insist upon proper termination. This heuristics are not simple. AFAIR the original routine was written to require the trailing ';' and it worked well for some time. Then more pages started to show unterminated entities inside, and it got so annoying we decided to make it more flexible and not to require the ';' when the entity name was found (IIRC). It'd be good to find the reason for the change before reverting it. I don't remember it now, but I do remember it was because the other way started to be perceived as worst in some sense. Maybe GMANE has the mailing list archives... (a similar situation happens with the question of e.g. allowing H1 inside the A element.). A bit of history: in the very beginning Dillo had strict parsing. The motto was not to try to fix bad HTML. After a few years dillo became more and more annoying (tag soup or HTML violations were not fixed), and the "Tag soup" pages looked really bad in it (hence the bug meter). At some point we had to change the policy because it was a lost war and dillo was becoming more and more unusable/irrelevant. At this point our policy is more or less: we try to render tag soup and use heuristics to do a good job on correcting usual problems, but haven't gave up on informing the user/author of all the HTML errors we found in the page. -- Cheers Jorge.-

May 4, 2014

character references, trailing ';', urls

by eocene＠gmx.com

I was looking at how badly dillo handles something like: <a href="http://www.dillo.org?asdf&copy=3&micro=zxcv">link</a> It becomes a much more common problem with html5, which has a _lot_ more character references. I could perhaps stick an argument on the Html_parse_entity() in Html_get_attr2(), telling it to insist upon finding a ';'. If we still had cvs.auriga, I could dig through prehistory and try to see whether not demanding ';' termination was initially done with the strong belief that it was for the best overall (or maybe it was even inherited from gzilla), but we don't have cvs.auriga, and we don't have mailing list search working (not that that's generally very fun to dig through in any case). After all, maybe we should always insist upon proper termination.

May 4, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Do, Mai 01, 2014, Johannes Hofmann wrote: > On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote: > > On Thu, May 01, 2014, Sebastian Geerken wrote: > > > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > > > Good! > > > > > > > > It works OK now. > > > > > > > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > > > There's no need to enable images, just the main page and remote CSS > > > > will do. > > > > > > > > [2] http://www.emol.com/economia/ > > > > > > I cannot reproduce this: with revision 3637, the page looks fine, > > > without flickering or CPU hogging. (Everything enabled, but turning > > > off images has the same effect.) > > > > Updates: > > > > 1. I can neither reproduce it with standard configuration ("mv .dillo > > .dillo_"). > > I still get something like that with http://slashdot.org This is working now. Unfortunately, the text is much too wide, which is due to some CSS definitions "text-indent: 9999px".i (I don't know whether this is a trick only working in some browsers, or whether dillo is incomplete and should actually ignore this.) If you put this in your ~/.dillo/style.css, slashdot becomes readable again: ---------------------------------------------------------------------- .spinner .tag-server-busy.spinner, .fhitem-editor .tag-server-busy, article footer .tag-server-busy, #edit-busy.busy.spinner, .synd .rss, .synd .tw, .synd .fb, .synd .gp, ui-icon.pref a, .ui-icon.edit a, .ui-icon.rss a, #user_bio .prefs a, #commentwrap .ui-icon.search { text-indent:0px !important; } ---------------------------------------------------------------------- Jorge: Do you still have problems with the other pages? Sebastian

May 3, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

Hi Jorge, On Fr, Mai 02, 2014, Jorge Arellano Cid wrote: > On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote: > > On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > > > [1] http://www.bolsadesantiago.com/index.aspx > > > > Works now, too; a problem with the "clear" attribute. (Actually rather > > similar to the previous problem.) > > After 3638, it restarted with the CPU hogs on [1] here. > > Now, if I disable remote CSS, load the URL, and afterwards > enable remote CSS, there's no problem. > > So there's clearly a timing issue upon CSS data arrival that > can explain why sometimes it doesn't happen. > > HTH. I neither can reproduce this, unfortunately. The change 3638 was not related to CPU hogging/layout flickering issues, but a rather simple resizing bug (in Wikipedia, the search field is now visible again, as an example). I'm currently working on slashdot.org; hopefully this is another symptom of the same bug. If not ... we'll see. Sebastian

May 2, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote: > On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > > but I can reproduce it with a simple test page (attached), so this > > > > should not take long, hopefully. > > > > > > Fixed. > > > > Good. > > > > Now, this one [1] hogs the CPU between two alternate layouts... > > (it also happens without the patch, but in a slighty different way). > > > > > > [1] http://www.bolsadesantiago.com/index.aspx > > Works now, too; a problem with the "clear" attribute. (Actually rather > similar to the previous problem.) After 3638, it restarted with the CPU hogs on [1] here. Now, if I disable remote CSS, load the URL, and afterwards enable remote CSS, there's no problem. So there's clearly a timing issue upon CSS data arrival that can explain why sometimes it doesn't happen. HTH. -- Cheers Jorge.-

May 2, 2014

More problem pages

by furaisanjin＠gmail.com

Hi. Yes, I see improvement. Thank you. Regards, furaisanjin

May 2, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Thu, May 01, 2014 at 10:55:36PM +0200, Sebastian Geerken wrote: > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote: > > > On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > > > > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > > > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > > > > but I can reproduce it with a simple test page (attached), so this > > > > > > should not take long, hopefully. > > > > > > > > > > Fixed. > > > > > > > > Good. > > > > > > > > Now, this one [1] hogs the CPU between two alternate layouts... > > > > (it also happens without the patch, but in a slighty different way). > > > > > > > > > > > > [1] http://www.bolsadesantiago.com/index.aspx > > > > > > Works now, too; a problem with the "clear" attribute. (Actually rather > > > similar to the previous problem.) > > > > Good! > > > > It works OK now. > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > There's no need to enable images, just the main page and remote CSS > > will do. > > > > [2] http://www.emol.com/economia/ > > I cannot reproduce this: with revision 3637, the page looks fine, > without flickering or CPU hogging. (Everything enabled, but turning > off images has the same effect.) Oh, it happens here... If I download the page and load it as a local file, there's no CPU hog nor flicker (nor CSS loaded), but from the HTTP URL, the three of them are present. -- Cheers Jorge.-

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Thu, May 01, 2014 at 11:11:22PM +0200, Johannes Hofmann wrote: > On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote: > > On Thu, May 01, 2014, Sebastian Geerken wrote: > > > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > > > Good! > > > > > > > > It works OK now. > > > > > > > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > > > There's no need to enable images, just the main page and remote CSS > > > > will do. > > > > > > > > [2] http://www.emol.com/economia/ > > > > > > I cannot reproduce this: with revision 3637, the page looks fine, > > > without flickering or CPU hogging. (Everything enabled, but turning > > > off images has the same effect.) > > > > Updates: > > > > 1. I can neither reproduce it with standard configuration ("mv .dillo > > .dillo_"). > > I still get something like that with http://slashdot.org Does [2] produce flickering among two layouts for you Johannes? Here it does. Checked twice. -- Cheers Jorge.-

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Do, Mai 01, 2014, Johannes Hofmann wrote: > On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote: > > On Thu, May 01, 2014, Sebastian Geerken wrote: > > > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > > > Good! > > > > > > > > It works OK now. > > > > > > > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > > > There's no need to enable images, just the main page and remote CSS > > > > will do. > > > > > > > > [2] http://www.emol.com/economia/ > > > > > > I cannot reproduce this: with revision 3637, the page looks fine, > > > without flickering or CPU hogging. (Everything enabled, but turning > > > off images has the same effect.) > > > > Updates: > > > > 1. I can neither reproduce it with standard configuration ("mv .dillo > > .dillo_"). > > I still get something like that with http://slashdot.org I can confirm this. I'll work on this. Sebastian

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by Johannes.Hofmann＠gmx.de

On Thu, May 01, 2014 at 11:02:54PM +0200, Sebastian Geerken wrote: > On Thu, May 01, 2014, Sebastian Geerken wrote: > > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > > Good! > > > > > > It works OK now. > > > > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > > There's no need to enable images, just the main page and remote CSS > > > will do. > > > > > > [2] http://www.emol.com/economia/ > > > > I cannot reproduce this: with revision 3637, the page looks fine, > > without flickering or CPU hogging. (Everything enabled, but turning > > off images has the same effect.) > > Updates: > > 1. I can neither reproduce it with standard configuration ("mv .dillo > .dillo_"). I still get something like that with http://slashdot.org Cheers, Johannes

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Thu, May 01, 2014, Sebastian Geerken wrote: > On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > > Good! > > > > It works OK now. > > > > > > This one [2] still hogs the CPU between two alternate layouts. > > There's no need to enable images, just the main page and remote CSS > > will do. > > > > [2] http://www.emol.com/economia/ > > I cannot reproduce this: with revision 3637, the page looks fine, > without flickering or CPU hogging. (Everything enabled, but turning > off images has the same effect.) Updates: 1. I can neither reproduce it with standard configuration ("mv .dillo .dillo_"). 2. Another bug: he headings are too narrow: this is something I noticed already (especially in wikipedia), and which I have on my list already. Sebastian

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Do, Mai 01, 2014, Jorge Arellano Cid wrote: > On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote: > > On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > > > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > > > but I can reproduce it with a simple test page (attached), so this > > > > > should not take long, hopefully. > > > > > > > > Fixed. > > > > > > Good. > > > > > > Now, this one [1] hogs the CPU between two alternate layouts... > > > (it also happens without the patch, but in a slighty different way). > > > > > > > > > [1] http://www.bolsadesantiago.com/index.aspx > > > > Works now, too; a problem with the "clear" attribute. (Actually rather > > similar to the previous problem.) > > Good! > > It works OK now. > > > This one [2] still hogs the CPU between two alternate layouts. > There's no need to enable images, just the main page and remote CSS > will do. > > [2] http://www.emol.com/economia/ I cannot reproduce this: with revision 3637, the page looks fine, without flickering or CPU hogging. (Everything enabled, but turning off images has the same effect.) Sebastian

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Thu, May 01, 2014 at 09:22:42PM +0200, Sebastian Geerken wrote: > On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > > but I can reproduce it with a simple test page (attached), so this > > > > should not take long, hopefully. > > > > > > Fixed. > > > > Good. > > > > Now, this one [1] hogs the CPU between two alternate layouts... > > (it also happens without the patch, but in a slighty different way). > > > > > > [1] http://www.bolsadesantiago.com/index.aspx > > Works now, too; a problem with the "clear" attribute. (Actually rather > similar to the previous problem.) Good! It works OK now. This one [2] still hogs the CPU between two alternate layouts. There's no need to enable images, just the main page and remote CSS will do. [2] http://www.emol.com/economia/ -- Cheers Jorge.-

May 1, 2014

More problem pages

by sgeerken＠dillo.org

And this one: On Do, Mai 01, 2014, furaisanjin wrote: > I also found a problematic page (http://gyao.yahoo.co.jp/ct/movie) and I tried > squeezing the page content as attached. > The attached page reads remote CSS pages. Trashing seems to be fixed now, but somehow the images overlap in an ugly way. I'll work on this. Sebastian

May 1, 2014

More problem pages

by sgeerken＠dillo.org

On Mi, Apr 30, 2014, Jeremy Henty wrote: > I updated and rebuilt a few minutes ago and though thecode is shaking > out nicely there are still some problems. > > Layout thrashes: > http://www.nature.com/nature/journal/v508/n7496_supp/full/508S66a.html > > CPU thrashes for a long time but eventually calms down: > http://www.sciencebasedmedicine.org/microwaves-and-nutrition/ Both don't trash anymore, but the first one still looks somewhat strange ... Sebastian

May 1, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Mi, Apr 30, 2014, Jorge Arellano Cid wrote: > On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > > but I can reproduce it with a simple test page (attached), so this > > > should not take long, hopefully. > > > > Fixed. > > Good. > > Now, this one [1] hogs the CPU between two alternate layouts... > (it also happens without the patch, but in a slighty different way). > > > [1] http://www.bolsadesantiago.com/index.aspx Works now, too; a problem with the "clear" attribute. (Actually rather similar to the previous problem.) Sebastian

May 1, 2014

More problem pages

by furaisanjin＠gmail.com

Hi all. I also found a problematic page (http://gyao.yahoo.co.jp/ct/movie) and I tried squeezing the page content as attached. The attached page reads remote CSS pages. Regards, furaisanjin

April 30, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Wed, Apr 30, 2014 at 05:16:07PM +0200, Sebastian Geerken wrote: > On Tue, Apr 29, 2014, Sebastian Geerken wrote: > > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > > > Most seems fixed, at least the CPU hogging. Still much space above, > > but I can reproduce it with a simple test page (attached), so this > > should not take long, hopefully. > > Fixed. Good. Now, this one [1] hogs the CPU between two alternate layouts... (it also happens without the patch, but in a slighty different way). [1] http://www.bolsadesantiago.com/index.aspx -- Cheers Jorge.-

April 30, 2014

More problem pages

by onepoint＠starurchin.org

I updated and rebuilt a few minutes ago and though thecode is shaking out nicely there are still some problems. Layout thrashes: http://www.nature.com/nature/journal/v508/n7496_supp/full/508S66a.html CPU thrashes for a long time but eventually calms down: http://www.sciencebasedmedicine.org/microwaves-and-nutrition/ Regards, Jeremy Henty

April 30, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Tue, Apr 29, 2014, Sebastian Geerken wrote: > On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan > > Most seems fixed, at least the CPU hogging. Still much space above, > but I can reproduce it with a simple test page (attached), so this > should not take long, hopefully. Fixed. Sebastian

April 30, 2014

Gamma error in picture scaling

by jcid＠dillo.org

On Wed, Apr 30, 2014 at 10:09:54AM +0200, Sebastian Geerken wrote: > Hi all! > > Visit <http://www.4p8.com/eric.brasseur/gamma.html> (you remember?) > and search for "dillo". Thanks for sharing the link. It produces some good feelings here. Congrats to all the team. :-) PS: FWIW, it made me remember a long long time ago, when Keith Packard let me knew dillo helped them to show in practice that the xserver was not the bottleneck in rendering speed. -- Cheers Jorge.-

April 30, 2014

Gamma error in picture scaling

by sgeerken＠dillo.org

Hi all! Visit <http://www.4p8.com/eric.brasseur/gamma.html> (you remember?) and search for "dillo". Sebastian

April 30, 2014

H1's inside A's

by tautolog＠gmail.com

I see the anchor as an inline element and the header as a block element, and spanning inlines across blocks makes me cringe. However, an anchor has a very important meaning because of its function. Its loss is different than the loss of an em tag, for example. I am in the strict camp, but would overlook breaking a spec in this case. Ben > On Apr 29, 2014, at 4:03 PM, Dennis New <dennisn at dennisn.linuxd.org> wrote: > > From: Dennis New <dennisn at dennisn.linuxd.org> > Newsgroups: gmane.comp.web.dillo.devel > Subject: Re: H1's inside A's > Date: Tue, 29 Apr 2014 19:01:33 -0400 > X-Newsreader: Sylpheed 3.2.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) > >> On 30 Apr 2014 00:34:58 +0200, Sebastian Geerken wrote: >>> On Di, Apr 29, 2014, Johannes Hofmann wrote: >>>> On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: >>>> I know technically the H1 heading tags aren't allowed between >>>> A../A, and Dillo rightfully complains about this: >>>> >>>> "a" is not allowed to contain "h1". -- closing "a" >>>> >>>> But it seems like an innocent tiny mistake. Can't dillo linkify >>>> anyways, in addition to throwing this error? Currently the >>>> link-information is lost and only accessibly if I manually view >>>> the source and copy-paste it. Other browsers (i.e. webkitgtk >>>> based ones) do this, which is quite useful. >>> >>> I agree, that it would be nice to have those links working - while >>> still reporting it as an error. >>> I didn't check yet how complicated it would be to get things working >>> that way. >> >> Would this not collide with rules to implicitely close <a> in HTML >> (not XHTML!)? >> >> Anyway: The attached page behaves the same way in dillo as in Firefox. > > My webkitgtk browser behaves differently -- it doesn't automatically > close the first "nowhere" link, until the next one starts. The DOM tree > looks like: > > http://imgur.com/4OHrNHN > > By the way, I came across this case on a website that wanted to have > the titles to stories as links, and bigger text size, something like: > > <a href="story1"><h1>Story One Title</h1></a> > > And in such cases, dillo won't render the link. The html rule banning > such constructs doesn't seem obvious to me, so I imagine there are many > such cases floating around. H1 kinda is just a <font size="+1"> with a > <br> at the end :P. > > >> OTOH, w3m closes the first, but not the second <a> implicitely. Do >> you have other test cases? >> >> (I haven't looked in detail at the specs, and it may be different in >> HTML 5.) > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

April 29, 2014

H1's inside A's

by dennisn＠dennisn.linuxd.org

From: Dennis New <dennisn at dennisn.linuxd.org> Newsgroups: gmane.comp.web.dillo.devel Subject: Re: H1's inside A's Date: Tue, 29 Apr 2014 19:01:33 -0400 X-Newsreader: Sylpheed 3.2.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) On 30 Apr 2014 00:34:58 +0200, Sebastian Geerken wrote: > On Di, Apr 29, 2014, Johannes Hofmann wrote: > > On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: > > > I know technically the H1 heading tags aren't allowed between > > > A../A, and Dillo rightfully complains about this: > > > > > > "a" is not allowed to contain "h1". -- closing "a" > > > > > > But it seems like an innocent tiny mistake. Can't dillo linkify > > > anyways, in addition to throwing this error? Currently the > > > link-information is lost and only accessibly if I manually view > > > the source and copy-paste it. Other browsers (i.e. webkitgtk > > > based ones) do this, which is quite useful. > > > > I agree, that it would be nice to have those links working - while > > still reporting it as an error. > > I didn't check yet how complicated it would be to get things working > > that way. > > Would this not collide with rules to implicitely close <a> in HTML > (not XHTML!)? > > Anyway: The attached page behaves the same way in dillo as in Firefox. My webkitgtk browser behaves differently -- it doesn't automatically close the first "nowhere" link, until the next one starts. The DOM tree looks like: http://imgur.com/4OHrNHN By the way, I came across this case on a website that wanted to have the titles to stories as links, and bigger text size, something like: <a href="story1"><h1>Story One Title</h1></a> And in such cases, dillo won't render the link. The html rule banning such constructs doesn't seem obvious to me, so I imagine there are many such cases floating around. H1 kinda is just a <font size="+1"> with a <br> at the end :P. > OTOH, w3m closes the first, but not the second <a> implicitely. Do > you have other test cases? > > (I haven't looked in detail at the specs, and it may be different in > HTML 5.)

April 29, 2014

H1's inside A's

by sgeerken＠dillo.org

On Di, Apr 29, 2014, Johannes Hofmann wrote: > On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: > > I know technically the H1 heading tags aren't allowed between A../A, > > and Dillo rightfully complains about this: > > > > "a" is not allowed to contain "h1". -- closing "a" > > > > But it seems like an innocent tiny mistake. Can't dillo linkify anyways, > > in addition to throwing this error? Currently the link-information is > > lost and only accessibly if I manually view the source and copy-paste > > it. Other browsers (i.e. webkitgtk based ones) do this, which is quite > > useful. > > I agree, that it would be nice to have those links working - while > still reporting it as an error. > I didn't check yet how complicated it would be to get things working > that way. Would this not collide with rules to implicitely close <a> in HTML (not XHTML!)? Anyway: The attached page behaves the same way in dillo as in Firefox. OTOH, w3m closes the first, but not the second <a> implicitely. Do you have other test cases? (I haven't looked in detail at the specs, and it may be different in HTML 5.) Sebastian

April 29, 2014

H1's inside A's

by Johannes.Hofmann＠gmx.de

On Sun, Apr 27, 2014 at 10:57:09PM -0400, Dennis New wrote: > I know technically the H1 heading tags aren't allowed between A../A, > and Dillo rightfully complains about this: > > "a" is not allowed to contain "h1". -- closing "a" > > But it seems like an innocent tiny mistake. Can't dillo linkify anyways, > in addition to throwing this error? Currently the link-information is > lost and only accessibly if I manually view the source and copy-paste > it. Other browsers (i.e. webkitgtk based ones) do this, which is quite > useful. I agree, that it would be nice to have those links working - while still reporting it as an error. I didn't check yet how complicated it would be to get things working that way. Cheers, Johannes

April 29, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Fr, Apr 25, 2014, Jorge Arellano Cid wrote: > On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > > On Tue, Apr 22, 2014, Jorge Arellano Cid wrote: > > > Today I saw commit 3626, and checked whether the pages I see to > > > produce redraw storms and CPU hogs were gone, and... no :-P > > > > > > I got one of them and worked reducing it to try to produce a good > > > test case, that's the attachment. If you open it with embedded CSS > > > disabled, it's OK, then enable it and voila: redraw storm and CPU > > > hog. > > > > > > I hope this helps the cause. Please let me know whether you can > > > work on it, or give me some clues to try to start digging further. > > > > Has been fixed now (really stupid bug). > > Good. > > BTW, I've come to like this kind of bugs along the way, a > simple change, great benefit, and no major work involved. I'd prefer not to have such bugs in the first place. :-) > OTOH, there're still some problems. The original URL [1] still > hogs the CPU. This time the page keeps increasing its length on > an on ("ad eternum"). > > When loaded with remote CSS disabled, it behaves OK (like the > reduced test case). If you enable remote CSS, the page length > tarts increasing (press End key and check the scrollbar). > > [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan Most seems fixed, at least the CPU hogging. Still much space above, but I can reproduce it with a simple test page (attached), so this should not take long, hopefully. Also, sizes are generally not perfect, but that will be cleaned a bit later (general redesign of widget sizes). Sebastian

April 29, 2014

H1's inside A's

by dennisn＠dennisn.linuxd.org

I know technically the H1 heading tags aren't allowed between A../A, and Dillo rightfully complains about this: "a" is not allowed to contain "h1". -- closing "a" But it seems like an innocent tiny mistake. Can't dillo linkify anyways, in addition to throwing this error? Currently the link-information is lost and only accessibly if I manually view the source and copy-paste it. Other browsers (i.e. webkitgtk based ones) do this, which is quite useful.

April 28, 2014

New/fixed Toolbar icons

by jcid＠dillo.org

On Fri, Apr 25, 2014 at 11:37:58PM +0200, Christophe Lincoln wrote: > > Yep, > > > Icons page updated :) > > Thanks for the link to slitaz.org :-) > > And sorry for te double post, I thought the first one was rejected due > to attached file size. It got stuck pending for aproval. -- Cheers Jorge.-

April 26, 2014

Nanolinux distro with Dillo

by rogerx.oss＠gmail.com

> On Fri, Apr 25, 2014 at 06:33:32PM +0200, Georg Potthast wrote: >I just want to mention that I made a small (14 MB footprint) Linux distro >called "Nanolinux" which includes Dillo as the browser plus many FLTK apps: >https://sourceforge.net/projects/nanolinux/ > >Georg Ah. The days when a complete GUI Desktop could be loaded using only 49MB of memory and 22.7MB of hard disk space! The performance of NanoLinux reminded me of MenuetOS and KolibriOS, but having at least VI! Last year, Seamonkey/Mozilla was blazing fast on my shiny new 64Bit 8 x i7-3770K w/ 4 cores having 32 GB of RAM, with an NVidia GTX 670. Now Seamonkey loads and performs like any other browser on previous x86 archs! There should be laws against writing websites with bloat and code wasting energy! ;-) -- Roger http://rogerx.freeshell.org/

April 25, 2014

New/fixed Toolbar icons

by pankso＠slitaz.org

Yep, > Icons page updated :) Thanks for the link to slitaz.org :-) And sorry for te double post, I thought the first one was rejected due to attached file size. Best regards, - Christophe

April 25, 2014

New/fixed Toolbar icons

by eocene＠gmx.com

Christophe wrote: > Please find attached the screenshot of SliTaz Toolbar icons and her > are the new pixmaps.slitaz.h + fixed pixmaps.tango.h: Icons page updated :)

April 25, 2014

Nanolinux distro with Dillo

by mailbox＠georgpotthast.de

I just want to mention that I made a small (14 MB footprint) Linux distro called "Nanolinux" which includes Dillo as the browser plus many FLTK apps: https://sourceforge.net/projects/nanolinux/ Georg

April 25, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by jcid＠dillo.org

On Fri, Apr 25, 2014 at 11:19:33AM +0200, Sebastian Geerken wrote: > On Tue, Apr 22, 2014, Jorge Arellano Cid wrote: > > Today I saw commit 3626, and checked whether the pages I see to > > produce redraw storms and CPU hogs were gone, and... no :-P > > > > I got one of them and worked reducing it to try to produce a good > > test case, that's the attachment. If you open it with embedded CSS > > disabled, it's OK, then enable it and voila: redraw storm and CPU > > hog. > > > > I hope this helps the cause. Please let me know whether you can > > work on it, or give me some clues to try to start digging further. > > Has been fixed now (really stupid bug). Good. BTW, I've come to like this kind of bugs along the way, a simple change, great benefit, and no major work involved. OTOH, there're still some problems. The original URL [1] still hogs the CPU. This time the page keeps increasing its length on an on ("ad eternum"). When loaded with remote CSS disabled, it behaves OK (like the reduced test case). If you enable remote CSS, the page length tarts increasing (press End key and check the scrollbar). [1] http://www.bolsadesantiago.com/theme/resumeninstrumentoexterno.aspx?NEMO=lan -- Cheers Jorge.-

April 25, 2014

[jcid@dillo.org: Commit 3626. Redraw problems]

by sgeerken＠dillo.org

On Tue, Apr 22, 2014, Jorge Arellano Cid wrote: > Today I saw commit 3626, and checked whether the pages I see to > produce redraw storms and CPU hogs were gone, and... no :-P > > I got one of them and worked reducing it to try to produce a good > test case, that's the attachment. If you open it with embedded CSS > disabled, it's OK, then enable it and voila: redraw storm and CPU > hog. > > I hope this helps the cause. Please let me know whether you can > work on it, or give me some clues to try to start digging further. Has been fixed now (really stupid bug). Sebastian

April 25, 2014