Dillo-dev

Download

By thread

dillo-dev@mailman3.com

2 participants
11672 messages

Startup time of the latest dev versions.

by nick＠linicks.net

Hi John, On Sat, 3 Sep 2016 21:12:46 +0300 John Found <johnfound at asm32.info> wrote: > I am using Dillo as a help viewer of my IDE, because it has really > short startup times and pressing F1 I get instant access to the > documentation. > > Recently I tried to compile and use the recent development versions > from the hg repository, because of the recent changes in the > rendering and the general improvements in the browser. > > But unfortunately, the startup time seems to be increased and now I > have to wait 2..3 seconds for browser to start and to show my help > files. Is that not fast? You blink and miss it. > Is such slow startup time side effect of some changes that will be > fixed some day, or it is kind of compromise, because of other > improvements and this way will persists in the project from now on? > > Or (what is pretty possible) I messed something with the compilation? What ./configure line do you use, and what install options? (I use make install-strip) 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"

Sept. 3, 2016

Startup time of the latest dev versions.

by johnfound＠asm32.info

I am using Dillo as a help viewer of my IDE, because it has really short startup times and pressing F1 I get instant access to the documentation. Recently I tried to compile and use the recent development versions from the hg repository, because of the recent changes in the rendering and the general improvements in the browser. But unfortunately, the startup time seems to be increased and now I have to wait 2..3 seconds for browser to start and to show my help files. Is such slow startup time side effect of some changes that will be fixed some day, or it is kind of compromise, because of other improvements and this way will persists in the project from now on? Or (what is pretty possible) I messed something with the compilation? -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Sept. 3, 2016

Get Dillo to honour target=_blank

by jcid＠dillo.org

On Mon, Aug 29, 2016 at 11:53:30AM +0100, Nick Warne wrote: > Hi Jorge, > > On Sun, 28 Aug 2016 21:57:21 -0300 > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > The trick is to submit pressing the middle button, that way the data > > remains in the old tab! > > Duh! I must have read the help file 20 times and still missed that. > Thanks, works a treat! I knew it was somewhere and didn't find it either... ;) It's under the Help|Tabs section, as you found. A minor refactoring of the help text looks like a good idea. -- Cheers Jorge.-

Aug. 29, 2016

Get Dillo to honour target=_blank

by jcid＠dillo.org

Hi, On Mon, Aug 29, 2016 at 01:29:39PM +0300, Martin Atukunda wrote: > Hi dillo-dev, > > While reading, incidentally, news.ycombinator.com, I came across this: > > https://dev.to/ben/the-targetblank-vulnerability-by-example I remember long ago we decided to avoid it for resons similar to popup windows, and some others probably, but the details left me... Thanks for the link. -- Cheers Jorge.-

Aug. 29, 2016

Get Dillo to honour target=_blank

by nick＠linicks.net

Hi Martin, On Mon, 29 Aug 2016 13:29:39 +0300 Martin Atukunda <matlads at gmail.com> wrote: > Hi dillo-dev, > > While reading, incidentally, news.ycombinator.com, I came across this: > > https://dev.to/ben/the-targetblank-vulnerability-by-example > Interesting! I use it a lot, but having read that page and then this one: https://css-tricks.com/use-target_blank/ Basically, if a user _wants_ to open a link in a new tab, it is up to them! I have removed all my target="_blank" stuff now, and will not use it again. 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"

Aug. 29, 2016

Get Dillo to honour target=_blank

by nick＠linicks.net

Hi Jorge, On Sun, 28 Aug 2016 21:57:21 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > The trick is to submit pressing the middle button, that way the data > remains in the old tab! Duh! I must have read the help file 20 times and still missed that. Thanks, works a treat! 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"

Aug. 29, 2016

Get Dillo to honour target=_blank

by matlads＠gmail.com

Hi dillo-dev, While reading, incidentally, news.ycombinator.com, I came across this: https://dev.to/ben/the-targetblank-vulnerability-by-example Cheers, - Martin - On 29 August 2016 at 03:57, Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi, > > On Sat, Aug 27, 2016 at 04:28:54PM +0100, Nick Warne wrote: > > Hi all, > > > > How easy (or hard) would it be to get Dillo to honour the URL/FORM > > directive 'target="_blank" to get URL/CGI data returned in a new tab? > > > > I ahve looked at the code, seeing as Dillo already has tabs, but I just > > don't get C++ classes and stuff, and wouldn't know where to begin. > > > > The reason for asking this is if one has a form with a lot of data that > > needs processing, once submitted the data gets returned to the parent > > page... if there is a mistake, then you need to go back to the form, > > and as Dillo doesn't keep the previous page data, you have to fill it > > all in again. By diverting the output to a new tab, the previous parent > > window remains the same, ready for editing and processing again. > > The trick is to submit pressing the middle button, that way the data > remains in the old tab! > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 29, 2016

Get Dillo to honour target=_blank

by jcid＠dillo.org

Hi, On Sat, Aug 27, 2016 at 04:28:54PM +0100, Nick Warne wrote: > Hi all, > > How easy (or hard) would it be to get Dillo to honour the URL/FORM > directive 'target="_blank" to get URL/CGI data returned in a new tab? > > I ahve looked at the code, seeing as Dillo already has tabs, but I just > don't get C++ classes and stuff, and wouldn't know where to begin. > > The reason for asking this is if one has a form with a lot of data that > needs processing, once submitted the data gets returned to the parent > page... if there is a mistake, then you need to go back to the form, > and as Dillo doesn't keep the previous page data, you have to fill it > all in again. By diverting the output to a new tab, the previous parent > window remains the same, ready for editing and processing again. The trick is to submit pressing the middle button, that way the data remains in the old tab! -- Cheers Jorge.-

Aug. 29, 2016

Get Dillo to honour target=_blank

by nick＠linicks.net

Hi all, How easy (or hard) would it be to get Dillo to honour the URL/FORM directive 'target="_blank" to get URL/CGI data returned in a new tab? I ahve looked at the code, seeing as Dillo already has tabs, but I just don't get C++ classes and stuff, and wouldn't know where to begin. The reason for asking this is if one has a form with a lot of data that needs processing, once submitted the data gets returned to the parent page... if there is a mistake, then you need to go back to the form, and as Dillo doesn't keep the previous page data, you have to fill it all in again. By diverting the output to a new tab, the previous parent window remains the same, ready for editing and processing again. 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"

Aug. 27, 2016

Underscores not drawn in pre with background color

by nick＠linicks.net

On Wed, 17 Aug 2016 14:09:32 -0300 Jorge Arellano Cid <jcid at dillo.org> wrote: > > > Is that the only symbol that disappears? > > > Try a line like: !"#$%&/()=?¡-_{}^[]~.,;:|° > > > and check whether those are displayed. > > > > When I open the attached page with dillo, only the underscore > > disappears. All other characters are visible. > > Maybe, https://bbs.archlinux.org/viewtopic.php?id=125749 OK, I just messed around with that, and all works fine in the console. I have attached a slightly different version of the test case, with a few lower case g's stuck in there. The tails of the g's show fine in Dillo, but if you then view the source, the underscore appears maybe 1 or 2 pixels lower than the bottom of the tails - looks like it goes outside the character bounding box when rendered in HTML? 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"

Aug. 17, 2016

Underscores not drawn in pre with background color

by jcid＠dillo.org

On Wed, Aug 17, 2016 at 09:07:39AM +0200, Alexander Voigt wrote: > Hi Jorge, > > > Is that the only symbol that disappears? > > Try a line like: !"#$%&/()=?¡-_{}^[]~.,;:|° > > and check whether those are displayed. > > When I open the attached page with dillo, only the underscore > disappears. All other characters are visible. Maybe, https://bbs.archlinux.org/viewtopic.php?id=125749 -- Cheers Jorge.-

Aug. 17, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

Hi Jorge, > Is that the only symbol that disappears? > Try a line like: !"#$%&/()=?¡-_{}^[]~.,;:|° > and check whether those are displayed. When I open the attached page with dillo, only the underscore disappears. All other characters are visible. Best regards, Alex On Tue, Aug 16, 2016 at 11:23:23PM -0300, Jorge Arellano Cid wrote: > On Fri, Jul 22, 2016 at 05:58:44PM +0200, Alexander Voigt wrote: > > > > IMHO, this is somehow related to the default fonts set in dillorc or > > > > the global set system fonts. > > > > > > +1 > > > > > > A wild shot, but a cheap one, so I'd also try that first. Change your > > > default font to something else and see what happens. > > > > > > Also check FLTK's test programs (IIRC there's a symbols one, and another > > > that's useful to try fonts). > > > > > > If FLTK also has problems check the video driver (older kernel, > > > older/different video driver, GRUB CLI parameter). > > > > I have not set any specific font in dillorc, so the default setting is > > used. However, when I change the monospace font to > > > > font_monospace="Monospace" > > > > then the rendering problem disappears and the underscores are > > correctly displayed. When I change to > > > > font_monospace="DejaVu Sans Mono" > > > > the rendering problem is present, i.e. the underscores are not > > displayed. > > I've tried all of them here and they work. > > Devuan Jessie, amd64, Linux 4.5.0-2-amd64 (fltk-1.3.1). > ------ > > Is that the only symbol that disappears? > Try a line like: !"#$%&/()=?¡-_{}^[]~.,;:|° > and check whether those are displayed. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Aug. 17, 2016

Underscores not drawn in pre with background color

by jcid＠dillo.org

On Fri, Jul 22, 2016 at 05:58:44PM +0200, Alexander Voigt wrote: > > > IMHO, this is somehow related to the default fonts set in dillorc or > > > the global set system fonts. > > > > +1 > > > > A wild shot, but a cheap one, so I'd also try that first. Change your > > default font to something else and see what happens. > > > > Also check FLTK's test programs (IIRC there's a symbols one, and another > > that's useful to try fonts). > > > > If FLTK also has problems check the video driver (older kernel, > > older/different video driver, GRUB CLI parameter). > > I have not set any specific font in dillorc, so the default setting is > used. However, when I change the monospace font to > > font_monospace="Monospace" > > then the rendering problem disappears and the underscores are > correctly displayed. When I change to > > font_monospace="DejaVu Sans Mono" > > the rendering problem is present, i.e. the underscores are not > displayed. I've tried all of them here and they work. Devuan Jessie, amd64, Linux 4.5.0-2-amd64 (fltk-1.3.1). ------ Is that the only symbol that disappears? Try a line like: !"#$%&/()=?¡-_{}^[]~.,;:|° and check whether those are displayed. -- Cheers Jorge.-

Aug. 17, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

Hi Michael, On Mon, Aug 15, 2016 at 09:28:15AM +0200, Michael Bäuerle wrote: > Please check whether the problem is related to this FLTK STR I created > some days ago: > <http://www.fltk.org/str.php?L3321> Adding Xft.antialias: true Xft.hinting: true Xft.autohint: false Xft.hintstyle: hintfull to ~/.Xdefaults and running xrdb ~/.Xdefaults dillo underscore.html does not solve the problem on my machine, sorry. Best regards, Alex On Mon, Aug 15, 2016 at 09:28:15AM +0200, Michael Bäuerle wrote: > Nick Warne wrote: > > On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > > > > On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > > > > > On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > > > Mono" have the same problem. It is probably because of the > > > > > > characters height - the next row of text overwrites the > > > > > > previous. The question is whether this is because of Dillo or > > > > > > because of FLTK. > > > > > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > > > > > This looks like a bug in the font: > > > > > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > > > > > (you need to scroll down a bit). > > > > > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > > > later. > > > > > > > > OK, I get the same issue. But if you change the font size, thus: > > > > > > > > <pre style="background-color: white; > > > > font-size:105%;">softpoint_with_block() { > > > > > > > > the underscores are visible. > > > > > > Huh! Strangely the underscores become visible with font size set to > > > 95% too! Only 100% renders them invisible? > > > > OK, turning off 'use embedded CSS' makes them visible too. > > > > CSS parsing error? > > Please check whether the problem is related to this FLTK STR I created > some days ago: > <http://www.fltk.org/str.php?L3321> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Aug. 15, 2016

Underscores not drawn in pre with background color

by michael.baeuerle＠stz-e.de

Nick Warne wrote: > On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > > On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > > > > On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > > Mono" have the same problem. It is probably because of the > > > > > characters height - the next row of text overwrites the > > > > > previous. The question is whether this is because of Dillo or > > > > > because of FLTK. > > > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > > > This looks like a bug in the font: > > > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > > > (you need to scroll down a bit). > > > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > > later. > > > > > > OK, I get the same issue. But if you change the font size, thus: > > > > > > <pre style="background-color: white; > > > font-size:105%;">softpoint_with_block() { > > > > > > the underscores are visible. > > > > Huh! Strangely the underscores become visible with font size set to > > 95% too! Only 100% renders them invisible? > > OK, turning off 'use embedded CSS' makes them visible too. > > CSS parsing error? Please check whether the problem is related to this FLTK STR I created some days ago: <http://www.fltk.org/str.php?L3321>

Aug. 15, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Reverting reverts: ----------------- There were a few unfortunate commits that break the work detailed in this thread, so basically we're getting back to r4648, keeping the patches that don't make regressions in this test suite [1], by reverting #4651 and #4652, and putting #4653 momentarily "on hold". In a nutshell: Results Table .-------.--------.------.-----------.-----------------------.-----.-----. | | BTG | test | pravda.ru | 4ta.html | VT | PV | | | render | t.* | #1 | #2 | Girl | footb. | horos.| | | |-------|--------|------|-----------|-----------------------|-----|-----| |d4657 | ok | ok | ok | ok | ok | ok | ok | ok | ok | |d4652 | ok | ok | x a | x ic| ok | x l | x d | x n | ok | |d4651 | ok | ok | x a | x ic| ok | x l | x d | x n | ok | |d4648 | ok | ok | ok | ok | ok | ok | ok | ok | ok | '-----------------------------------'-----------------------------'-----' As you can see, d4648 and d4657 pass all the tests. Technical details in "hg log -v" and [1]. Hereafter we'll use this testsuite [1] to assert committed code at least passes this known bugset. Besides the test suite, I did extensive tests with the sites I usually visit, with no regressions (BTW, a three year old bug or so was catched in the process). This was meant to be a moment of joy for dillo users, so please give these patches extensive tests/surfing and report back how they work for you! (good and bad). Hint: I found a near 100% speed increase with a heavy site I use (Back/Forward test). [1] http://www.dillo.org/test/4648/test-suite.v1.txt -- Cheers Jorge.-

Aug. 4, 2016

Successful build on OS X

by gears_of_war__＠hotmail.com

Dillo builds an runs on mac os x 10.5.8 (ppc32) with fltk-1.3.3. It runs great!

Aug. 4, 2016

Underscores not drawn in pre with background color

by nick＠linicks.net

On Sat, 23 Jul 2016 11:25:18 +0100 Nick Warne <nick at linicks.net> wrote: > On Sat, 23 Jul 2016 11:13:19 +0100 > Nick Warne <nick at linicks.net> wrote: > > > On Sat, 23 Jul 2016 10:01:59 +0100 > > Nick Warne <nick at linicks.net> wrote: > > > > > On Fri, 22 Jul 2016 20:12:59 +0300 > > > John Found <johnfound at asm32.info> wrote: > > > > > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > > Mono" have the same problem. It is probably because of the > > > > characters height - the next row of text overwrites the > > > > previous. The question is whether this is because of Dillo or > > > > because of FLTK. > > > > > > > > The same font, used in Firefox renders correctly. > > > > > > This looks like a bug in the font: > > > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > > > (you need to scroll down a bit). > > > > > > I have version 2.34 installed - will see if I can reproduce it > > > later. > > > > OK, I get the same issue. But if you change the font size, thus: > > > > <pre style="background-color: white; > > font-size:105%;">softpoint_with_block() { > > > > the underscores are visible. > > Huh! Strangely the underscores become visible with font size set to > 95% too! Only 100% renders them invisible? OK, turning off 'use embedded CSS' makes them visible too. CSS parsing error? 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"

July 23, 2016

Underscores not drawn in pre with background color

by nick＠linicks.net

On Sat, 23 Jul 2016 11:13:19 +0100 Nick Warne <nick at linicks.net> wrote: > On Sat, 23 Jul 2016 10:01:59 +0100 > Nick Warne <nick at linicks.net> wrote: > > > On Fri, 22 Jul 2016 20:12:59 +0300 > > John Found <johnfound at asm32.info> wrote: > > > > > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans > > > Mono" have the same problem. It is probably because of the > > > characters height - the next row of text overwrites the previous. > > > The question is whether this is because of Dillo or because of > > > FLTK. > > > > > > The same font, used in Firefox renders correctly. > > > > This looks like a bug in the font: > > > > http://dejavu-fonts.org/wiki/Bugs/Archived > > > > (you need to scroll down a bit). > > > > I have version 2.34 installed - will see if I can reproduce it > > later. > > OK, I get the same issue. But if you change the font size, thus: > > <pre style="background-color: white; > font-size:105%;">softpoint_with_block() { > > the underscores are visible. Huh! Strangely the underscores become visible with font size set to 95% too! Only 100% renders them invisible? 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"

July 23, 2016

Underscores not drawn in pre with background color

by nick＠linicks.net

On Sat, 23 Jul 2016 10:01:59 +0100 Nick Warne <nick at linicks.net> wrote: > On Fri, 22 Jul 2016 20:12:59 +0300 > John Found <johnfound at asm32.info> wrote: > > > > > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans Mono" > > have the same problem. It is probably because of the characters > > height - the next row of text overwrites the previous. The question > > is whether this is because of Dillo or because of FLTK. > > > > The same font, used in Firefox renders correctly. > > This looks like a bug in the font: > > http://dejavu-fonts.org/wiki/Bugs/Archived > > (you need to scroll down a bit). > > I have version 2.34 installed - will see if I can reproduce it later. OK, I get the same issue. But if you change the font size, thus: <pre style="background-color: white; font-size:105%;">softpoint_with_block() { the underscores are visible. 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"

July 23, 2016

Underscores not drawn in pre with background color

by nick＠linicks.net

On Fri, 22 Jul 2016 20:12:59 +0300 John Found <johnfound at asm32.info> wrote: > > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans Mono" > have the same problem. It is probably because of the characters > height - the next row of text overwrites the previous. The question > is whether this is because of Dillo or because of FLTK. > > The same font, used in Firefox renders correctly. This looks like a bug in the font: http://dejavu-fonts.org/wiki/Bugs/Archived (you need to scroll down a bit). I have version 2.34 installed - will see if I can reproduce it later. 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"

July 23, 2016

Underscores not drawn in pre with background color

by johnfound＠asm32.info

On Fri, 22 Jul 2016 17:58:44 +0200 Alexander Voigt <Hole.destructor at gmx.de> wrote: > I have not set any specific font in dillorc, so the default setting is > used. However, when I change the monospace font to > > font_monospace="Monospace" > > then the rendering problem disappears and the underscores are > correctly displayed. When I change to > > font_monospace="DejaVu Sans Mono" > > the rendering problem is present, i.e. the underscores are not > displayed. > > Best regards, > Alex > Confirmed. I am using "Liberation Mono", but with "DejaVu Sans Mono" have the same problem. It is probably because of the characters height - the next row of text overwrites the previous. The question is whether this is because of Dillo or because of FLTK. The same font, used in Firefox renders correctly. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

July 22, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

> > IMHO, this is somehow related to the default fonts set in dillorc or > > the global set system fonts. > > +1 > > A wild shot, but a cheap one, so I'd also try that first. Change your > default font to something else and see what happens. > > Also check FLTK's test programs (IIRC there's a symbols one, and another > that's useful to try fonts). > > If FLTK also has problems check the video driver (older kernel, > older/different video driver, GRUB CLI parameter). I have not set any specific font in dillorc, so the default setting is used. However, when I change the monospace font to font_monospace="Monospace" then the rendering problem disappears and the underscores are correctly displayed. When I change to font_monospace="DejaVu Sans Mono" the rendering problem is present, i.e. the underscores are not displayed. Best regards, Alex On Fri, Jul 22, 2016 at 11:43:14AM -0400, Jorge Arellano Cid wrote: > On Fri, Jul 22, 2016 at 06:19:21PM +0300, John Found wrote: > > On Fri, 22 Jul 2016 10:17:38 +0200 > > Alexander Voigt <Hole.destructor at gmx.de> wrote: > > > > > > > > then maybe it is an FLTK issue? I'm using > > > > > > Debian Jessie GNU/Linux 4.6.0-0.bpo.1-amd64 > > > FLTK 1.3.1 > > > > > > Best regards, > > > Alex > > > > > > > IMHO, this is somehow related to the default fonts set in dillorc or > > the global set system fonts. > > +1 > > A wild shot, but a cheap one, so I'd also try that first. Change your > default font to something else and see what happens. > > Also check FLTK's test programs (IIRC there's a symbols one, and another > that's useful to try fonts). > > If FLTK also has problems check the video driver (older kernel, > older/different video driver, GRUB CLI parameter).

July 22, 2016

Underscores not drawn in pre with background color

by jcid＠dillo.org

On Fri, Jul 22, 2016 at 06:19:21PM +0300, John Found wrote: > On Fri, 22 Jul 2016 10:17:38 +0200 > Alexander Voigt <Hole.destructor at gmx.de> wrote: > > > > > then maybe it is an FLTK issue? I'm using > > > > Debian Jessie GNU/Linux 4.6.0-0.bpo.1-amd64 > > FLTK 1.3.1 > > > > Best regards, > > Alex > > > > IMHO, this is somehow related to the default fonts set in dillorc or > the global set system fonts. +1 A wild shot, but a cheap one, so I'd also try that first. Change your default font to something else and see what happens. Also check FLTK's test programs (IIRC there's a symbols one, and another that's useful to try fonts). If FLTK also has problems check the video driver (older kernel, older/different video driver, GRUB CLI parameter). -- Cheers Jorge.-

July 22, 2016

Underscores not drawn in pre with background color

by johnfound＠asm32.info

On Fri, 22 Jul 2016 10:17:38 +0200 Alexander Voigt <Hole.destructor at gmx.de> wrote: > > then maybe it is an FLTK issue? I'm using > > Debian Jessie GNU/Linux 4.6.0-0.bpo.1-amd64 > FLTK 1.3.1 > > Best regards, > Alex > IMHO, this is somehow related to the default fonts set in dillorc or the global set system fonts. > On Thu, Jul 21, 2016 at 08:14:20PM -0400, Jorge Arellano Cid wrote: > > Hi Alexander, > > > > On Thu, Jul 21, 2016 at 09:50:22PM +0200, Alexander Voigt wrote: > > > Hi Dillo developers, > > > > > > I stumbled upon a page with a lot of code snippets wrapped in a <pre> > > > block, where Dillo seems to have a rendering problem: Underscores `_' > > > are not drawn. I stripped down this real-world-example to the > > > attached minimal html file which reproduces the problem: > > > > > > The page should render as follows: > > > > > > ============================================ > > > softpoint_with_block() { > > > { echo ""; } | ./softpoint.x leshouches > > > } > > > ============================================ > > > > > > However, in the development version of Dillo it renders as follows: > > > > > > ============================================ > > > softpoint with block() { > > > { echo ""; } | ./softpoint.x leshouches > > > } > > > ============================================ > > > > > > As you can see, the underscores in the function softpoint_with_block() > > > are not drawn in Dillo. > > > > > > However, the underscores are drawn correcty if you > > > > > > * remove the style="..." specification from the <pre> block or > > > > > > * remove the line > > > > > > { echo ""; } | ./softpoint.x leshouches > > > > > > from the <pre> block content. > > > > The attached example renders OK here. > > Maybe someone else can reproduce it. > > > > -- > > Cheers > > Jorge.- > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

July 22, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

Hi Jorge, then maybe it is an FLTK issue? I'm using Debian Jessie GNU/Linux 4.6.0-0.bpo.1-amd64 FLTK 1.3.1 Best regards, Alex On Thu, Jul 21, 2016 at 08:14:20PM -0400, Jorge Arellano Cid wrote: > Hi Alexander, > > On Thu, Jul 21, 2016 at 09:50:22PM +0200, Alexander Voigt wrote: > > Hi Dillo developers, > > > > I stumbled upon a page with a lot of code snippets wrapped in a <pre> > > block, where Dillo seems to have a rendering problem: Underscores `_' > > are not drawn. I stripped down this real-world-example to the > > attached minimal html file which reproduces the problem: > > > > The page should render as follows: > > > > ============================================ > > softpoint_with_block() { > > { echo ""; } | ./softpoint.x leshouches > > } > > ============================================ > > > > However, in the development version of Dillo it renders as follows: > > > > ============================================ > > softpoint with block() { > > { echo ""; } | ./softpoint.x leshouches > > } > > ============================================ > > > > As you can see, the underscores in the function softpoint_with_block() > > are not drawn in Dillo. > > > > However, the underscores are drawn correcty if you > > > > * remove the style="..." specification from the <pre> block or > > > > * remove the line > > > > { echo ""; } | ./softpoint.x leshouches > > > > from the <pre> block content. > > The attached example renders OK here. > Maybe someone else can reproduce it. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 22, 2016

Underscores not drawn in pre with background color

by jcid＠dillo.org

Hi Alexander, On Thu, Jul 21, 2016 at 09:50:22PM +0200, Alexander Voigt wrote: > Hi Dillo developers, > > I stumbled upon a page with a lot of code snippets wrapped in a <pre> > block, where Dillo seems to have a rendering problem: Underscores `_' > are not drawn. I stripped down this real-world-example to the > attached minimal html file which reproduces the problem: > > The page should render as follows: > > ============================================ > softpoint_with_block() { > { echo ""; } | ./softpoint.x leshouches > } > ============================================ > > However, in the development version of Dillo it renders as follows: > > ============================================ > softpoint with block() { > { echo ""; } | ./softpoint.x leshouches > } > ============================================ > > As you can see, the underscores in the function softpoint_with_block() > are not drawn in Dillo. > > However, the underscores are drawn correcty if you > > * remove the style="..." specification from the <pre> block or > > * remove the line > > { echo ""; } | ./softpoint.x leshouches > > from the <pre> block content. The attached example renders OK here. Maybe someone else can reproduce it. -- Cheers Jorge.-

July 22, 2016

Underscores not drawn in pre with background color

by Hole.destructor＠gmx.de

Hi Dillo developers, I stumbled upon a page with a lot of code snippets wrapped in a <pre> block, where Dillo seems to have a rendering problem: Underscores `_' are not drawn. I stripped down this real-world-example to the attached minimal html file which reproduces the problem: The page should render as follows: ============================================ softpoint_with_block() { { echo ""; } | ./softpoint.x leshouches } ============================================ However, in the development version of Dillo it renders as follows: ============================================ softpoint with block() { { echo ""; } | ./softpoint.x leshouches } ============================================ As you can see, the underscores in the function softpoint_with_block() are not drawn in Dillo. However, the underscores are drawn correcty if you * remove the style="..." specification from the <pre> block or * remove the line { echo ""; } | ./softpoint.x leshouches from the <pre> block content. Best regards, Alex

July 21, 2016

ImageMagick for SVG and other image types?: Pseudo Code

by jgaffney＠lawrenceville.org

I was going to attempt a sort of proof-of-concept patch, and still include a mix of code and pseudo-code below, but see that a change would be required in the way a_Misc_get_content_type_from_data() (in src/misc.[hc]) is called from elsewhere in Dillo -- but this would not require much change, since, as far as I can see, a_Misc_get_content_type_from_data() is called from only two places in the rest of the source code. The problem is that the data being parsed is from a Dstr, but only the str and the value of the len members of this Dstr are passed to a_Misc_get_content_type_from_data(), so that the Dstr is not modifiable. If a pointer to the Dstr were passed instead, it would be modifiable, which would then allow for conversion of image types other than GIF, PNG, and JPG to be converted to PNG for the purposes of display by replacing the original Dstr data with the data for the converted image. (This would mean that Dillo would be using and caching the PNG into which the original image was converted, rather than the original, but this is only proposed as an interim means of at least displaying other, currently unsupported, image types.) In a mix of code and pseudo-code: Along with the configure.ac block to use the Magick++-config utility to test for the Magick++ library and its version and to set the corresponding compiler and linker flags, and a call in main() to Magick::InitializeMagick(NULL), replace the current src/misc.c block starting at line 161 } else if (Size >= 2 && !strncmp(p, "\xff\xd8", 2)) { /* JPEG has the first 2 bytes set to 0xffd8 in BigEndian - looking * at the character representation should be machine independent. */ Type = DT_IMAGE_JPG; st = 0; /* Text */ } else { /* Heuristic for "text/plain" ... */ with something like } else if (Size >= 2 && !strncmp(p, "\xff\xd8", 2)) { /* JPEG has the first 2 bytes set to 0xffd8 in BigEndian - looking * at the character representation should be machine independent. */ Type = DT_IMAGE_JPG; st = 0; } else if (ConvertImage(ModifiablePtrToData, & DataLen)) { Type = DT_IMAGE_PNG; st = 0; /* Text */ } else { /* Heuristic for "text/plain" ... */ and adding to src/misc.h #include "miscconv.hh" with two new files: a header miscconv.hh with #ifndef __MISCCONV_HH__ #define __MISCCONV_HH__ #ifdef __cplusplus extern "C" { #endif #include <stdlib.h> int ConvertImage (void *, size_t *); #ifdef __cplusplus } #endif #endif and, for the source file miscconv.cc, something like #include "miscconv.hh" #include <Magick++.h> extern "C" int ConvertImage ( char * Data, size_t * Size ) { try { Magick :: Blob blob ( Data, Size ), PngBlob; // This ctor will throw an exception if Data is not image data: Magick :: Image image ( blob ); // From the magic used by the `file' command, it seems that identifying SVG // data by its magic would be pretty involved, and as far as I can tell // there is no way in Magick++ to check the type of the image data // (including whether it is image data to begin with) without constructing // an Image -- which, if the data is any kind of image recognized by // ImageMagick, seems automatically to convert the image to some internal // format. And in consequence it seems that any security policies, such as // limits on image sizes or types, would have to be set via the local // ImageMagick policy (in the ImageMagick policy.xml in /etc or the like). // Now that the Image has been constructed, if desired its native type can be // determined by, e.g., Image::format(). Otherwise, one can // just proceed with the conversion of images of any format. // The following call could also throw an exception: image . write ( & PngBlob, "PNG"); // And now we just need to rewire things for the converted image: Code here to deallocate Data, allocate a new pointer according to PngBlob.length(), replace Data with the new pointer, and copy PngBlob.data() to it. } catch ( Magick :: Exception & e ) { // The ImageMagick docs cover the rather wide array of possible warnings and // errors, and a MSG could be crafted from these, but for the present purposes // any exception means the failure to return a displayable PNG. Code to do whatever with e.what() ... return 0; } return 1; } John Gaffney <jgaffney at lawrenceville.org> writes: > At this point Dillo supports the display of GIF, PNG, and JPG, but SVG > is used heavily by sites like, for example, Wikipedia. Has the > Magick++ library in ImageMagick been considered for supporting these > other image formats? The FLTK people seem enthusiastic about the > Imago library in spite of its alpha state of development; librsvg, > which looks, at least to my untutored eye, like it requires a fair > amount of voodoo to use, is apparently no longer actively supported > and would at any rate only provide SVG support; but ImageMagick is > pretty standard with Linux distributions, and the Magick++ interface > makes conversions from any format to PNG for the purposes of display > extremely easy. In src/misc.c, at the end of the image part of the > else-if ladder in a_Misc_get_content_type_from_data(), one could add > another "rung" that uses Data and Size to create a Magick::Blob, and > from this a Magick::Image, then use Magick::Image.write() to write > this to another Magick::Blob of type PNG, and then replace Data and > Size with those of the resulting Magick::Blob. A try-catch block > would catch the cases where Data is not an image. Altogether this > sort of "cheat" would require very few lines of code to implement. > And the Magick++-config utility could supply the needed -D..., -I..., > -l... flags to the configure script. > > I'm not suggesting this is an ideal long-term solution, but in the > interim would at least allow the display of other image types. > > The most recent mention of this on the mailing list seems to be > Jorge's indication on 22 April 2016 that > > No, there's no SVG image support in dillo yet. > > It should not be hard to implement though, but it needs an effort > similar to GIF or PNG or JPEG code. Patch welcomed! ;) > > But surely someone has thought of ImageMagick before. Are there > objections to using it? And if so, maybe a flag could be set by the > configure script to conditionally compile this in for those who want > it? (If this is pursued, the configure script should probably also > check that the version of ImageMagick is recent enough to have been > patched against that serious exploit in just this sort of conversion > code.) > > A test program shows that the invocation of ImageMagick and > conversions really are as simple as the steps outlined above. But I > would be happy to make an attempt at a patch, if you don't mind this > being undertaken by an amateur. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 20, 2016

ImageMagick for SVG and other image types?

by jgaffney＠lawrenceville.org

At this point Dillo supports the display of GIF, PNG, and JPG, but SVG is used heavily by sites like, for example, Wikipedia. Has the Magick++ library in ImageMagick been considered for supporting these other image formats? The FLTK people seem enthusiastic about the Imago library in spite of its alpha state of development; librsvg, which looks, at least to my untutored eye, like it requires a fair amount of voodoo to use, is apparently no longer actively supported and would at any rate only provide SVG support; but ImageMagick is pretty standard with Linux distributions, and the Magick++ interface makes conversions from any format to PNG for the purposes of display extremely easy. In src/misc.c, at the end of the image part of the else-if ladder in a_Misc_get_content_type_from_data(), one could add another "rung" that uses Data and Size to create a Magick::Blob, and from this a Magick::Image, then use Magick::Image.write() to write this to another Magick::Blob of type PNG, and then replace Data and Size with those of the resulting Magick::Blob. A try-catch block would catch the cases where Data is not an image. Altogether this sort of "cheat" would require very few lines of code to implement. And the Magick++-config utility could supply the needed -D..., -I..., -l... flags to the configure script. I'm not suggesting this is an ideal long-term solution, but in the interim would at least allow the display of other image types. The most recent mention of this on the mailing list seems to be Jorge's indication on 22 April 2016 that No, there's no SVG image support in dillo yet. It should not be hard to implement though, but it needs an effort similar to GIF or PNG or JPEG code. Patch welcomed! ;) But surely someone has thought of ImageMagick before. Are there objections to using it? And if so, maybe a flag could be set by the configure script to conditionally compile this in for those who want it? (If this is pursued, the configure script should probably also check that the version of ImageMagick is recent enough to have been patched against that serious exploit in just this sort of conversion code.) A test program shows that the invocation of ImageMagick and conversions really are as simple as the steps outlined above. But I would be happy to make an attempt at a patch, if you don't mind this being undertaken by an amateur.

July 18, 2016

Good news in dillo's rendering!

by sgeerken＠dillo.org

On Mi, Jul 13, 2016, Jorge Arellano Cid wrote: > GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. > This is a very powerful and flexible concept whose design allows > floats, layers (and absolutes in the future, and more). It has > proven very fast so far, even without optimizations. It's actually called "SRDOP" ("Size Requisitions Depending On Positions). See - http://www.dillo.org/dw/html/dw-grows.html - http://www.dillo.org/dw/html/dw-size-request-pos.html As to current bugs, most of them fall into either one category: 1. missing rendering updates: this results in rendering errors (wrong positions etc.); 2. inefficient (too many) updates: this results in CPU hogging. You see that these are complementary. :-) The focus should now be on the first category, and I've still at least one open issue here, which is neither addressed by Jorge's patches. Problems from the second category are best fixed after this. Sebastian

July 17, 2016

cppcheck on Dillo source

by sgeerken＠dillo.org

On Di, Jul 12, 2016, Jorge Arellano Cid wrote: > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > in some patches I have, which also silence cppcheck. But maybe the > original construct was meant for adding more options (like absolute > positioned floats), but those may end in a third floats array, so I'm > not sure. Is it safe to use the above construct, or should I leave it > as is? OOFFloatsMgr only deals with floats, so it should be safe. However, I'd like to keep assertNotReached() there, to make debugging easier. Sebastian

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Hi there, OK, the patches were just committed, there're four instead of two and the last one has the full test suite results inside the comments in Hg. These patches work very well so far. The idea is to get your testing and feedback. I still have some ideas and cleanups for them, but that will take more time, and this set is already working and very fast. Enjoy! PD: a bit overworked Jorge. :-P -- Cheers Jorge.-

July 17, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

On Wed, Jul 13, 2016 at 01:37:12PM -0400, Jorge Arellano Cid wrote: > [...] > @Sebastian: Problem #10 is not related to GROWS2, but a three > year old bug discovered during the tests. So let's get it done > first. How to reproduce it: Go to [2], wait a bit for most images > to load, then use "find text" to find the "re-re" string, scroll > a bit downwards to find the image and center it. Go back then > forward; no image! But dillo thinks it *is* there so move the > cursor to the center of the page and you'll see the hand cursor, > wait for the tooltip and drag it a bit downwards to the right. > Dillo will repaint from the image data. > Bisect shows the bug was introduced by #2863. Attached is a > simple concept patch for it. Please review/fix/commit, as I don't > know the updated invariants of resize idle. > > > [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html > [2] http://tinyurl.com/huvf6pn As usual, the attachment arrives later... ;) -- Cheers Jorge.-

July 13, 2016

Good news in dillo's rendering!

by jcid＠dillo.org

Hi there, Here go some good news. Originally I was to send this internally to the core devs, but as we've benefitted from the feedback of active users in the list, and their experiences with the patches (before/afterwards), on the sites they usually browse, it looks like a good idea to do it again. Since June 6, when this thread [1] was started by Sebastian, I've been investigating/working in problems related to it. This led to some extensive rendering tests that catched a laundry list of problems with our current tip (#4643 today). This is a list with brief explanations, taken from the testing data tables I've gathered so far: Problems: 1: overwrites text with images. 2: crops images (aspect ratio). 3: different layout. 4: overwrites text with text float. 5: overwrites text with text. 6: CPU HOG with: tmp.num.html, tmp.num.small.html 7: Missing page sections (sometimes works for the same page). 8: Small images cut in two sometimes ("ESP", "CRO", ...) 9: Wrong aspect ratio for images (text line height) 10: Page drawn with offset (but browser thinks other section is on screen). There're test cases for each one, and most of them were taken and reduced from real pages. Having reduced test cases is good, reduced and isolated tests is better, but the good news is that I have a couple of patches that solve all of them! I'm not saying dillo will be error-free hereafter, but that the root of a whole family of problems has been found and fixed, and this will make future testing much simpler. GROWS2 is the "Grand Redesign Of Widget Sizes" v2 by Sebastian. This is a very powerful and flexible concept whose design allows floats, layers (and absolutes in the future, and more). It has proven very fast so far, even without optimizations. Well the patches are two simple but deep changes in the way markSizeChange() and queueResize() interact. The patch idea is close to graph coverage recursions (with pruning), applied to the widget tree. I'd like to commit it, upload the test suite I'm using, and show the testing data tables I've gathered so everyone can check it with their use cases and report on it. @Sebastian: May I, or would you prefer to review them before? (the patches are the "middle ground" you mentioned. Solve the dw hog problems at dw level, not in the parser, and reuse code you've already seen. A couple of days should be enough to review) @Sebastian: Problem #10 is not related to GROWS2, but a three year old bug discovered during the tests. So let's get it done first. How to reproduce it: Go to [2], wait a bit for most images to load, then use "find text" to find the "re-re" string, scroll a bit downwards to find the image and center it. Go back then forward; no image! But dillo thinks it *is* there so move the cursor to the center of the page and you'll see the hand cursor, wait for the tooltip and drag it a bit downwards to the right. Dillo will repaint from the image data. Bisect shows the bug was introduced by #2863. Attached is a simple concept patch for it. Please review/fix/commit, as I don't know the updated invariants of resize idle. [1] http://lists.dillo.org/pipermail/dillo-dev/2016-June/010887.html [2] http://tinyurl.com/huvf6pn -- Cheers Jorge.-

July 13, 2016

cppcheck on Dillo source

by sgeerken＠dillo.org

> > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. > > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I've looked at this, and this is rather Johannes' code. I'm not sure whether negative may cause troubles. Sebastian

July 12, 2016

cppcheck on Dillo source

by nick＠linicks.net

On Tue, 12 Jul 2016 15:02:31 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi Nick, > > On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck > > on Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and > > attached it as a plain text file. > > Thanks for the report. I personally didn't know of cppcheck. I have used it in the past - a few years ago, but as I say I was bored so found something to do... > We have used several code cleanup tools in the past and we usually > honour them as sometimes they catch important flaws. > > A bunch of patches was just committed. You may peruse them with > "hg log -vp" for the details/explanations. Good stuff. I watch the dillo hg site anyway as I like to see (and learn) all this C++ stuff. > It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer > Sebastian to double check it. > > Not committed. I looked and looked at that, but alas, don't understand why it's wrong/right :) > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) > > Memory leak: eit3 > > Done. > > AFAICS, this is a false positive. > Patched to please cppcheck anyway. Yes, even I got that, but wasn't sure. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) > > Possible null pointer dereference: vloat > > Well, the code should never reach there. > Not changed. > > @Sebastian, BTW, coincidentally I'm using something like: > > SortedFloatsVector *list; > list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; > Float *vloat = list->get (getFloatIndexFromSubRef (ref)); > > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) > > Uninitialized variable: X in md5.c > > Untouched: I'm not md5 savvy. Maybe corvid. Nor am I. I looked a lot at that code, and K[] whatever doesn't seem to be declared anywhere (with my little knowledge). Strange GCC doesn't squinny on that one? 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"

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi, On Sat, Jul 09, 2016 at 03:28:25PM +0100, Nick Warne wrote: > On Sat, 9 Jul 2016 12:35:10 +0100 > Nick Warne <nick at linicks.net> wrote: > > > Hi all, > > > > While waiting for the Tour De France to start on TV, I ran cppcheck on > > Dillo source for something to do - a few errors were picked up! > > > > I have compacted the findings (with two comments from me)and attached > > it as a plain text file. > > > > Keep up the great work guys and thanks! > > > > Nick > > OK, updating cppcheck to 1.74, I ran it again. A new error appears, but > I don't know if it is a false positive, as I still don't really > understand C++ (but do get the logic of function calls vs void etc.: > > Checking ../../slackbuilds/dillo/hg/dillo/src/ui.cc... > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:574]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > [../../slackbuilds/dillo/hg/dillo/src/ui.cc:588]: (error) Return value > of allocation function 'make_filemenu_button' is not stored. > > Now, the call is: > > make_filemenu_button(); > > to: > > Fl_Widget *UI::make_filemenu_button() > > which returns (btn) > > so is that correct? Where does (btn) go in the calling function - or > what does it do? Patch committed. It wasn't necessary anymore. Most probably it remained from a time when it was used. Now they are stored in local variables so it's safe to make the function void. -- Cheers Jorge.-

July 12, 2016

cppcheck on Dillo source

by jcid＠dillo.org

Hi Nick, On Sat, Jul 09, 2016 at 12:35:10PM +0100, Nick Warne wrote: > Hi all, > > While waiting for the Tour De France to start on TV, I ran cppcheck on > Dillo source for something to do - a few errors were picked up! > > I have compacted the findings (with two comments from me)and attached it > as a plain text file. Thanks for the report. I personally didn't know of cppcheck. We have used several code cleanup tools in the past and we usually honour them as sometimes they catch important flaws. A bunch of patches was just committed. You may peruse them with "hg log -vp" for the details/explanations. > Checking ../../slackbuilds/dillo/hg/dillo/dpi/file.c... > [../../slackbuilds/dillo/hg/dillo/dpi/file.c:356]: (error) syntax error > > if S_ISDIR (finfo->mode) { > Nick-> maybe?: > if (S_ISDIR (finfo->mode)) { Done. > Checking ../../slackbuilds/dillo/hg/dillo/dpid/dpid.c... > [../../slackbuilds/dillo/hg/dillo/dpid/dpid.c:465]: (error) Resource leak: dpidrc_stream > > return -1; > Nick-> maybe?: > return (-1); Done. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 1) requires 'unsigned int *' but the argument type is 'int *'. > Checking ../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/hyphenator.cc:570]: (warning) %u in format > string (no. 2) requires 'unsigned int *' but the argument type is 'int *'. It may be a trivial s/%u/%d/, but after reading it a bit I'd prefer Sebastian to double check it. Not committed. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/iterator.cc... > [../../slackbuilds/dillo/hg/dillo/dw/iterator.cc:124]: (error) Memory leak: eit3 Done. AFAICS, this is a false positive. Patched to please cppcheck anyway. > > Checking ../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc... > [../../slackbuilds/dillo/hg/dillo/dw/ooffloatsmgr.cc:654]: (error) Possible null pointer dereference: vloat Well, the code should never reach there. Not changed. @Sebastian, BTW, coincidentally I'm using something like: SortedFloatsVector *list; list = isSubRefLeftFloat(ref) ? leftFloats : rightFloats; Float *vloat = list->get (getFloatIndexFromSubRef (ref)); in some patches I have, which also silence cppcheck. But maybe the original construct was meant for adding more options (like absolute positioned floats), but those may end in a third floats array, so I'm not sure. Is it safe to use the above construct, or should I leave it as is? > Checking ../../slackbuilds/dillo/hg/dillo/lout/container.cc... > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:143]: (error) Common realloc mistake: 'array' nulled but not freed upon failure > [../../slackbuilds/dillo/hg/dillo/lout/container.cc:177]: (error) Common realloc mistake: 'array' nulled but not freed upon failure Done. > Checking ../../slackbuilds/dillo/hg/dillo/lout/misc.cc... > [../../slackbuilds/dillo/hg/dillo/lout/misc.cc:172]: (error) Common realloc mistake: 'bits' nulled but not freed upon failure Done. > Truck loads of: > Checking ../../slackbuilds/dillo/hg/dillo/src/md5.c: ARCH_IS_BIG_ENDIAN... > [../../slackbuilds/dillo/hg/dillo/src/md5.c:216]: (error) Uninitialized variable: X > in md5.c Untouched: I'm not md5 savvy. Maybe corvid. -- Cheers Jorge.-

July 12, 2016

Problem related to generated content

by sgeerken＠dillo.org

At least it can be worked around by the user by switching off CSS, so this is not a blocker for a new release. Sebastian On Di, Jul 05, 2016, Sebastian Geerken wrote: > Hi! > > I've come upon an interesting problem. Consider this HTML (stripped > down from a real world example): > > <head> > <style> > .fc:after { > content: ""; > display: block; > clear: both; > } > </style> > </head> > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Firefox (and probably other browsers) renders black text "main" on > white background above white text "footer" on dark gray background. > Dillo 3.0.5 does the same, for the simple reason that it does not > support floats. Dillo 3.1-dev, however, renders black text "main" and > white text "footer" side by side on dark gray background, because > "main" is within a float. (Which is, of course, difficult to read.) > > The reason why Firefox renders this as it does: the definition within > <style> generates something like a block element before the text > containing "footer", with "clear: both" as CSS attributes; something > like: > > <body> > <div class="fc"> > <div style="float: left">main</div> > </div> > <div style="clear:both"></div> > <div style="background:#404040; color:#ffffff">footer</div> > </body> > > Aside from the fact that dillo has still problems with this ("footer" > is too much to the right; I'll investigate this independently), this > shows that dillo's limited capabilities regarding generated content, > together with floats, causes some unpleasing rendering errors, which > are furthermore laborious to analyse (and thus not so simple to > be ignored). Has someone a feasible idea to deal with this? > > Sebastian > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

July 10, 2016

cppcheck on Dillo source

by nick＠linicks.net

On Sat, 9 Jul 2016 12:35:10 +0100 Nick Warne <nick at linicks.net> wrote: > Hi all, > > While waiting for the Tour De France to start on TV, I ran cppcheck on > Dillo source for something to do - a few errors were picked up! > > I have compacted the findings (with two comments from me)and attached > it as a plain text file. > > Keep up the great work guys and thanks! > > Nick OK, updating cppcheck to 1.74, I ran it again. A new error appears, but I don't know if it is a false positive, as I still don't really understand C++ (but do get the logic of function calls vs void etc.: Checking ../../slackbuilds/dillo/hg/dillo/src/ui.cc... [../../slackbuilds/dillo/hg/dillo/src/ui.cc:574]: (error) Return value of allocation function 'make_filemenu_button' is not stored. [../../slackbuilds/dillo/hg/dillo/src/ui.cc:588]: (error) Return value of allocation function 'make_filemenu_button' is not stored. Now, the call is: make_filemenu_button(); to: Fl_Widget *UI::make_filemenu_button() which returns (btn) so is that correct? Where does (btn) go in the calling function - or what does it do? Nick (trying to learn). -- 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"

July 9, 2016

cppcheck on Dillo source

by nick＠linicks.net

Hi all, While waiting for the Tour De France to start on TV, I ran cppcheck on Dillo source for something to do - a few errors were picked up! I have compacted the findings (with two comments from me)and attached it as a plain text file. Keep up the great work guys and 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"

July 9, 2016

URL field / Loading page images / Refreshing DNS cache

by Johannes.Hofmann＠gmx.de

On Fri, Jul 08, 2016 at 01:23:55PM -0400, Jorge Arellano Cid wrote: > On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote: > > On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote: > > > On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > > > > First, a huge thanks to all the Dillo team for their efforts: I just > > > > switched from 3.0.5 to the current snapshot to try out the mbedtls > > > > changes, and I am wowed not only by this, but by all the improvements > > > > in rendering, etc. Great work! > > > > > > > > A few suggestions, all very minor, that might be added to the back of > > > > the development queue: > > > > > > > > In the current snapshot, the navigation bar has changed, and the URL > > > > field does not seem to be taking into account font_factor -- with the > > > > result that the window is smaller than the font height. You can test > > > > this by setting, e.g., font_factor=2.0 in your dillorc (most > > > > dramatically for a tiny panel with small icons). The issue seems to > > > > be with this factor not being taken into account when bh and lh are > > > > set in make_panel() in ui.cc. > > > > > > > > As far as I can see, one can use the context menu to download > > > > individual images on a page, or use the panel to toggle image > > > > loading. But if one wants not to download images in general, but to > > > > download all the images for some one page (e.g., a weather forecast > > > > page), then one has to toggle downloading of images on and then off > > > > again. Maybe a command could be added to KeysCommand_t in keys.hh, > > > > bound by default to something like Ctrl-i in keys.cc, with a > > > > corresponding call to a_Html_load_images() in handle() in ui.cc? > > > > > > > > To make the switch to the current snapshot, I had, sadly, to terminate > > > > an instance of 3.0.5 that had been running continuously for 90 days > > > > without any issues. But to get that much up time it was necessary to > > > > add a little code so that SIGUSR1 would call a_Dns_freeall() and > > > > a_Dns_init(), otherwise (unless I am missing something) Dillo will > > > > persist in using the cached lookup indefinitely and not detect when > > > > the IP address has changed. So maybe some sort of key binding could > > > > be added that would flush the cache when needed? > > > > > > good point. However I'd like to avoid another key-binding and rather > > > do the right thing automatically. > > > I could think of a general DNS entry timeout of a couple of seconds. > > > In many cases DNS responses are cached at OS-level too respecting > > > lifetime values given by the server. > > > > Firefox has an option to configure the DNS cache expiration > > (network.dnsCacheExpiration). > > Attached patch implements a similar feature for Dillo. > > Thanks for the patch Johannes. > > Under the current workload, I guess I'll look at it in a couple of days. > > BTW, different use cases are very interesting. We usually asume our > use case is generic. Dillo has thaught me several times that's not the > case. true > > I for instance, really avoid flushing the DNS cache as it is one of > the slowest parts of my web browsing experience. Sometimes the ISP DNS > server takes more time to answer than the page to load! > > I use another DNS but it's very noticeable, and the sites I usually browse > seldom change their IPs (I've even thought of caching to disk, go figure! ;) > > So I'd like to know what's the use case behind this need. There's surely > something on it (e.g. some site may want to distribute workload between > different servers by changing IP, etc). Searching for "getaddrinfo ttl" gives some interesting information about the topic. The general opinion seems to be that DNS caching should be handled by e.g. nscd(8) as the TTL value is available there and responses can be cached over process restarts of individual apps. That also seems to be the reason why getaddrinfo() doesn't give access to the TTL value (to avoid that all sorts of applications implement their own DNS caching scheme). Nevertheless I think that for the special case of web browsers some DNS caching is helpful. And e.g. Firefox does that too. Having a configuration option for the DNS cache expiration time one can have everything from no caching at all to caching forever. > > One thing I know DNS queries are abused for is for tracking users. > On the old dialup days, the DNS was very quick to answer, so I suspect > something fishy going on when it takes so much time here on broadband... > Cheers, Johannes

July 9, 2016

patches #4634 and #4635

by jcid＠dillo.org

Hi corvid, Some comments: ----------------- Patch #4635: rm IO flags, as they are never used Yes, those linger from a time when shutdown() was used for handling sockets in dillo. Not necessary now since we use read() write() close(). ------------------ Patch #4634: freeing http socket, close FD that's being connected Why did you do this? (i.e. Is there a specific bug?). Beware the FD is closed inside IO.c (OpEnd|OpAbort). If you close it in Http_socket_free(), you are opening race conditions on file descriptors, and coding outside the design. Http_socket_free() is used with the CCC chains, that's why it doesn't close the FD, IO will do it by means of CCC; avoiding race conditions. I haven't tested the code yet, but I'd be amazed if resources don't stop to load at random. For instance, Http_socket_reuse(int Skey) would be activating and reporting success on a socket that's just been closed. Please review all the related patches and be more careful before committing. PD: IIRC I used lsof to check for FD leaks long ago. -- Cheers Jorge.-

July 9, 2016

an experiment using mbed TLS

by eocene＠gmx.com

Martin wrote: > Dillo builds just fine on mucosa, especially after I `brew install mbedtls` > > Problem is that, at start up, it reports > Trusting 0 TLS certificates. > > Any idea how I can install some? It's odd browsing about without https > these days. Did it work with 3.0.5 or the development branch before the recent change? (Wouldn't expect it to.) Johannes reported success on osx, but I don't know what's customary for getting certificates there... I presume https is "working" but forces you to click on dialogs...?

July 8, 2016

an experiment using mbed TLS

by matlads＠gmail.com

Hi dillo-dev, Dillo builds just fine on mucosa, especially after I `brew install mbedtls` Problem is that, at start up, it reports Trusting 0 TLS certificates. Any idea how I can install some? It's odd browsing about without https these days. Cheers, On 4 Jul 2016 20:22, "Nick Warne" <nick at linicks.net> wrote: > On Mon, 4 Jul 2016 17:01:39 +0000 > eocene <eocene at gmx.com> wrote: > > > Nick wrote: > > > > > Should be -lmbedtls, -lmbedx509 and -lmbedcrypto > > > > > > All really does build fine now :) > > > > > > mbedtls seems to work well - seems a tad quicker too. > > > > I don't know where you got the > > "-libmbedtls -libmbedx509 -libmbedcrypto" from. > > Mine has "-lmbedtls -lmbedx509 -lmbedcrypto", > > and it says "-lmbedtls -lmbedx509 -lmbedcrypto when > > I double-check on hg.dillo.org. > > Ummm. You are right. Maybe I was messing around late last night with > the earlier error message - I can't remember now :) > > Sorry for the noise - all builds and works fine. > > 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" > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

July 8, 2016

URL field / Loading page images / Refreshing DNS cache

by jgaffney＠lawrenceville.org

Jorge Arellano Cid <jcid at dillo.org> writes: [...] >> As far as I can see, one can use the context menu to download >> individual images on a page, or use the panel to toggle image >> loading. But if one wants not to download images in general, but to >> download all the images for some one page (e.g., a weather forecast >> page), then one has to toggle downloading of images on and then off >> again. Maybe a command could be added to KeysCommand_t in keys.hh, >> bound by default to something like Ctrl-i in keys.cc, with a >> corresponding call to a_Html_load_images() in handle() in ui.cc? > > This is interesting. > >> To make the switch to the current snapshot, I had, sadly, to terminate >> an instance of 3.0.5 that had been running continuously for 90 days >> without any issues. > > Wow, it's good to know it can last that long. > > What you describe here is very interesting, in a way I've > come to suspect most users don't have the slightest clue. > > I mean, everyone of us (as dillo users) have *different* use cases. > There's no way we can guess what other people are doing outside of > our awareness realm. > > Now, you're not only a casual user, but one that uses dillo *a lot*, > and appreciate it as an everyday tool. > > That being stated, we are very interested in knowing your use case, > and all the details of it. There's potentially a lot we can learn from it, > and also improve yours/and-the-generic user experience as a result of > this learning. > > So please elaborate on why you like to have it running for that long time, > what do you do with it, how you do it, what problem does it solve that other > tools don't, why is it your choice. What you'd wish it had. I had been using Firefox (and still do, for trusted sites that require javascript), but looked around for another browser when the option to turn off javascript was removed from the preferences dialog -- when javascript is so often the vulnerability behind exploits, I didn't want a browser hoisting in javascript from all over the Internet at its own discretion. (It is still possible to turn javascript off in Firefox if one starts from a script that invokes a prefs.js with a legacy `user_pref("javascript.enabled", false);', or from the internal about:config page, but:) Dillo was one of the few browsers without javascript, and when I checked it out, I found that I agreed very much with Dillo's stated philosophy. And it has been my principal browser ever since. In fact, along with an xterm and Emacs, it's one of the three apps always running on my machine. Things I like about Dillo: Dillo doesn't even include javascript. (I cringe a bit when there is talk on the list about the possibility of including it -- if it is included at some point, I hope that there will be a #define to exclude that code at compile time.) Dillo is small and fast, which is nice not only for general browsing, but when invoking it through, e.g., Emacs to open a link. Dillo let's me configure things the way I like, and when it doesn't do something I want, the code base is accessible enough that I can modify it to do so. (I had in fact already implemented the suggestions I made, but didn't share any patches because, even beyond being an amateur, my hacks tend to be on the ugly side -- the loading of images per page, for example, required adding #include "html.hh" to ui.cc, indicating that I am certainly violating some logic of organization and encapsulation.) Dillo isn't phoning home or doing anything else behind my back, and it let's me easily block ad and other such sites in domainrc. Dillo doesn't try to do all sorts of exotic things, or invoke external apps to do them, with all of the potential security risks. With other browsers, you have to do a lot of work to try to prevent this sort of automagical behavior, and even if it's possible, you aren't left feeling at all confident about having prevented it. Like you, I like that Dillo caches DNS lookups, but of course IP addresses change from time to time for legitimate reasons, so there does need to be a way to flush the cache. Johannes's patch is a good one, but I also still like the idea of using the cache until I need it to refresh. Of course, one could simply start a new instance of Dillo, but I also like that it caches pages in a way that allows me to open a link to a previously visited page off-line, without trying to reconnect and reload it. And -- possibly a unique personal idiosyncrasy -- I like to see links I have visited displayed as visited. Other than that, there really isn't any reason not to be firing up a fresh instance of Dillo whenever it is needed. And probably a lot of other virtues in Dillo that just aren't coming to mind right now. > Some things may be possible, others not, a few may be solved in different > ways, etc. Just learning about those key tasks, or improving a single one, > would be a big gain for all of us. > > Your feedback as a dillo power-user is not only welcomed, it's asked for! > > >> Thanks again for all your hard work! > > Ack! > > > @all: if you're a dillo power-user, let us know about it!

July 8, 2016

URL field / Loading page images / Refreshing DNS cache

by jcid＠dillo.org

On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > First, a huge thanks to all the Dillo team for their efforts: I just > switched from 3.0.5 to the current snapshot to try out the mbedtls > changes, and I am wowed not only by this, but by all the improvements > in rendering, etc. Great work! Thanks for taking the time to express this! > As far as I can see, one can use the context menu to download > individual images on a page, or use the panel to toggle image > loading. But if one wants not to download images in general, but to > download all the images for some one page (e.g., a weather forecast > page), then one has to toggle downloading of images on and then off > again. Maybe a command could be added to KeysCommand_t in keys.hh, > bound by default to something like Ctrl-i in keys.cc, with a > corresponding call to a_Html_load_images() in handle() in ui.cc? This is interesting. > To make the switch to the current snapshot, I had, sadly, to terminate > an instance of 3.0.5 that had been running continuously for 90 days > without any issues. Wow, it's good to know it can last that long. What you describe here is very interesting, in a way I've come to suspect most users don't have the slightest clue. I mean, everyone of us (as dillo users) have *different* use cases. There's no way we can guess what other people are doing outside of our awareness realm. Now, you're not only a casual user, but one that uses dillo *a lot*, and appreciate it as an everyday tool. That being stated, we are very interested in knowing your use case, and all the details of it. There's potentially a lot we can learn from it, and also improve yours/and-the-generic user experience as a result of this learning. So please elaborate on why you like to have it running for that long time, what do you do with it, how you do it, what problem does it solve that other tools don't, why is it your choice. What you'd wish it had. Some things may be possible, others not, a few may be solved in different ways, etc. Just learning about those key tasks, or improving a single one, would be a big gain for all of us. Your feedback as a dillo power-user is not only welcomed, it's asked for! > Thanks again for all your hard work! Ack! @all: if you're a dillo power-user, let us know about it! -- Cheers Jorge.-

July 8, 2016

CSS files downloaded only after reloading page

by nick＠linicks.net

On Thu, 7 Jul 2016 22:20:01 +0000 eocene <eocene at gmx.com> wrote: > Alexander wrote: > > Hi Dillo developers, > > > > the dillo version from the repository seems to have problems > > downloading some CSS files the first time some pages are loaded. > > Though, the remaining CSS files are downloaded when the page is > > re-loaded using CTRL-r. > > > > Example page: > > > > https://netzpolitik.org/ > > > > Reproduce: > > > > 1) dillo https://netzpolitik.org/ > > -> styles from some CSS files seem to be missing > > 2) press CTRL-r > > -> some new CSS file is downloaded and styles are applied > > 3) press CTRL-r > > -> some new CSS file is downloaded and styles are applied > > My guess is that it might have something to do with redirections, > where we think we're ready but we don't have the final endpoint > documents yet. Interesting - here is another example of the issue that I discovered today: https://bz.apache.org/bugzilla/show_bug.cgi?id=59333 Great work going on with Dillo anyhow - thanks to all. 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"

July 8, 2016

URL field / Loading page images / Refreshing DNS cache

by jcid＠dillo.org

On Fri, Jul 08, 2016 at 05:22:48PM +0200, Johannes Hofmann wrote: > On Wed, Jul 06, 2016 at 10:28:04AM +0200, Johannes Hofmann wrote: > > On Tue, Jul 05, 2016 at 04:53:45PM -0400, John Gaffney wrote: > > > First, a huge thanks to all the Dillo team for their efforts: I just > > > switched from 3.0.5 to the current snapshot to try out the mbedtls > > > changes, and I am wowed not only by this, but by all the improvements > > > in rendering, etc. Great work! > > > > > > A few suggestions, all very minor, that might be added to the back of > > > the development queue: > > > > > > In the current snapshot, the navigation bar has changed, and the URL > > > field does not seem to be taking into account font_factor -- with the > > > result that the window is smaller than the font height. You can test > > > this by setting, e.g., font_factor=2.0 in your dillorc (most > > > dramatically for a tiny panel with small icons). The issue seems to > > > be with this factor not being taken into account when bh and lh are > > > set in make_panel() in ui.cc. > > > > > > As far as I can see, one can use the context menu to download > > > individual images on a page, or use the panel to toggle image > > > loading. But if one wants not to download images in general, but to > > > download all the images for some one page (e.g., a weather forecast > > > page), then one has to toggle downloading of images on and then off > > > again. Maybe a command could be added to KeysCommand_t in keys.hh, > > > bound by default to something like Ctrl-i in keys.cc, with a > > > corresponding call to a_Html_load_images() in handle() in ui.cc? > > > > > > To make the switch to the current snapshot, I had, sadly, to terminate > > > an instance of 3.0.5 that had been running continuously for 90 days > > > without any issues. But to get that much up time it was necessary to > > > add a little code so that SIGUSR1 would call a_Dns_freeall() and > > > a_Dns_init(), otherwise (unless I am missing something) Dillo will > > > persist in using the cached lookup indefinitely and not detect when > > > the IP address has changed. So maybe some sort of key binding could > > > be added that would flush the cache when needed? > > > > good point. However I'd like to avoid another key-binding and rather > > do the right thing automatically. > > I could think of a general DNS entry timeout of a couple of seconds. > > In many cases DNS responses are cached at OS-level too respecting > > lifetime values given by the server. > > Firefox has an option to configure the DNS cache expiration > (network.dnsCacheExpiration). > Attached patch implements a similar feature for Dillo. Thanks for the patch Johannes. Under the current workload, I guess I'll look at it in a couple of days. BTW, different use cases are very interesting. We usually asume our use case is generic. Dillo has thaught me several times that's not the case. I for instance, really avoid flushing the DNS cache as it is one of the slowest parts of my web browsing experience. Sometimes the ISP DNS server takes more time to answer than the page to load! I use another DNS but it's very noticeable, and the sites I usually browse seldom change their IPs (I've even thought of caching to disk, go figure! ;) So I'd like to know what's the use case behind this need. There's surely something on it (e.g. some site may want to distribute workload between different servers by changing IP, etc). One thing I know DNS queries are abused for is for tracking users. On the old dialup days, the DNS was very quick to answer, so I suspect something fishy going on when it takes so much time here on broadband... -- Cheers Jorge.-

July 8, 2016

Jump to page: