- Dillo-dev - lists.mailman3.com

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