- Dillo-dev - lists.mailman3.com

here's 3.0.4.1 RC1

by jcid＠dillo.org

Hi, On Wed, Dec 03, 2014 at 12:13:08AM +0000, eocene wrote: > > Even though 3.0.4.1 only has a few changes, it's nice to have an RC and > make sure that everything is all right, so: > > http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2 Yes, thanks a lot. Just checked the diff, compiled and run. AFAIS, it's OK. @all, please compile/run rc1 and report how it went. When there's feedback from the main platforms (GNU/Linux already OK), I'll add the release date, signature and upload to the site, so the rest of the release can proceed. -- Cheers Jorge.-

Dec. 3, 2014

here's 3.0.4.1 RC1

by eocene＠gmx.com

Even though 3.0.4.1 only has a few changes, it's nice to have an RC and make sure that everything is all right, so: http://www.dillo.org/download/dillo-3.0.4.1-rc1.tar.bz2

Dec. 3, 2014

can't access http://www.dillo.org/index.html after pushing an update to it :( :(

by eocene＠gmx.com

Andreas wrote: > index.html was again rw------- > > I have done a simple chmod last time because I was in a hurry (and did > not send a notice) and forgot to do something real about it. > I hope I have fixed it now in a better way. Thank you :)

Nov. 27, 2014

can't access http://www.dillo.org/index.html after pushing an update to it :( :(

by andreas＠kemnade.info

Hi, On Thu, 2014-11-27 at 19:32 +0000, eocene wrote: > Forbidden > You don't have permission to access /index.html on this server. > > :( > > (I added some mention of 3.1 and 3.0.4.1 for clarification after noticing that > our ChangeLog link only shows 3.0.4.1 at the moment.) > > I had this happen with another file some weeks ago, and I mentioned it > to Andreas, who either fixed it or it resolved on its own somehow. > index.html was again rw------- I have done a simple chmod last time because I was in a hurry (and did not send a notice) and forgot to do something real about it. I hope I have fixed it now in a better way. Greetings Andreas Kemnade

Nov. 27, 2014

can't access http://www.dillo.org/index.html after pushing an update to it :( :(

by eocene＠gmx.com

Forbidden You don't have permission to access /index.html on this server. :( (I added some mention of 3.1 and 3.0.4.1 for clarification after noticing that our ChangeLog link only shows 3.0.4.1 at the moment.) I had this happen with another file some weeks ago, and I mentioned it to Andreas, who either fixed it or it resolved on its own somehow. I don't believe I've changed anything. My umask is 0066, but that's not new at all.

Nov. 27, 2014

--local, reload, repush

by eocene＠gmx.com

BTW, when I was checking --local, I noticed that it will start to request images and stuff upon reload as expected, but then when there's a repush, SpamSafe is on again.

Nov. 27, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote: > > Seems to be working. Changes pushed. > > I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from > > the 'default' branch after pulling. > > Can you push changeset: 3976:d6a45d54f49a to the default branch too? > (I don't know how to do it without making a new patch). Do you mean have a changeset be part of multiple branches? I don't think that can be done. My impression is that merging after we finish the branch won't be anything more than: hg update default hg merge 3.0.4.1 (and I see that hg commit comes with a '--close-branch' that people use when they're irritated by having too many old branches visible in hg branches, which doesn't sound like a problem for us at present)

Nov. 27, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote: > Jorge wrote: > > On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote: > > > After doing all of that just now, I was giving a little methodical testing > > > before pushing my changes, and I found that there's still a bug in the focus > > > fix. > > > > > > If the page has focus, and the cursor leaves the page and returns to it, it > > > seems to be fine. > > > If an input has focus, and the cursor leaves the page and returns to it, it > > > seems to be fine. > > > If an input has focus and you click on the page to give it focus instead, > > > and then the cursor leaves the page and returns to it, the input is given > > > focus instead. > > > > Right! > > > > Please try this patch: > > Seems to be working. Changes pushed. > I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from > the 'default' branch after pulling. Can you push changeset: 3976:d6a45d54f49a to the default branch too? (I don't know how to do it without making a new patch). -- Cheers Jorge.-

Nov. 27, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote: > > After doing all of that just now, I was giving a little methodical testing > > before pushing my changes, and I found that there's still a bug in the focus > > fix. > > > > If the page has focus, and the cursor leaves the page and returns to it, it > > seems to be fine. > > If an input has focus, and the cursor leaves the page and returns to it, it > > seems to be fine. > > If an input has focus and you click on the page to give it focus instead, > > and then the cursor leaves the page and returns to it, the input is given > > focus instead. > > Right! > > Please try this patch: Seems to be working. Changes pushed. I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from the 'default' branch after pulling.

Nov. 27, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote: > I wrote: > > Jorge wrote: > > > On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote: > > > > Jorge wrote: > > > > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. > > > > > > > > Looking at ChangeLog, I'd argue that if we're making any release, we > > > > should also have > > > > > > > > - Don't load background images in --local mode. > > > > > > > > and probably > > > > > > > > - Fix Makefile to pick up LIBJPEG_CPPFLAGS. > > > > > > > > and perhaps > > > > > > > > - Remove Fl_Printer stub that always gave problems compiling under OSX. > > > > > > +1 > > > > It looks like I'll be semi-busy through Monday or so, but if no one > > else feels like doing it, I'll look into creating a branch, committing > > changes, version number, splash verbiage, etc.... > > After doing all of that just now, I was giving a little methodical testing > before pushing my changes, and I found that there's still a bug in the focus > fix. > > If the page has focus, and the cursor leaves the page and returns to it, it > seems to be fine. > If an input has focus, and the cursor leaves the page and returns to it, it > seems to be fine. > If an input has focus and you click on the page to give it focus instead, > and then the cursor leaves the page and returns to it, the input is given > focus instead. Right! Please try this patch: diff -r fb02b8b26017 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Fri Nov 21 21:58:27 2014 +0100 +++ b/dw/fltkviewbase.cc Thu Nov 27 10:10:22 2014 -0300 @@ -365,6 +365,8 @@ int FltkViewBase::handle (int event) // FLTK delivers UNFOCUS to the previously focused widget if (find(Fl::focus()) < children()) focused_child = Fl::focus(); // remember the focused child! + else if (Fl::focus() == this) + focused_child = NULL; // no focused child this time return 0; case FL_KEYBOARD: if (Fl::event_key() == FL_Tab) -- Cheers Jorge.-

Nov. 27, 2014

what's currently broken in dillo

by eocene＠gmx.com

I wrote: > Jorge wrote: > > On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote: > > > Jorge wrote: > > > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. > > > > > > Looking at ChangeLog, I'd argue that if we're making any release, we > > > should also have > > > > > > - Don't load background images in --local mode. > > > > > > and probably > > > > > > - Fix Makefile to pick up LIBJPEG_CPPFLAGS. > > > > > > and perhaps > > > > > > - Remove Fl_Printer stub that always gave problems compiling under OSX. > > > > +1 > > It looks like I'll be semi-busy through Monday or so, but if no one > else feels like doing it, I'll look into creating a branch, committing > changes, version number, splash verbiage, etc.... After doing all of that just now, I was giving a little methodical testing before pushing my changes, and I found that there's still a bug in the focus fix. If the page has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus and you click on the page to give it focus instead, and then the cursor leaves the page and returns to it, the input is given focus instead. PS I was mistaken when I thought "Fix Makefile to pick up LIBJPEG_CPPFLAGS" related to a bug that made it into a release. The bug actually came from the float code that was merged in.

Nov. 25, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote: > > Jorge wrote: > > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. > > > > Looking at ChangeLog, I'd argue that if we're making any release, we > > should also have > > > > - Don't load background images in --local mode. > > > > and probably > > > > - Fix Makefile to pick up LIBJPEG_CPPFLAGS. > > > > and perhaps > > > > - Remove Fl_Printer stub that always gave problems compiling under OSX. > > +1 It looks like I'll be semi-busy through Monday or so, but if no one else feels like doing it, I'll look into creating a branch, committing changes, version number, splash verbiage, etc....

Nov. 21, 2014

Todo "dpid_idle_timeout variable to dpidrc" and config parsing generally

by james.from.wellington＠gmail.com

Hello all, In dpid/dpid.c at about line 204, there is a todo, that dpid_idle_timeout should be configurable. I looked at how to do this sympathetically with the existing code and blocked, because the configuration file is: - having its location calculated - being opened - being scanned into heap memory several times in the existing code. My over-response is to write a library to: - private memory-map it - parse it into a linked-list in the comments in the file and - have everyone who traversed the file now traverse the linked-list On the way, we get new functionality: - the ability to record the use of a configuration item - the ability to report on unused configuration items -- which are interesting because they're probably typos Parsing dillorc with the default options uncommented, this approach is about 4* faster than the existing approach. I think that it will also have a smaller VM footprint, because we are already paying for cooked disk buffers for the same amount of file, more times. The diff is 1400 lines, so I don't expect instant rejoicing :-) The attached file contains my test-cases, shell scripts to generate some of them, that are tricky, and the diff which inserts the code into revision b185e43. Regards, James.

Nov. 21, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote: > Jorge wrote: > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. > > Looking at ChangeLog, I'd argue that if we're making any release, we > should also have > > - Don't load background images in --local mode. > > and probably > > - Fix Makefile to pick up LIBJPEG_CPPFLAGS. > > and perhaps > > - Remove Fl_Printer stub that always gave problems compiling under OSX. +1 -- Cheers Jorge.-

Nov. 19, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. Looking at ChangeLog, I'd argue that if we're making any release, we should also have - Don't load background images in --local mode. and probably - Fix Makefile to pick up LIBJPEG_CPPFLAGS. and perhaps - Remove Fl_Printer stub that always gave problems compiling under OSX.

Nov. 19, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote: > Jorge wrote: > > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote: > > > Good try, wandering focus got so annoying that I had to start scratching > > > the itch! ;) > > > > > > FYI, I'm testing a patch that so far behaves OK. > > > > Committed. > > If I go to a page that has a Fl_Input, give focus to the input, move the > cursor out of the dillo window, and move it back into the dillo window, > focus does not return to the input. Committed a new patch. -- Cheers Jorge.-

Nov. 19, 2014

Strange linebreaking when long hyphenated words appear in table cells

by sgeerken＠dillo.org

On Fr, Nov 14, 2014, Jeremy Henty wrote: > The attached file demonstrates the problem. The test in the first > paragraph easily linebreaks to fit the width of the window because of > the potential linebreaks after each hyphen. The same text inside of a > table cell forces the cell to be almost as wide as the unbroken text, > although some line breaking does happen. > > My guess is that Dillo calculates the minimum width of the table cell > without accounting for potential linebreaks after hyphens in the text. > However, when it later fills the cell with the text it does allow > linebreaks after hyphens. This is correct. There are several reasons for ignoring hyphenation (both implicit and explicit, as here) when calculating the minimal width. First, it would make hyphenation of all words necessary, not (as now) the ones around feasible line breaks. Furthermore, there are problems with layout tables (altough becoming more and more extinct); there has been some discussion on this list, IIRC. > If that is correct then I think Dillo > should account for potential linebreaks after hyphens both when > calculating the minimum width of the cell See above. > and when filling the cell with text. This is actually done, as you see. The long "aaaaa-aaaaa-..." is broken, within the width which has been calculated before for the table cell width. > The current situation is inconsistent and can deliver very > poor results. Changing one of the above (minimal width, or hyphenation within table cells) will probably do more harm than good, so I'd leave it as it is, unless there are really severe reasons, as real-world web pages which are unreadable. Sebastian

Nov. 19, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote: > > Jorge wrote: > > > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote: > > > > Good try, wandering focus got so annoying that I had to start scratching > > > > the itch! ;) > > > > > > > > FYI, I'm testing a patch that so far behaves OK. > > > > > > Committed. > > > > If I go to a page that has a Fl_Input, give focus to the input, move the > > cursor out of the dillo window, and move it back into the dillo window, > > focus does not return to the input. > > OK, now I have code that also works for this case... > > If you have another interesting test case like this, please let > me know now (before I send it to you for the final reality checks). I can't think of anything in particular right now...

Nov. 18, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote: > Jorge wrote: > > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote: > > > Good try, wandering focus got so annoying that I had to start scratching > > > the itch! ;) > > > > > > FYI, I'm testing a patch that so far behaves OK. > > > > Committed. > > If I go to a page that has a Fl_Input, give focus to the input, move the > cursor out of the dillo window, and move it back into the dillo window, > focus does not return to the input. OK, now I have code that also works for this case... If you have another interesting test case like this, please let me know now (before I send it to you for the final reality checks). -- Cheers Jorge.-

Nov. 18, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jorge wrote: > On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote: > > Good try, wandering focus got so annoying that I had to start scratching > > the itch! ;) > > > > FYI, I'm testing a patch that so far behaves OK. > > Committed. If I go to a page that has a Fl_Input, give focus to the input, move the cursor out of the dillo window, and move it back into the dillo window, focus does not return to the input.

Nov. 18, 2014

what's currently broken in dillo

by jcid＠dillo.org

On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote: > > Jeremy wrote: > > > The Dillo source does something a little devious. It refers to > > > fl_oldfocus, but this symbol is not declared in any header, it is just > > > shared between two *.c files via an extern declaration (with a comment > > > that this is a hack to make Fl_Group work). Something has changed in > > > libfltk.so to stop the linker finding this symbol. I don't know what > > > (I am not experienced in debugging linking failures.) > > > > To the best of my recollection, something tricky was necessary because > > Fl_Group didn't have the idea that the group itself could have focus > > instead of one of the children. I can't immediately see how to get it > > to work right without fl_oldfocus, but if we can't link, we have nothing, > > so I'll take out fl_oldfocus, and hopefully someone will figure out > > something at some point... > > Good try, wandering focus got so annoying that I had to start scratching > the itch! ;) > > FYI, I'm testing a patch that so far behaves OK. Committed. -- Cheers Jorge.-

Nov. 18, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote: > > > > Should we release 3.0.5 to fix this for distro users? Otherwise their > > dillo will break when their distro updates to a FLTK-1.3.3 *.so . > > IMHO current repo is not as stable as it should for a new release. > > I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. That was what I had in mind. Sorry if that was not clear. > The repo has more than enough for a version bump when its moment > comes! I would say it deserves to be 3.1 at least! :-) Regards, Jeremy Henty

Nov. 17, 2014

what's currently broken in dillo

by jcid＠dillo.org

Hi Jeremy, On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote: > > eocene wrote: > > > [...] I'll take out fl_oldfocus, and hopefully someone will figure > > out something at some point... > > Should we release 3.0.5 to fix this for distro users? Otherwise their > dillo will break when their distro updates to a FLTK-1.3.3 *.so . IMHO current repo is not as stable as it should for a new release. I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. The repo has more than enough for a version bump when its moment comes! -- Cheers Jorge.-

Nov. 17, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

eocene wrote: > [...] I'll take out fl_oldfocus, and hopefully someone will figure > out something at some point... Should we release 3.0.5 to fix this for distro users? Otherwise their dillo will break when their distro updates to a FLTK-1.3.3 *.so . Regards, Jeremy Henty

Nov. 17, 2014

what's currently broken in dillo

by jcid＠dillo.org

Hi, On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote: > Jeremy wrote: > > The Dillo source does something a little devious. It refers to > > fl_oldfocus, but this symbol is not declared in any header, it is just > > shared between two *.c files via an extern declaration (with a comment > > that this is a hack to make Fl_Group work). Something has changed in > > libfltk.so to stop the linker finding this symbol. I don't know what > > (I am not experienced in debugging linking failures.) > > To the best of my recollection, something tricky was necessary because > Fl_Group didn't have the idea that the group itself could have focus > instead of one of the children. I can't immediately see how to get it > to work right without fl_oldfocus, but if we can't link, we have nothing, > so I'll take out fl_oldfocus, and hopefully someone will figure out > something at some point... Good try, wandering focus got so annoying that I had to start scratching the itch! ;) FYI, I'm testing a patch that so far behaves OK. -- Cheers Jorge.-

Nov. 17, 2014

What's the repository for latest dillo?

by Johannes.Hofmann＠gmx.de

Hi Walter, On Mon, Nov 17, 2014 at 12:31:46AM -0500, Walter Dnes wrote: > I've got dillo-3.0.4 running on Gentoo linux, with fltk-1.3.2. People > here seem to be running experimental "bleeding edge" versions. I assume > it's from a git repo. What are the instructions to download and build > dillo, preferably in my user directory? I'm aware that it may be broken > on edge cases. > > I'm not a C programmer. My main skills are in bash shell scripting. > If nothing else, I'll be another tester. instructions how to get the latest sources can be found at http://www.dillo.org/source.html Cheers, Johannes

Nov. 17, 2014

What's the repository for latest dillo?

by waltdnes＠waltdnes.org

I've got dillo-3.0.4 running on Gentoo linux, with fltk-1.3.2. People here seem to be running experimental "bleeding edge" versions. I assume it's from a git repo. What are the instructions to download and build dillo, preferably in my user directory? I'm aware that it may be broken on edge cases. I'm not a C programmer. My main skills are in bash shell scripting. If nothing else, I'll be another tester. -- Walter Dnes <waltdnes at waltdnes.org>

Nov. 17, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

I wrote: > The Dillo source does something a little devious. It refers to > fl_oldfocus, but this symbol is not declared in any header, it is > just shared between two *.c files via an extern declaration (with a > comment that this is a hack to make Fl_Group work). Something has > changed in libfltk.so to stop the linker finding this symbol. I > don't know what (I am not experienced in debugging linking > failures.) Got it! When using autoconf, FLTK-1.3.3 compiles (if possible) with -fvisibility=hidden . This means that fl_oldfocus is marked as local instead of global in libfltk.so , which breaks linking Dillo. You can work around this with " ac_cv_cxx_fvisibility=no ./configure ... ". Regards, Jeremy Henty

Nov. 16, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jeremy wrote: > The Dillo source does something a little devious. It refers to > fl_oldfocus, but this symbol is not declared in any header, it is just > shared between two *.c files via an extern declaration (with a comment > that this is a hack to make Fl_Group work). Something has changed in > libfltk.so to stop the linker finding this symbol. I don't know what > (I am not experienced in debugging linking failures.) To the best of my recollection, something tricky was necessary because Fl_Group didn't have the idea that the group itself could have focus instead of one of the children. I can't immediately see how to get it to work right without fl_oldfocus, but if we can't link, we have nothing, so I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...

Nov. 16, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

higuita wrote: > > > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function > > > `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: > > > undefined reference to `fl_oldfocus' collect2: error: ld returned 1 > > > exit status make[3]: *** [dillo] Error 1 > > I'm not sure why you're getting that. > > I found that if i revert to fltk 1.3.2 it works, again building > the fltk 1.3.3, dillo build fails again. > > I have done make clean on fltk and dillo on every try and tried > to clean the system from any old files, but same results. > > greping the both fltk version for fl_oldfocus, i get the same > code, so is even weirder. > > Can someone reproduce this or i have something broken on my > system? I can reproduce this. The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.) Incidentally, yoshimi also fails to link against FLTK-1.3.3, although a different symbol is involved. Regards, Jeremy Henty

Nov. 15, 2014

Strange linebreaking when long hyphenated words appear in table cells

by onepoint＠starurchin.org

The attached file demonstrates the problem. The test in the first paragraph easily linebreaks to fit the width of the window because of the potential linebreaks after each hyphen. The same text inside of a table cell forces the cell to be almost as wide as the unbroken text, although some line breaking does happen. My guess is that Dillo calculates the minimum width of the table cell without accounting for potential linebreaks after hyphens in the text. However, when it later fills the cell with the text it does allow linebreaks after hyphens. If that is correct then I think Dillo should account for potential linebreaks after hyphens both when calculating the minimum width of the cell and when filling the cell with text. The current situation is inconsistent and can deliver very poor results. Regards, Jeremy Henty

Nov. 14, 2014

Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed.

by sgeerken＠dillo.org

On Mi, Nov 05, 2014, eocene wrote: > outofflowmgr.cc:203: virtual int > dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, > lout::object::Object*): Assertion `oofm->wasAllocated > (fl2->generatingBlock)' failed. [...] This assertion is indeed wrong, and has been removed, along with some others. Sebastian

Nov. 9, 2014

assert failed when using text search while page still loading

by eocene＠gmx.com

Sebastian wrote: > On Fri, Oct 24, 2014, Sebastian Geerken wrote: > > I've problems to reproduce it, but I'm guessing ... > > > > On Do, Okt 23, 2014, eocene wrote: > > > (gdb) bt > > > #0 0xb778a424 in __kernel_vsyscall () > > > #1 0xb70b2661 in *__GI_raise (sig=6) > > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > > > #3 0xb70ab878 in *__GI___assert_fail ( > > > assertion=0x816049e "i >= 0 && this->num - i > 0", > > > file=0x816048e "../lout/misc.hh", line=167, > > > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 > > > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > > > this=0x905df50, i=-1) at ../lout/misc.hh:167 > > > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > > > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > > > at textblock_iterator.cc:288 > > > > A line is missing, but everything else seems OK. I guess that this has > > to do with the new line breaking (introduced with release 3.0.3), > > where some words are not immediately assigned to a line. I'll soon > > work on this. > > I just pushed a fix. Does the problem still occur? I'll probably be lucky to trigger the right conditions again, but I'll try to make a habit of searching for text while waiting for pages to load and render...

Nov. 7, 2014

assert failed when using text search while page still loading

by sgeerken＠dillo.org

On Fri, Oct 24, 2014, Sebastian Geerken wrote: > I've problems to reproduce it, but I'm guessing ... > > On Do, Okt 23, 2014, eocene wrote: > > (gdb) bt > > #0 0xb778a424 in __kernel_vsyscall () > > #1 0xb70b2661 in *__GI_raise (sig=6) > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > > #3 0xb70ab878 in *__GI___assert_fail ( > > assertion=0x816049e "i >= 0 && this->num - i > 0", > > file=0x816048e "../lout/misc.hh", line=167, > > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 > > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > > this=0x905df50, i=-1) at ../lout/misc.hh:167 > > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > > at textblock_iterator.cc:288 > > A line is missing, but everything else seems OK. I guess that this has > to do with the new line breaking (introduced with release 3.0.3), > where some words are not immediately assigned to a line. I'll soon > work on this. I just pushed a fix. Does the problem still occur? Sebastian

Nov. 6, 2014

Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed.

by eocene＠gmx.com

outofflowmgr.cc:203: virtual int dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, lout::object::Object*): Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed. (gdb) bt #0 0xb7705424 in __kernel_vsyscall () #1 0xb702d661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7030a92 in *__GI_abort () at abort.c:92 #3 0xb7026878 in *__GI___assert_fail ( assertion=0x814bcf0 "oofm->wasAllocated (fl2->generatingBlock)", file=0x814bc53 "outofflowmgr.cc", line=203, function=0x814c2e0 "virtual int dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, lout::object::Object*)") at assert.c:81 #4 0x080b0a83 in dw::OutOfFlowMgr::Float::ComparePosition::compare ( this=0xbfcd6d6c, o1=0xbfcd6d18, o2=0x89c46d8) at outofflowmgr.cc:203 #5 0x080d926c in lout::container::untyped::Vector::bsearch (this=0x8b29898, key=0xbfcd6d18, mustExist=false, start=0, end=6, comparator=0xbfcd6d6c) at container.cc:239 #6 0x080b5607 in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x8a63970, key=0xbfcd6d18, mustExist=false, start=0, end=6, comparator=0xbfcd6d6c) at ../lout/container.hh:451 #7 0x080b0f24 in dw::OutOfFlowMgr::SortedFloatsVector::find (this=0x8a63970, textblock=0x887dc60, y=4079, start=0, end=6) at outofflowmgr.cc:382 #8 0x080b0fdd in dw::OutOfFlowMgr::SortedFloatsVector::findFirst ( this=0x8a63970, textblock=0x887dc60, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9, lastReturn=0x0) at outofflowmgr.cc:429 #9 0x080b458f in dw::OutOfFlowMgr::hasFloat (this=0x8a526d0, textblock=0x887dc60, side=dw::OutOfFlowMgr::LEFT, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9) at outofflowmgr.cc:2172 #10 0x080b44df in dw::OutOfFlowMgr::hasFloatLeft (this=0x8a526d0, textblock=0x887dc60, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9) at outofflowmgr.cc:2149 #11 0x080ac7c2 in dw::Textblock::calcBorders (this=0x887dc60, lastOofRef=-1, height=1) at textblock_linebreaking.cc:1986 #12 0x080aa385 in dw::Textblock::balanceBreakPosAndHeight (this=0x887dc60, wordIndex=19, firstIndex=10, searchUntil=0xbfcd6f58, tempNewLine=true, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0xbfcd6f5f, wrapAll=true, diffWords=0xbfcd6f60, wordIndexEnd=0xbfcd6f54, lastFloatPos=0xbfcd6f48, regardBorder=true, height=0xbfcd6f50, breakPos=0xbfcd6f4c) at textblock_linebreaking.cc:893 #13 0x080a9f81 in dw::Textblock::wrapWordInFlow (this=0x887dc60, wordIndex=19, wrapAll=true) at textblock_linebreaking.cc:728 #14 0x080a9bfa in dw::Textblock::wordWrap (this=0x887dc60, wordIndex=19, wrapAll=true) at textblock_linebreaking.cc:588 #15 0x080aca94 in dw::Textblock::showMissingLines (this=0x887dc60) at textblock_linebreaking.cc:2054 #16 0x0809febd in dw::Textblock::sizeAllocateImpl (this=0x887dc60, allocation=0xbfcd7160) at textblock.cc:562 #17 0x080d6ed5 in dw::core::Widget::sizeAllocate (this=0x887dc60, allocation=0xbfcd7160) at widget.cc:986 #18 0x080a0340 in dw::Textblock::sizeAllocateImpl (this=0x87fa748, allocation=0xbfcd7240) at textblock.cc:731 #19 0x080d6ed5 in dw::core::Widget::sizeAllocate (this=0x87fa748, allocation=0xbfcd7240) at widget.cc:986 #20 0x080cb35c in dw::core::Layout::resizeIdle (this=0x875f858) at layout.cc:912 #21 0x080b9b48 in dw::fltk::FltkPlatform::generalIdle (this=0x874fc58) at fltkplatform.cc:627 #22 0x080b9ad0 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x874fc58) at fltkplatform.cc:617

Nov. 5, 2014

what's currently broken in dillo

by higuita7＠yahoo.co.uk

> Please may I have: > - a screen shot of some of the breakage Screen shot attached.^H^H^H^H^H^H^H^H on the url below :) http://picpaste.com/gkrellShoot_11-04-14_235147-M4JGRxAA.jpg Note the images and next to the right the placeover where the image should be. > - the list of web bugs on the page 21 web bugs: HTML warning: line 95, <meta> must be inside the HEAD section. HTML warning: line 96, <meta> must be inside the HEAD section. HTML warning: line 97, <meta> must be inside the HEAD section. HTML warning: line 98, <meta> must be inside the HEAD section. HTML warning: line 99, <meta> must be inside the HEAD section. HTML warning: line 100, <meta> must be inside the HEAD section. HTML warning: line 101, <meta> must be inside the HEAD section. HTML warning: line 102, Unexpected closing tag: </head>. HTML warning: line 103, <body> was already open. HTML warning: line 718, <table> cellspacing attribute is obsolete. HTML warning: line 1063, <big> is obsolete in HTML5. HTML warning: line 1064, <big> is obsolete in HTML5. HTML warning: line 1069, <big> is obsolete in HTML5. HTML warning: line 1070, <big> is obsolete in HTML5. HTML warning: line 1075, <big> is obsolete in HTML5. HTML warning: line 1076, <big> is obsolete in HTML5. HTML warning: line 1079, <big> is obsolete in HTML5. HTML warning: line 1080, <big> is obsolete in HTML5. HTML warning: line 1095, <table> cellspacing attribute is obsolete. HTML warning: line 1158, <link> must be inside the HEAD section. HTML warning: line 1158, <link> must be inside the HEAD section. This witl fltk 1.3.2 and dillo e929d8bd7d6e tip Thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 5, 2014

what's currently broken in dillo

by higuita7＠yahoo.co.uk

On Tue, 4 Nov 2014 14:38:19 +0000, eocene <eocene at gmx.com> wrote: > Are you talking about the empty boxes to the left of the images? Looks > like it's some javascript thing. Yes! In firefox, if i disable javascript, the page still renders fine... but looking to the source, you may be right: <td><a href="/wiki/Fruits" class="image image-thumbnail link-internal" title="Fruits"> <img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" alt="Fruit" class="lzy lzyPlcHld " data-image-key="Fruit.png" data-image-name="Fruit.png" data-src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/t…" onload="if(typeof ImgLzy==='object'){ImgLzy.load(this)}" height="32" width="32"> <noscript> <img src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/t…" alt="Fruit" class="" data-image-key="Fruit.png" data-image-name="Fruit.png" height="32" width="32"> </noscript></a>?0.5 </td> So there are 2 image loaders, one with javascript, other without! So the problem is that dillo is loading BOTH, creating the empty square and the image right next to it, taken from the <noscript> block > > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function > > `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: > > undefined reference to `fl_oldfocus' collect2: error: ld returned 1 > > exit status make[3]: *** [dillo] Error 1 > I'm not sure why you're getting that. I found that if i revert to fltk 1.3.2 it works, again building the fltk 1.3.3, dillo build fails again. I have done make clean on fltk and dillo on every try and tried to clean the system from any old files, but same results. greping the both fltk version for fl_oldfocus, i get the same code, so is even weirder. Can someone reproduce this or i have something broken on my system? Thanks again higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 5, 2014

what's currently broken in dillo

by eocene＠gmx.com

> In the url below, all images are off the frame, making > everything look weird: > > http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes > > Disabling the CSS don't fix the problem. Are you talking about the empty boxes to the left of the images? Looks like it's some javascript thing. > Also, i tried to build fltk svn and dillo hg and dillo is > reporting this: > [snip] > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': > /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' > collect2: error: ld returned 1 exit status > make[3]: *** [dillo] Error 1 I'm not sure why you're getting that.

Nov. 4, 2014

what's currently broken in dillo

by james.from.wellington＠gmail.com

Hi Higuita, Please may I have: - a screen shot of some of the breakage - the list of web bugs on the page ? I have 21 web bugs, and see many black boxes, but the only thing that's obviously too far to the right is "A burnt Crock Pot from the Reign of Giants DLC". I'm running hg dillo dated 26 Oct 14 plus the diffs that I have sent to the list, one of which fixed some rendering problems for me, but this page is not obviously exercising it. Regards, James. On 11/4/14, higuita <higuita7 at yahoo.co.uk> wrote: > Hi > On Tue, 4 Nov 2014 00:26:47 +0000, eocene <eocene at gmx.com> wrote: >> Since fltk had a release today, I was thinking about where dillo stands >> at present. Here are the problems that I can think of: > > I wanted to report this for a long time, this seems a good > opportunity :) > > In the url below, all images are off the frame, making > everything look weird: > > http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes > > Disabling the CSS don't fix the problem. > > Also, i tried to build fltk svn and dillo hg and dillo is > reporting this: > > g++ -I/usr/include/libpng14 -I/usr/include/freetype2 -O2 -fPIC > -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE > -D_THREAD_SAFE -D_REENTRANT -g -O0 -fPIC -Wall -W -Wno-unused-parameter > -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o > tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o > history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o > timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o > css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o > dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o > ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a > ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 > -lpng14 -L/usr/lib64 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig > -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11 > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function > `dw::fltk::FltkViewBase::handle(int)': > /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined > reference to `fl_oldfocus' > collect2: error: ld returned 1 exit status > make[3]: *** [dillo] Error 1 > > Thanks for dillo > higuita > -- > Naturally the common people don't want war... but after all it is the > leaders of a country who determine the policy, and it is always a > simple matter to drag the people along, whether it is a democracy, or > a fascist dictatorship, or a parliament, or a communist dictatorship. > Voice or no voice, the people can always be brought to the bidding of > the leaders. That is easy. All you have to do is tell them they are > being attacked, and denounce the pacifists for lack of patriotism and > exposing the country to danger. It works the same in every country. > -- Hermann Goering, Nazi and war criminal, 1883-1946 >

Nov. 4, 2014

what's currently broken in dillo

by higuita7＠yahoo.co.uk

Hi On Tue, 4 Nov 2014 00:26:47 +0000, eocene <eocene at gmx.com> wrote: > Since fltk had a release today, I was thinking about where dillo stands > at present. Here are the problems that I can think of: I wanted to report this for a long time, this seems a good opportunity :) In the url below, all images are off the frame, making everything look weird: http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes Disabling the CSS don't fix the problem. Also, i tried to build fltk svn and dillo hg and dillo is reporting this: g++ -I/usr/include/libpng14 -I/usr/include/freetype2 -O2 -fPIC -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O0 -fPIC -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 -lpng14 -L/usr/lib64 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11 ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1 Thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Nov. 4, 2014

what's currently broken in dillo

by eocene＠gmx.com

Since fltk had a release today, I was thinking about where dillo stands at present. Here are the problems that I can think of: - vsource request crashes when dpid isn't working. - source is slow to render, presumably something to do with large tables. - on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing. - text search while loading, assert failed. - img alt text not constrained by width/height.

Nov. 4, 2014

SSL in the browser

by eocene＠gmx.com

I put up a new version that checks various locations for certificates and permits a location to be specified during configuration. It may not make any difference for osx, but maybe it will help the BSDs. http://www.dillo.org/test/ssl_in_browser.diff

Oct. 27, 2014

SSL in the browser

by james.from.wellington＠gmail.com

Firefox keeps them in a database called cert8.db in <user>/Library/Application Support/Firefox/Profiles/*/ Safari keeps them in /System/Library/Keychains/SystemCACertificates.keychain Neither of these formats is legible to OpenSSL. These comments are about Firefox 32.0.3, and OSX 10.6.8 which is now obsolete. Later versions may do things differently. On 10/26/14, eocene <eocene at gmx.com> wrote: > James wrote: >> Every certificate that doesn't have something at the root of its chain, as >> it should. I'm on osx and there is no /etc/ssl/certs, so I had no roots >> until I started loading them. > > Where does OSX keep them? > > I'd looked on the web a bit in the past in case there was any simple > consensus out there on the matter of where to check, but didn't find > anything. > > I'll see where curl checks. Whatever they do is probably a good idea. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 26, 2014

SSL in the browser

by eocene＠gmx.com

James wrote: > Every certificate that doesn't have something at the root of its chain, as it should. I'm on osx and there is no /etc/ssl/certs, so I had no roots until I started loading them. Where does OSX keep them? I'd looked on the web a bit in the past in case there was any simple consensus out there on the matter of where to check, but didn't find anything. I'll see where curl checks. Whatever they do is probably a good idea.

Oct. 26, 2014

SSL in the browser

by eocene＠gmx.com

James wrote: > I've got gmail going, using the ~/.dillo/certs certificate store. It > took a bit of poking around, so I'm attaching my notes to myself in > case they're useful for someone else. Is the code complaining about every certificate by default, or was gmail specifically giving you trouble?

Oct. 26, 2014

SSL in the browser

by james.from.wellington＠gmail.com

I've got gmail going, using the ~/.dillo/certs certificate store. It took a bit of poking around, so I'm attaching my notes to myself in case they're useful for someone else. On 10/23/14, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: >> Jorge wrote: >> > Oh, as our mailsearch doesn't work anymore, is there >> > and URL to the original thread (Gmane style) or something? >> > >> > I'd like to remember what the main point of having SSL inside >> > the browser were. I'm getting old. ;) >> >> Looking briefly, I couldn't find relevant discussion. Possibly it >> was off list. My recollection is that, at the time, it had to do with >> seeing how SSL was becoming more and more central to browsing with >> things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' >> coming along and the issue of privacy gaining increasing public >> awareness. >> >> As for this effort now, I started just by wondering what it would >> look like if I integrated Benjamin's code and took out the windows >> stuff. It was working pretty well very quickly. And now I like how >> much more respectful of servers and resources Dillo can be when >> HTTPS is integrated with the http_max_conns queuing and >> http_persistent_conns. I think Johannes mentioned something about >> Dillo and Tor not working together so well with HTTPS in a dpi, >> but I don't know the details there. > > There is a potential loophole if you start dillo in a torified > environment and dpid is running outside. Then https connections go > via the non-torified https plugin. It's a small detail, but it > happened to me. > I'm mostly interested in getting SSL support from unmaintained > experimental state to properly supported and maintained option. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 26, 2014

assert failed when using text search while page still loading

by sgeerken＠dillo.org

I've problems to reproduce it, but I'm guessing ... On Do, Okt 23, 2014, eocene wrote: > (gdb) bt > #0 0xb778a424 in __kernel_vsyscall () > #1 0xb70b2661 in *__GI_raise (sig=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > #3 0xb70ab878 in *__GI___assert_fail ( > assertion=0x816049e "i >= 0 && this->num - i > 0", > file=0x816048e "../lout/misc.hh", line=167, > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > this=0x905df50, i=-1) at ../lout/misc.hh:167 > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > at textblock_iterator.cc:288 A line is missing, but everything else seems OK. I guess that this has to do with the new line breaking (introduced with release 3.0.3), where some words are not immediately assigned to a line. I'll soon work on this. Sebastian

Oct. 24, 2014

assert failed when using text search while page still loading

by james.from.wellington＠gmail.com

Here's a swag: - the search and the assembly of the page are in separate threads - the search finds the word - layout hasn't been done yet - so there is no line number to find Presumably, if things were earlier in the assembly of the page, the search would refuse to start, because it couldn't see the text to search. Suggested bodge: whatever chain of pointers the search follows, in order to decide whether to start, keep more of them private inside the page assembler, for longer, so that the searcher can't see this transient state. In the data structure, document the set of things that must be true before it can be published to other threads. On 10/24/14, eocene <eocene at gmx.com> wrote: > > (gdb) bt > #0 0xb778a424 in __kernel_vsyscall () > #1 0xb70b2661 in *__GI_raise (sig=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > #3 0xb70ab878 in *__GI___assert_fail ( > assertion=0x816049e "i >= 0 && this->num - i > 0", > file=0x816048e "../lout/misc.hh", line=167, > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const > [with T = dw::Textblock::Line]") at assert.c:81 > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > this=0x905df50, i=-1) at ../lout/misc.hh:167 > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > at textblock_iterator.cc:288 > #6 0x080c65f7 in dw::core::Iterator::scrollTo (it1=0x885ef98, > it2=0x948efe0, > start=0, end=5, hpos=dw::core::HPOS_INTO_VIEW, > vpos=dw::core::VPOS_CENTER) > at iterator.cc:108 > #7 0x080c621e in dw::core::DeepIterator::scrollTo (it1=0x88e86e8, > it2=0x885efb8, start=0, end=5, hpos=dw::core::HPOS_INTO_VIEW, > vpos=dw::core::VPOS_CENTER) at iterator.hh:229 > #8 0x080c629a in dw::core::CharIterator::scrollTo (it1=0x89c6e60, > it2=0x8872900, hpos=dw::core::HPOS_INTO_VIEW, > vpos=dw::core::VPOS_CENTER) > at iterator.hh:265 > #9 0x080c5bcb in dw::core::FindtextState::search (this=0x8a02a40, > key=0x88dbd70 "dillo", caseSens=false, backwards=false) at > findtext.cc:120 > #10 0x08057cad in dw::core::Layout::search (this=0x8a02970, > str=0x88dbd70 "dillo", caseSens=false, backwards=0) at > ../dw/layout.hh:444 > #11 0x080579e5 in a_UIcmd_findtext_search (bw=0x8ae1940, > key=0x88dbd70 "dillo", case_sens=0, backward=0) at uicmd.cc:1484 > #12 0x0808c7c3 in Findbar::search_cb (vfb=0x8a08808) at findbar.cc:86 > #13 0x081075e1 in Fl_Widget::do_callback (this=0x8882020, o=0x8882020, > arg=0x8a08808) at Fl_Widget.cxx:328 > #14 0x080e305d in do_callback (this=0x8882020) at ../FL/Fl_Widget.H:840 > #15 Fl_Button::handle (this=0x8882020, event=12) at Fl_Button.cxx:164 > #16 0x080503c9 in TipWinButton::handle (this=0x8882020, e=12) at > tipwin.cc:158 > #17 0x08050536 in CustButton::handle (this=0x8882020, e=12) at > tipwin.cc:194 > #18 0x080e4b64 in send (o=o at entry=0x8882020, event=event at entry=12) > at Fl_Group.cxx:98 > #19 0x080e5755 in Fl_Group::handle (this=0x8a08808, event=12) > at Fl_Group.cxx:185 > #20 0x0808cd72 in Findbar::handle (this=0x8a08808, event=12) at > findbar.cc:192 > #21 0x080e4b64 in send (o=o at entry=0x8a08808, event=event at entry=12) > at Fl_Group.cxx:98 > #22 0x080e5755 in Fl_Group::handle (this=0x88e9218, event=12) > at Fl_Group.cxx:185 > #23 0x08052f2f in UI::handle (this=0x88e9218, event=12) at ui.cc:788 > #24 0x080dc5d2 in send (event=event at entry=12, to=to at entry=0x88e9218, > window=<optimized out>) at Fl.cxx:1143 > #25 0x080dd421 in Fl::handle_ (e=12, window=0x8806268) at Fl.cxx:1401 > #26 0x080dd368 in Fl::handle_ (e=8, window=0x8806268) at Fl.cxx:1379 > #27 0x0810bbc0 in fl_handle (thisevent=...) at Fl_x.cxx:2144 > #28 0x0810d89e in do_queued_events () at Fl_x.cxx:210 > #29 0x0810d93f in fl_wait (time_to_wait=0) at Fl_x.cxx:235 > #30 0x080de3d2 in Fl::wait (time_to_wait=<optimized out>, > time_to_wait at entry=<error reading variable: Could not find type for > DW_OP_GNU_const_type>) at Fl.cxx:566 > #31 0x080de46e in Fl::run () at Fl.cxx:589 > #32 0x0804f933 in main (argc=1, argv=0xbff2f214) at dillo.cc:586 > > I see that it's unhappy in > Textblock::TextblockIterator::getAllocation() where index was 34 and > lineIndex = textblock->findLineOfWord (index); results in -1, which > the getRef() doesn't want at all... > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Oct. 24, 2014

assert failed when using text search while page still loading

by eocene＠gmx.com

(gdb) bt #0 0xb778a424 in __kernel_vsyscall () #1 0xb70b2661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb70b5a92 in *__GI_abort () at abort.c:92 #3 0xb70ab878 in *__GI___assert_fail ( assertion=0x816049e "i >= 0 && this->num - i > 0", file=0x816048e "../lout/misc.hh", line=167, function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( this=0x905df50, i=-1) at ../lout/misc.hh:167 #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( this=0x885ef98, start=0, end=5, allocation=0xbff2e818) at textblock_iterator.cc:288 #6 0x080c65f7 in dw::core::Iterator::scrollTo (it1=0x885ef98, it2=0x948efe0, start=0, end=5, hpos=dw::core::HPOS_INTO_VIEW, vpos=dw::core::VPOS_CENTER) at iterator.cc:108 #7 0x080c621e in dw::core::DeepIterator::scrollTo (it1=0x88e86e8, it2=0x885efb8, start=0, end=5, hpos=dw::core::HPOS_INTO_VIEW, vpos=dw::core::VPOS_CENTER) at iterator.hh:229 #8 0x080c629a in dw::core::CharIterator::scrollTo (it1=0x89c6e60, it2=0x8872900, hpos=dw::core::HPOS_INTO_VIEW, vpos=dw::core::VPOS_CENTER) at iterator.hh:265 #9 0x080c5bcb in dw::core::FindtextState::search (this=0x8a02a40, key=0x88dbd70 "dillo", caseSens=false, backwards=false) at findtext.cc:120 #10 0x08057cad in dw::core::Layout::search (this=0x8a02970, str=0x88dbd70 "dillo", caseSens=false, backwards=0) at ../dw/layout.hh:444 #11 0x080579e5 in a_UIcmd_findtext_search (bw=0x8ae1940, key=0x88dbd70 "dillo", case_sens=0, backward=0) at uicmd.cc:1484 #12 0x0808c7c3 in Findbar::search_cb (vfb=0x8a08808) at findbar.cc:86 #13 0x081075e1 in Fl_Widget::do_callback (this=0x8882020, o=0x8882020, arg=0x8a08808) at Fl_Widget.cxx:328 #14 0x080e305d in do_callback (this=0x8882020) at ../FL/Fl_Widget.H:840 #15 Fl_Button::handle (this=0x8882020, event=12) at Fl_Button.cxx:164 #16 0x080503c9 in TipWinButton::handle (this=0x8882020, e=12) at tipwin.cc:158 #17 0x08050536 in CustButton::handle (this=0x8882020, e=12) at tipwin.cc:194 #18 0x080e4b64 in send (o=o at entry=0x8882020, event=event at entry=12) at Fl_Group.cxx:98 #19 0x080e5755 in Fl_Group::handle (this=0x8a08808, event=12) at Fl_Group.cxx:185 #20 0x0808cd72 in Findbar::handle (this=0x8a08808, event=12) at findbar.cc:192 #21 0x080e4b64 in send (o=o at entry=0x8a08808, event=event at entry=12) at Fl_Group.cxx:98 #22 0x080e5755 in Fl_Group::handle (this=0x88e9218, event=12) at Fl_Group.cxx:185 #23 0x08052f2f in UI::handle (this=0x88e9218, event=12) at ui.cc:788 #24 0x080dc5d2 in send (event=event at entry=12, to=to at entry=0x88e9218, window=<optimized out>) at Fl.cxx:1143 #25 0x080dd421 in Fl::handle_ (e=12, window=0x8806268) at Fl.cxx:1401 #26 0x080dd368 in Fl::handle_ (e=8, window=0x8806268) at Fl.cxx:1379 #27 0x0810bbc0 in fl_handle (thisevent=...) at Fl_x.cxx:2144 #28 0x0810d89e in do_queued_events () at Fl_x.cxx:210 #29 0x0810d93f in fl_wait (time_to_wait=0) at Fl_x.cxx:235 #30 0x080de3d2 in Fl::wait (time_to_wait=<optimized out>, time_to_wait at entry=<error reading variable: Could not find type for DW_OP_GNU_const_type>) at Fl.cxx:566 #31 0x080de46e in Fl::run () at Fl.cxx:589 #32 0x0804f933 in main (argc=1, argv=0xbff2f214) at dillo.cc:586 I see that it's unhappy in Textblock::TextblockIterator::getAllocation() where index was 34 and lineIndex = textblock->findLineOfWord (index); results in -1, which the getRef() doesn't want at all...

Oct. 23, 2014

SSL in the browser

by johannes.hofmann＠gmx.de

On Tue, Oct 21, 2014 at 04:42:24PM +0000, eocene wrote: > Jorge wrote: > > Oh, as our mailsearch doesn't work anymore, is there > > and URL to the original thread (Gmane style) or something? > > > > I'd like to remember what the main point of having SSL inside > > the browser were. I'm getting old. ;) > > Looking briefly, I couldn't find relevant discussion. Possibly it > was off list. My recollection is that, at the time, it had to do with > seeing how SSL was becoming more and more central to browsing with > things like 'HTTPS Everywhere' and 'HTTP Strict Transport Security' > coming along and the issue of privacy gaining increasing public > awareness. > > As for this effort now, I started just by wondering what it would > look like if I integrated Benjamin's code and took out the windows > stuff. It was working pretty well very quickly. And now I like how > much more respectful of servers and resources Dillo can be when > HTTPS is integrated with the http_max_conns queuing and > http_persistent_conns. I think Johannes mentioned something about > Dillo and Tor not working together so well with HTTPS in a dpi, > but I don't know the details there. There is a potential loophole if you start dillo in a torified environment and dpid is running outside. Then https connections go via the non-torified https plugin. It's a small detail, but it happened to me. I'm mostly interested in getting SSL support from unmaintained experimental state to properly supported and maintained option. Cheers, Johannes

Oct. 23, 2014