- Dillo-dev - lists.mailman3.com

Dillo documentation delivered daily
by onepoint＠starurchin.org 04 Mar '15

04 Mar '15

My website is up again[1] and I have added a daily build of the Dillo documentation (having noticed that the version on the Dillo site is over a year old). HTML: http://starurchin.org/dillo/doc/html/index.html tarball: http://starurchin.org/dillo/doc/dillo-doc.tar.gz (Note that the tarball has moved from its old location.) Doxygen generates quite a few errors when building the docs. I would like to fix them (if only to have less noise from my cron jobs). Would the Dillo devs be interested in the patches? Regards Jeremy Henty [1] Nginx spontaneously decided not to run until I tweaked its configuration. No idea why, but at least it is fixed.

2 1

a different lines->getRef() segfault
by eocene＠gmx.com 02 Mar '15

02 Mar '15

A new page was just coming in -- seems like the same sort of problem as last time. (gdb) bt #0 0xb77bb424 in __kernel_vsyscall () #1 0xb72f9661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb72fca92 in *__GI_abort () at abort.c:92 #3 0xb72f2878 in *__GI___assert_fail ( assertion=0x8151afe "i >= 0 && this->num - i > 0", file=0x8151aee "../lout/misc.hh", line=167, function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( this=0x953b618, i=-1) at ../lout/misc.hh:167 #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) at textblock.cc:1093 #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, event=0xbfbb8180) at textblock.cc:1008 #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, event=0xbfbb8180) at widget.cc:1027 #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at layout.cc:1234 #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.cc:1023 #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.hh:345 #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, event=2) at fltkviewbase.cc:319 #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, event=2) at fltkviewport.cc:331 #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () #15 0x080dff0e in Fl::handle(int, Fl_Window*) () #16 0x08107e9d in fl_handle(_XEvent const&) () #17 0x08107fbc in do_queued_events() () #18 0x0810822a in fl_wait(double) () #19 0x080e08af in Fl::wait(double) () #20 0x080e099d in Fl::run() () #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588

2 2

what's currently broken in dillo
by eocene＠gmx.com 28 Feb '15

28 Feb '15

from my notes. I think all of this was mentioned on list: --local ... reload turns off URL_SpamSafe, but there it is again upon repush. > I found that shift+arrows in the url bar is doing nothing instead > of selecting the text. Ctrl+shift+arrows work fine. dd search url not removed when dillorc has search urls. background image oddities Jan 15 jan 17 edge.org page parbreak issue another lines->getRef segfault Jorge's slashdot hang the interlaced gif on forum.thinkpads.com feb 10 news.sciencemag.org hangs As for speed, I'd spent enough time with dillo being pretty slow before those optimizations were made in the past month or two that I've somewhat lost my feel for how fast dillo is supposed to be...

3 2

outofflowmgr.cc:1527: Assertion `yReq >= 0' failed.
by eocene＠gmx.com 12 Feb '15

12 Feb '15

outofflowmgr.cc:1527: void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int): Assertion `yReq >= 0' failed. At http://darwinday.org/events/ #0 0xb775e424 in __kernel_vsyscall () #1 0xb7083661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7086a92 in *__GI_abort () at abort.c:92 #3 0xb707c878 in *__GI___assert_fail (assertion=0x8158124 "yReq >= 0", file=0x8158073 "outofflowmgr.cc", line=1527, function=0x81584a0 "void dw::OutOfFlowMgr::tellFloatPosition(dw::core::Widget*, int)") at assert.c:81 #4 0x080b8016 in dw::OutOfFlowMgr::tellFloatPosition (this=0x844f5b0, widget= 0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1527 #5 0x080b7fdd in dw::OutOfFlowMgr::tellPosition (this=0x844f5b0, widget=0x8cda630, yReq=-1348746332) at outofflowmgr.cc:1516 #6 0x080aed85 in dw::Textblock::wrapWordInFlow (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:788 #7 0x080ae8c0 in dw::Textblock::wordWrap (this=0x844ed10, wordIndex=9, wrapAll=true) at textblock_linebreaking.cc:606 #8 0x080b1842 in dw::Textblock::showMissingLines (this=0x844ed10) at textblock_linebreaking.cc:2113 #9 0x080a431d in dw::Textblock::sizeRequestImpl (this=0x844ed10, requisition=0xbfeaa950) at textblock.cc:342 #10 0x080dafc0 in dw::core::Widget::sizeRequest (this=0x844ed10, requisition=0xbfeaa950) at widget.cc:494 #11 0x080b71c7 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x844f5b0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #12 0x080b67ae in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x844f5b0, caller=0x844ed10) at outofflowmgr.cc:651 #13 0x080a4e6b in dw::Textblock::sizeAllocateImpl (this=0x844ed10, allocation=0xbfeaab00) at textblock.cc:759 #14 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x844ed10, allocation=0xbfeaab00) at widget.cc:993 #15 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468b58, allocation=0xbfeaabf0) at textblock.cc:744 #16 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468b58, allocation=0xbfeaabf0) at widget.cc:993 #17 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8468278, allocation=0xbfeaace0) at textblock.cc:744 #18 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8468278, allocation=0xbfeaace0) at widget.cc:993 #19 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x89c7ed8, allocation=0xbfeaadd0) at textblock.cc:744 #20 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x89c7ed8, allocation=0xbfeaadd0) at widget.cc:993 #21 0x080a4d8d in dw::Textblock::sizeAllocateImpl (this=0x8a04228, allocation=0xbfeaaeb0) at textblock.cc:744 #22 0x080dbe93 in dw::core::Widget::sizeAllocate (this=0x8a04228, #23 0x080d0230 in dw::core::Layout::resizeIdle (this=0x83a3688) at layout.cc:912 #24 0x080be150 in dw::fltk::FltkPlatform::generalIdle (this=0x83946e0) at fltkplatform.cc:630 #25 0x080be0d8 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x83946e0) at fltkplatform.cc:620 #26 0x08106e5c in call_idle() () #27 0x080e3eb5 in Fl::wait(double) () #28 0x080e3ff5 in Fl::run() () #29 0x08053b6f in main (argc=2, argv=0xbfeab0d4) at dillo.cc:590

1 0

page that hangs
by eocene＠gmx.com 10 Feb '15

10 Feb '15

news.sciencemag.org Under gdb, breaking in and having a look at the backtrace always showed a series of rewrap()... (gdb) bt #0 0x08051680 in mcount at plt () #1 0x080b753f in lout::object::TypedPointer<dw::Textblock>::~TypedPointer ( this=0xbfffedf4, __in_chrg=<optimized out>) at ../lout/object.hh:115 #2 0x080b5b36 in dw::OutOfFlowMgr::getTextblock (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.cc:1956 #3 0x080b6aa1 in dw::OutOfFlowMgr::getAllocation (this=0x825aa00, textblock=0x862f5e0) at outofflowmgr.hh:252 #4 0x080b288c in dw::OutOfFlowMgr::Float::ComparePosition::compare ( this=0xbfffef7c, o1=0xbfffef28, o2=0x83eb728) at outofflowmgr.cc:233 #5 0x080db204 in lout::container::untyped::Vector::bsearch (this=0x82466c8, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at container.cc:239 #6 0x080b6d8b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x82466b0, key=0xbfffef28, mustExist=false, start=0, end=5, comparator=0xbfffef7c) at ../lout/container.hh:451 #7 0x080b2cba in dw::OutOfFlowMgr::SortedFloatsVector::find (this=0x82466b0, textblock=0x862f5e0, y=61080, start=0, end=5) at outofflowmgr.cc:385 #8 0x080b2d73 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst ( this=0x82466b0, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:432 #9 0x080b6069 in dw::OutOfFlowMgr::getFloatHeight (this=0x825aa00, textblock=0x862f5e0, side=dw::OutOfFlowMgr::LEFT, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2143 #10 0x080b5fc5 in dw::OutOfFlowMgr::getLeftFloatHeight (this=0x825aa00, textblock=0x862f5e0, y=61080, h=1, lastGB=0x862f5e0, lastExtIndex=-1) at outofflowmgr.cc:2125 #11 0x080ae637 in dw::Textblock::calcBorders (this=0x862f5e0, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2058 #12 0x080ac011 in dw::Textblock::balanceBreakPosAndHeight (this=0x862f5e0, wordIndex=0, firstIndex=0, searchUntil=0xbffff168, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0xbffff16f, wrapAll=false, diffWords=0xbffff170, wordIndexEnd=0xbffff164, lastFloatPos=0xbffff158, regardBorder=true, height=0xbffff160, breakPos=0xbffff15c) at textblock_linebreaking.cc:910 #13 0x080abc03 in dw::Textblock::wrapWordInFlow (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:746 #14 0x080ab87c in dw::Textblock::wordWrap (this=0x862f5e0, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #15 0x080ae17c in dw::Textblock::rewrap (this=0x862f5e0) at textblock_linebreaking.cc:1891 #16 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f5e0, requisition=0x8635f80) at textblock.cc:341 #17 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f5e0, requisition=0x8635f80) at widget.cc:494 #18 0x080ae159 in dw::Textblock::rewrap (this=0x862f098) at textblock_linebreaking.cc:1889 #19 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862f098, requisition=0x862f370) at textblock.cc:341 #20 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862f098, requisition=0x862f370) at widget.cc:494 #21 0x080ae159 in dw::Textblock::rewrap (this=0x862ea18) at textblock_linebreaking.cc:1889 #22 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862ea18, requisition=0x862ee18) at textblock.cc:341 #23 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862ea18, requisition=0x862ee18) at widget.cc:494 #24 0x080ae159 in dw::Textblock::rewrap (this=0x862b748) at textblock_linebreaking.cc:1889 #25 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b748, requisition=0x862b9f8) at textblock.cc:341 #26 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b748, requisition=0x862b9f8) at widget.cc:494 #27 0x080ae159 in dw::Textblock::rewrap (this=0x862b0a0) at textblock_linebreaking.cc:1889 #28 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x862b0a0, requisition=0x862b478) at textblock.cc:341 #29 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x862b0a0, requisition=0x862b478) at widget.cc:494 #30 0x080ae159 in dw::Textblock::rewrap (this=0x835e868) at textblock_linebreaking.cc:1889 #31 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x835e868, requisition=0x855357c) at textblock.cc:341 #32 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x835e868, requisition=0x855357c) at widget.cc:494 #33 0x080ae159 in dw::Textblock::rewrap (this=0x82846b8) at textblock_linebreaking.cc:1889 #34 0x080a12ce in dw::Textblock::sizeRequestImpl (this=0x82846b8, requisition=0xbffff750) at textblock.cc:341 #35 0x080d7f7c in dw::core::Widget::sizeRequest (this=0x82846b8, requisition=0xbffff750) at widget.cc:494 #36 0x080b4183 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x825aa00, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #37 0x080b376a in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x825aa00, caller=0x82846b8) at outofflowmgr.cc:651 #38 0x080a1e27 in dw::Textblock::sizeAllocateImpl (this=0x82846b8, allocation=0xbffff8f0) at textblock.cc:759 #39 0x080d8e4f in dw::core::Widget::sizeAllocate (this=0x82846b8, allocation=0xbffff8f0) at widget.cc:993 #40 0x080cd1ec in dw::core::Layout::resizeIdle (this=0x81f2940) at layout.cc:912 #41 0x080bb10c in dw::fltk::FltkPlatform::generalIdle (this=0x81e2d38) at fltkplatform.cc:630 #42 0x080bb094 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x81e2d38) at fltkplatform.cc:620 #43 0x08103e18 in call_idle() () #44 0x080e0e71 in Fl::wait(double) () #45 0x080e0fb1 in Fl::run() () #46 0x08052f7a in main (argc=1, argv=0xbffffb14) at dillo.cc:588

1 0

Core-dump pasting from one form field into another
by james.from.wellington＠gmail.com 02 Feb '15

02 Feb '15

Hello All, This is exercisable in Dillo 3.0.4.1, but not new. I found it by accident in my hack-up of Dillo 3.0.4. The reproduction is: - enable cookies for .google.com - navigate to https://mail.google.com/mail/?ui=html - fight the links until you get a screen with two fields, one for the username and one for the password - type something into the username field - select it and drag to the password field -- core dump I am on: - OSX 10.6.8 - Dillo 3.0.4.1 with SSL enabled - FLTK 1.3.3 - with dpid, etc from Dillo 3.0.4 with extensive hacking so the fault could be Mac-specific. Essentially the same fault (in Fl::dnd()) is reproducible in clean Dillo 3.0.4, with FLTK 1.3.2, clean dpid, etc, so I *think* it's not a product of my hackery. Clean Dillo 3.0.4 does not report the CGContextSetShouldAntialias and related errors, so I *think* that they are unrelated. Some errors and backtrace below. So far, I have not reproduced this fault in the FLTK input test program. Does anyone have a favourite piece of form html for me to try, to see if we can get out of needing gmail for the reproduction. Regards, James. ======================== Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetTextPosition: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Sat Dec 27 12:16:00 James-MacBook.local dillo[93125] <Error>: CGContextSetShouldAntialias: invalid context 0x0 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x00007fff8a1cd7cd in __dynamic_cast () (gdb) bt #0 0x00007fff8a1cd7cd in __dynamic_cast () #1 0x000000010009b318 in Fl::dnd () at Fl_cocoa.mm:3792 #2 0x00000001000aee3f in Fl_Input::handle (this=<value temporarily unavailable, due to optimizations>, event=<value temporarily unavailable, due to optimizations>) at Fl_Input.cxx:681 #3 0x0000000100071187 in CustInput2::handle (this=0x103c10a00, e=5) at fltkui.cc:86 #4 0x000000010009cfda in send (event=<value temporarily unavailable, due to optimizations>, to=<value temporarily unavailable, due to optimizations>, window=<value temporarily unavailable, due to optimizations>) at Fl.cxx:1143 #5 0x000000010009eaf7 in Fl::handle_ (e=5, window=0x102a1e020) at Fl.cxx:1455 #6 0x000000010009ad28 in cocoaMouseHandler (theEvent=0x100565980) at Fl_cocoa.mm:1057 #7 0x00007fff890580c7 in -[NSWindow sendEvent:] () #8 0x00007fff88f8cafa in -[NSApplication sendEvent:] () #9 0x000000010009af43 in +[FLApplication sendEvent:] (self=<value temporarily unavailable, due to optimizations>, _cmd=<value temporarily unavailable, due to optimizations>, theEvent=0x100565980) at Fl_cocoa.mm:1453 #10 0x000000010009883a in do_queued_events (time=1e+20) at Fl_cocoa.mm:772 #11 0x000000010009b175 in fl_wait [inlined] () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/src/Fl_cocoa.mm:796 #12 0x000000010009b175 in fl_mac_flush_and_wait (time_to_wait=1e+20) at Fl_cocoa.mm:815 #13 0x000000010009df39 in Fl::run () at Fl.cxx:589 #14 0x0000000100004819 in main (argc=1, argv=0x7fff5fbff3f0) at dillo.cc:572 (gdb)

4 8

an interlaced gif doesn't finish drawing
by eocene＠gmx.com 25 Jan '15

25 Jan '15

I've consistently noticed that the image in the upper left corner of http://forum.thinkpads.com doesn't finish drawing initially. If I isolate the image or click to a second page, it'll show the whole thing properly.

1 0

form input placeholder text
by eocene＠gmx.com 24 Jan '15

24 Jan '15

Everyone's getting into the habit of using the html5 placeholder attributes on form inputs to tell users what the inputs are for, decreasing usability for the rest of us, so I implemented it for INPUT text/password. (It's also legal on TEXTAREA.) http://www.dillo.org/test/input_placeholder.diff

1 1

How to do a local install?
by waltdnes＠waltdnes.org 22 Jan '15

22 Jan '15

It's taken me a while to get around to trying to install from the git repository. With experimental stuff, I prefer to do things in my local directory, so that if it blows up, it doesn't blow up with root permissions. I've done this in the past with other software, so I think it can be done. Note that I'm running in Gentoo, if it makes any difference. I have fltk-1.3.2 installed with USE="opengl threads xft" enabled and other fltk options disabled. Here's my /home/waltdnes/dillo/dbuild script, which I've loosely based on instructions at http://www.dillo.org/source.html After the initial "hg clone" command, updates are pulled in by "git pull" from inside the dillo3 directory; is that correct? #!/bin/bash # hg clone http://hg.dillo.org/dillo dillo3 cd /home/waltdnes/dillo/dillo3 PREFIX=/home/waltdnes/.local CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS=${CFLAGS} make clean git pull ./autogen.sh ./configure make make install-strip The process works until the last step, where it's suggested to sudo, to allow installing in /usr/local It fails like so... make[4]: Entering directory '/home/waltdnes/dillo/dillo3/src' /bin/mkdir -p '/usr/local/bin' /bin/sh /home/waltdnes/dillo/dillo3/install-sh -c -s dillo '/usr/local/bin' cp: cannot create regular file '/usr/local/bin/_inst.22011_': Permission denied Makefile:538: recipe for target 'install-binPROGRAMS' failed make[4]: *** [install-binPROGRAMS] Error 1 make[4]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:856: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:695: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:469: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/waltdnes/dillo/dillo3' Makefile:767: recipe for target 'install-strip' failed make: *** [install-strip] Error 2 What settings do I need to make to get the install totally in my home directory? While I'm at it, what are the manual tweaks to enable "gif jpeg png ssl" and disable "-doc -ipv6" in the build? Can all the settings be put into local.mk, so I can "set it and forget it"? -- Walter Dnes <waltdnes at waltdnes.org>

3 3

addParbreak, display:inline
by eocene＠gmx.com 19 Jan '15

19 Jan '15

I was looking at why the page numbers at the bottom of a startpage search results page aren't visible. It seems that the numbers are forms with display:inline. open_form has HT2TB(html)->addParbreak (9, html->wordStyle ()); Am I correct in thinking that the assorted addParbreak()s have to come out at some point for display to work, or is there some other plan? I note that the html5 spec has: "In quirks mode, the following rules are also expected to apply: ... form { margin-bottom: 1em; }" to provide the gap in this case.

1 0