- Dillo-dev - lists.mailman3.com

CPU hog bug with https?
by jcid＠dillo.org May 19, 2016

May 19, 2016

Hi, If I start current dillo with [1], an https dialog springs (untrusted certificate). Answering "continue" gets into a CPU hog, answering "cancel" allows reading the page with no problems. FWIW, I've done that lots of times with other sites, and this is the first CPU hog I get accross. [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 -- Cheers Jorge.-

4 9

New tab colours - suggestion
by nick＠linicks.net May 18, 2016

May 18, 2016

I find that when opening a new tab, the colour of it changes to a sort of turquoise colour - which suggests it is in the background. I do find it confusing - could it be possible to change the working tab to the default grey and the background tabs to the turquoise colour? Just a suggestion. If it doesn't seem to bother anybody else, can someone point me to the area of code so I can do a local patch. Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

2 8

Firefox bookmarks.html convertor for Dillo
by nick＠linicks.net May 14, 2016

May 14, 2016

Hi all, Attached is a short perl script that converts FF bookmarks.html (which can be exported within FF itself) to Dillo format bm.txt. Simple to use, and the code has brief instructions. The only thing I am not sure about is if different versions of FF use the same bookmarks.html format. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

1 1

"ok" for unnested body
by genoob＠yandex.com May 11, 2016

May 11, 2016

Hello! I'm a noob, so I'm sorry if this is actually not an issue, but I've searched and haven't found anything on this. When creating a simple list using `ul` (I've replaced < > with `` in order to avoid html parsing by some readers) tags I accidentally placed it after `/body``/html` and to my surprise It wasn't marked as an html error and the data was correctly displayed, jus like it would be had the list been placed inside the `html``body` `/body``/html` tags. Unnesting `li` from `ul` however displayed nesting problem, but only referring to the `li` being out of `ul` or `ol` tags, not from it being unnested from `html` `body`. I realize my explanation might be a little confusing at this point, so this is what I mean: I put it on bpaste so this message wouldn't be flagged as spam: https://bpaste.net/show/ed1374304997 And this is a screenshot of the data being displayed and getting a thumbs-up from the browser in case its relevant: http://i.imgur.com/d1f9Pv9.png I'd like to report this in case it's a bug(invalid html being marked valid), however if it's a valid html you can disregard/exclude this message from the list with no hard feelings. I'm using dillo-3.0.5-r1 by the way. I'm sorry if this was confusing and wasted your time. In case you need more info on my system I'm happy to help however I can. And thanks for maintaining such a nice project (It really helped me a lot thus far). Cheers!

2 2

Bug in meta tag refresh code [with cause]
by nick＠linicks.net May 10, 2016

May 10, 2016

I have been looking at this for about 5 hours now, and it has fried my brain. Reading the code, and then reading the email thread about depreciated meta tag 'refresh', I agree with Dillo's actions. But what I found was that on some sites (mine included), if there was a tag: <meta http-equiv="refresh" content="15" /> Dillo reports and the warning message reports: The author wanted you to go _here_ after 10 seconds. What happens now is the link (_here_) gets appended with the refresh value, so for example: www.example.com/refesh.html becomes: www.example.com/10 (or 15 or whatever the refresh value is). I have found that if the meta tag is right: <meta http-equiv="refresh" content="5;URL='./index.html'" /> then the code creates the right URL (but it's not seen as no warning is given. html.cc from line 3218 if the meta tag refresh is correct HTML on the web page, mr_url returns the correct path to the refresh. If it isn't, then mr_url returns the value of the refresh - which fubars the warning messages link. I tested this running dillo from the commandline with this insertion and testing the correct and wrong meta tags: } /* Skip to anything after "URL=" or ";" if "URL=" is not found */ if ((p = dStriAsciiStr(content, "url="))) content = p + strlen("url="); else if ((p = strstr(content, ";"))) content = p + strlen(";"); /* Handle the case of a quoted URL */ if (*content == '"' || *content == '\'') { if ((p = strchr(content + 1, *content))) mr_url = dStrndup(content + 1, p - content - 1); else mr_url = dStrdup(content + 1); } else { mr_url = dStrdup(content); } //nick printf ("%s\n", mr_url); new_url = a_Html_url_new(html, mr_url, NULL, 0); // new_url = a_Html_url_new(html, ".", NULL, 0); Not being very good with C++, I can't work out what goes wrong here - but it looks like that if 'URL=' or';' isn't found, then the code still looks for quotes - which does something to the string? I have two pages you can test on - one with the proper meta tag, and one with out: http://irpi.linicks.net:8080/static_simple.html <- good http://fishpi.linicks.net:8081/static_simple.html <- bad - that shows the bug If possible view both with that printf I put in - you can see what mr_url returns. Phew* Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

4 6

image overlaps text
by sgeerken＠dillo.org May 9, 2016

May 9, 2016

Hi Alexander and others, On Mo, Mai 09, 2016, Alexander Voigt wrote: > Dear Sebastian, > > I think one of your recent commits (probably 4543:3cb86de1861a) > introduced a problem with hyphenation. See for example the rendering > of > > debian.org This commit fixes a problem which has hidden another problem which now shows up. I'm working on it. If you want a halfway usable recent version, stick to revision 4542. Sebastian

1 0

Minor bug in test/cookies.c
by nick＠linicks.net May 1, 2016

May 1, 2016

Hi Jorge, I saw the two minor fixes you done today - here's another: :~/slackbuilds/dillo/hg/dillo$ grep -Rin "} if" * test/cookies.c:426: } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

2 1

dillo redraws part II
by jcid＠dillo.org April 29, 2016

April 29, 2016

Hi there, Just committed the second part of this patch. It further reduces the number of redraws (see details in hg). The debug messages are active and will be shut after a brief testing period. Screen drawing *feels* cleaner here! :-) YMMV. -- Cheers Jorge.-

1 0

https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo
by sgeerken＠dillo.org April 24, 2016

April 24, 2016

Hi! Since we do not have a tracking system, I suggest a new thread for every issue, with some identifier (e. g. a URL) as subject. Please focus on regressions: bugs not present in dillo 3.0.5. As for <https://www.google.com/search?ie=UTF-8&oe=UTF-8&q=dillo>, the problem are floating inline-blocks (see Johannes' posting and my answer). Floats positioned side by-side are not an issue for the next release, so I see two possibilities: 1. Leave it as it is, and start on an other positioning after the next release. 2. Deactivate inline-blocks for the next release, and re-activate as soon as side-by-side positioning of floats is implemented. This way, dillo 3.1 would render Google like 3.0.5. The latter is rather simple: diff -r 7c2e27119432 src/html.cc --- a/src/html.cc Sun Apr 24 12:21:07 2016 +0200 +++ b/src/html.cc Sun Apr 24 13:23:10 2016 +0200 @@ -4036,7 +4036,7 @@ Html_display_block(html); break; case DISPLAY_INLINE_BLOCK: - Html_display_inline_block(html); + //Html_display_inline_block(html); break; case DISPLAY_LIST_ITEM: Html_display_listitem(html); What do you think? Sebastian

2 1

GROWS fixes
by sgeerken＠dillo.org April 23, 2016

April 23, 2016

Hi! After the recent changes, dillo handles 'height' specially for tables and textblocks: now, it is not possible anymore that the height of table or a textblock is less than the inherent height. This fixes - <http://forums.thinkbroadband.com> and - <https://linicks.net/AnAdIc/> (looks as with dillo 3.0.5). For tables, dillo behaves the same way as Firefox; for textblock not quite, but somewhat similar as dillo 3.0.5. This means that there is no regression, and that texblock heights may be worked on after the next release. Sebastian

3 2