- Dillo-dev - lists.mailman3.com

weirdly scaled images

by Johannes.Hofmann＠gmx.de

Hi v4hn, On Fri, Jul 10, 2015 at 12:55:33AM +0200, v4hn wrote: > Hey everyone, > > thanks for the great project. :-) > It is awesome to have a graphical browser at ones hand > that starts up in less than a second > and still supports most of the stuff I need. > > Now, for quite some time I've been using dillo to read news > on http://www.heise.de and it has always annoyed me > that some of the images on the main page are weirdly scaled. > Because these images are of size 160x90 but are scaled to > what feels like 98% of the window's width, they are barely recognizable > and distracting. I think this is fixed in main line for quite some while. Can you please try to build from the repo (http://www.dillo.org/source.html) and try again? Cheers, Johannes

Aug. 15, 2015

Dillo CPU-hog lock on slashdot

by james.from.wellington＠gmail.com

This page exercises the spin, on the current default source: http://thedailyblog.co.nz/2015/07/27/new-zealand-in-denial-a-review-of-jane… The non-finishing part of the stack is dw::Textblock::wrapWordInFlow and below: #0 dw::Textblock::wrapWordInFlow (this=0x1179e9b50, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:732 #1 0x000000010007729f in dw::Textblock::wordWrap (this=0x1179e9b50, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #2 0x0000000100074633 in dw::Textblock::rewrap (this=0x1179e9b50) at textblock_linebreaking.cc:1891 #3 0x000000010006f6a5 in dw::Textblock::sizeRequestImpl (this=0x1179e9b50, requisition=0x101a30bf0) at textblock.cc:341 #4 0x00000001000a101f in dw::core::Widget::sizeRequest (this=0x1179e9b50, requisition=0x101a30bf0) at widget.cc:494 #5 0x0000000100074615 in dw::Textblock::rewrap (this=0x100d5bff0) at textblock_linebreaking.cc:1889 #6 0x000000010006f6a5 in dw::Textblock::sizeRequestImpl (this=0x100d5bff0, requisition=0x7fff5fbfeea0) at textblock.cc:341 #7 0x00000001000a101f in dw::core::Widget::sizeRequest (this=0x100d5bff0, requisition=0x7fff5fbfeea0) at widget.cc:494 #8 0x000000010005cb60 in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x11775ff10, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #9 0x000000010005fbeb in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x11775ff10, caller=0x100d5bff0) at outofflowmgr.cc:651 (More stack frames follow...) On 21/01/2015, James C <james.from.wellington at gmail.com> wrote: > Hello Jorge et al, > > Partly reproduced on OSX, on a branch that includes the repository up > to 26 October, and eocene's SSL patch. The CPU and memory use is > reasonable, but the stop icon does not turn grey. Fields on the right > show "8 of 9" in black and "264.5 KB" in grey. > > Reproduced on OSX with the tip (changeset 553bbaa) of the default > branch. Uses 100% of cpu and does not respond to Cmd-Q quit request. > Fields on the right show "5 of 10" in black and "181.4 KB" in grey. > Because the window won't scroll, it's hard to tell how much has > rendered. > > Ignorant GDB exploring below. It seems to be struggling with > word-wrap, tables, etc. > > Bin-packing is in NP-hard. I wonder what the right algorithm is for > good table rendering. > > Regards, > James. > > =============== > > Program received signal SIGINT, Interrupt. > 0x00000001000a09f9 in lout::container::untyped::HashSet::calcHashValue > (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.hh:242 > 242 return abs(object->hashValue()) % tableSize; > (gdb) bt > #0 0x00000001000a09f9 in > lout::container::untyped::HashSet::calcHashValue (this=0x116b1bd90, > object=0x7fff5fbfdb80) at container.hh:242 > #1 0x000000010009eeb9 in lout::container::untyped::HashSet::findNode > (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.cc:497 > #2 0x000000010009f2e3 in lout::container::untyped::HashTable::get > (this=0x116b1bd90, key=0x7fff5fbfdb80) at container.cc:704 > #3 0x000000010005d83c in > lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, > dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) > at container.hh:524 > #4 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock > (this=0x116b1bb60, textblock=0x116bf7270) at outofflowmgr.cc:1954 > #5 0x0000000100059ad5 in > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at > outofflowmgr.cc:291 > #6 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, > end=38, comparator=0x7fff5fbfdd80) at container.cc:239 > #7 0x000000010005de36 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:159 > #8 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:456 > #9 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > #10 0x000000010005b986 in > dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, > textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, > lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 > #11 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat > (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, > y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:2115 > #12 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft > (this=0x116b1bb60, textblock=0x116bf7270, y=330882, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 > #13 0x000000010006fdb2 in dw::Textblock::calcBorders > (this=0x116bf7270, lastOofRef=-1, height=1) at > textblock_linebreaking.cc:2045 > #14 0x0000000100071f2b in dw::Textblock::balanceBreakPosAndHeight > (this=0x116bf7270, wordIndex=0, firstIndex=0, > searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, > borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, > wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, > lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, > breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:910 > #15 0x00000001000729d2 in dw::Textblock::wrapWordInFlow > (this=0x116bf7270, wordIndex=0, wrapAll=false) at > textblock_linebreaking.cc:746 > #16 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116bf7270, > wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 > #17 0x00000001000701b7 in dw::Textblock::rewrap (this=0x116bf7270) at > textblock_linebreaking.cc:1891 > #18 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf7270, requisition=0x116bf7600) at textblock.cc:341 > #19 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf7270, requisition=0x116bf7600) at widget.cc:494 > #20 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf6ce0) at > textblock_linebreaking.cc:1889 > #21 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf6ce0, requisition=0x116bf8ac0) at textblock.cc:341 > #22 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf6ce0, requisition=0x116bf8ac0) at widget.cc:494 > #23 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf67c0) at > textblock_linebreaking.cc:1889 > #24 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf67c0, requisition=0x11713ac20) at textblock.cc:341 > #25 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf67c0, requisition=0x11713ac20) at widget.cc:494 > #26 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf57d0) at > textblock_linebreaking.cc:1889 > #27 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf57d0, requisition=0x117119680) at textblock.cc:341 > #28 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf57d0, requisition=0x117119680) at widget.cc:494 > #29 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf5590) at > textblock_linebreaking.cc:1889 > #30 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf5590, requisition=0x116bf5d80) at textblock.cc:341 > #31 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf5590, requisition=0x116bf5d80) at widget.cc:494 > #32 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf3c80) at > textblock_linebreaking.cc:1889 > #33 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf3c80, requisition=0x100941240) at textblock.cc:341 > #34 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf3c80, requisition=0x100941240) at widget.cc:494 > #35 0x0000000100070199 in dw::Textblock::rewrap (this=0x102277cd0) at > textblock_linebreaking.cc:1889 > #36 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x102277cd0, requisition=0x1009435c0) at textblock.cc:341 > #37 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x102277cd0, requisition=0x1009435c0) at widget.cc:494 > #38 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d7f0) at > textblock_linebreaking.cc:1889 > #39 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1d7f0, requisition=0x116b1daa0) at textblock.cc:341 > #40 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1d7f0, requisition=0x116b1daa0) at widget.cc:494 > #41 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d060) at > textblock_linebreaking.cc:1889 > #42 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1d060, requisition=0x116b1d3c0) at textblock.cc:341 > #43 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1d060, requisition=0x116b1d3c0) at widget.cc:494 > #44 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1ca30) at > textblock_linebreaking.cc:1889 > #45 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1ca30, requisition=0x116b1cd80) at textblock.cc:341 > #46 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1ca30, requisition=0x116b1cd80) at widget.cc:494 > #47 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1c570) at > textblock_linebreaking.cc:1889 > #48 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1c570, requisition=0x117125040) at textblock.cc:341 > #49 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1c570, requisition=0x117125040) at widget.cc:494 > #50 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b9b0) at > textblock_linebreaking.cc:1889 > #51 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1b9b0, requisition=0x116b1c180) at textblock.cc:341 > #52 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1b9b0, requisition=0x116b1c180) at widget.cc:494 > #53 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b4f0) at > textblock_linebreaking.cc:1889 > #54 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1b4f0, requisition=0x116b1b6f4) at textblock.cc:341 > #55 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1b4f0, requisition=0x116b1b6f4) at widget.cc:494 > #56 0x0000000100058685 in dw::OutOfFlowMgr::ensureFloatSize > (this=0x1022478e0, vloat=0x116b1b6a0) at outofflowmgr.cc:2272 > #57 0x000000010005b067 in dw::OutOfFlowMgr::tellFloatPosition > (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1534 > #58 0x000000010005b1dc in dw::OutOfFlowMgr::tellPosition > (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1516 > #59 0x0000000100072aef in dw::Textblock::wrapWordInFlow > (this=0x116b1ad70, wordIndex=1, wrapAll=true) at > textblock_linebreaking.cc:788 > #60 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116b1ad70, > wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:606 > #61 0x000000010006fbb2 in dw::Textblock::showMissingLines > (this=0x116b1ad70) at textblock_linebreaking.cc:2113 > #62 0x000000010006b230 in dw::Textblock::sizeRequestImpl > (this=0x116b1ad70, requisition=0x10095b450) at textblock.cc:342 > #63 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1ad70, requisition=0x10095b450) at widget.cc:494 > #64 0x0000000100070199 in dw::Textblock::rewrap (this=0x10210cdf0) at > textblock_linebreaking.cc:1889 > #65 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x10210cdf0, requisition=0x1009597c0) at textblock.cc:341 > #66 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x10210cdf0, requisition=0x1009597c0) at widget.cc:494 > #67 0x0000000100070199 in dw::Textblock::rewrap (this=0x10054a2c0) at > textblock_linebreaking.cc:1889 > #68 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x10054a2c0, requisition=0x7fff5fbff040) at textblock.cc:341 > #69 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x10054a2c0, requisition=0x7fff5fbff040) at widget.cc:494 > #70 0x00000001000586cc in dw::OutOfFlowMgr::doFloatsExceedCB > (this=0x1022478e0, side=dw::OutOfFlowMgr::LEFT) at > outofflowmgr.cc:1045 > #71 0x000000010005b757 in dw::OutOfFlowMgr::sizeAllocateEnd > (this=0x1022478e0, caller=0x10054a2c0) at outofflowmgr.cc:651 > #72 0x000000010006ae82 in dw::Textblock::sizeAllocateImpl > (this=0x10054a2c0, allocation=0x7fff5fbff240) at textblock.cc:757 > #73 0x000000010009cfb2 in dw::core::Widget::sizeAllocate > (this=0x10054a2c0, allocation=0x7fff5fbff240) at widget.cc:993 > #74 0x000000010008e4ff in dw::core::Layout::resizeIdle > (this=0x105109370) at layout.cc:912 > #75 0x0000000100076d9e in dw::fltk::FltkPlatform::generalIdle > (this=0x1051091c0) at fltkplatform.cc:627 > #76 0x0000000100076def in dw::fltk::FltkPlatform::generalStaticIdle > (data=0x1051091c0) at fltkplatform.cc:617 > #77 0x00000001000ad21e in fl_mac_flush_and_wait (time_to_wait=1e+20) > at Fl_cocoa.mm:806 > #78 0x00000001000b0025 in Fl::run () at Fl.cxx:589 > #79 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at > dillo.cc:588 > (gdb) finish > Run till exit from #0 0x00000001000a09f9 in > lout::container::untyped::HashSet::calcHashValue (this=0x116b1bd90, > object=0x7fff5fbfdb80) at container.hh:242 > 0x000000010009eeb9 in lout::container::untyped::HashSet::findNode > (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.cc:497 > 497 int h = calcHashValue(object); > Value returned is $1 = 176 > (gdb) > Run till exit from #0 0x000000010009eeb9 in > lout::container::untyped::HashSet::findNode (this=0x116b1bd90, > object=0x7fff5fbfdb80) at container.cc:497 > 0x000000010009f2e3 in lout::container::untyped::HashTable::get > (this=0x116b1bd90, key=0x7fff5fbfdb80) at container.cc:704 > 704 Node *node = findNode(key); > Value returned is $2 = ('lout::container::untyped::HashSet::Node' *) > 0x116bf7500 > (gdb) > Run till exit from #0 0x000000010009f2e3 in > lout::container::untyped::HashTable::get (this=0x116b1bd90, > key=0x7fff5fbfdb80) at container.cc:704 > 0x000000010005d83c in > lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, > dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) > at container.hh:524 > 524 { return (V*)((untyped::HashTable*)this->base)->get(key); } > Value returned is $3 = ('lout::object::Object' *) 0x116bf73f0 > (gdb) > Run till exit from #0 0x000000010005d83c in > lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, > dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) > at container.hh:524 > 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock > (this=0x116b1bb60, textblock=0x116bf7270) at outofflowmgr.cc:1954 > 1954 TBInfo *tbInfo = tbInfosByTextblock->get (&key); > Value returned is $4 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116bf73f0 > (gdb) > Run till exit from #0 0x00000001000587fd in > dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, > textblock=0x116bf7270) at outofflowmgr.cc:1954 > 0x0000000100059ad5 in > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at > outofflowmgr.cc:291 > 291 TBInfo *t1 = oofm->getTextblock (f1->generatingBlock), > Value returned is $5 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116bf73f0 > (gdb) > Run till exit from #0 0x0000000100059ad5 in > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at > outofflowmgr.cc:291 > 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, > end=38, comparator=0x7fff5fbfdd80) at container.cc:239 > 239 int c = comparator->compare (key, array[index]); > Value returned is $6 = -4 > (gdb) > Run till exit from #0 0x000000010009eaf6 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, > comparator=0x7fff5fbfdd80) at container.cc:239 > 0x000000010005de36 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:159 > 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } > Value returned is $7 = 32 > (gdb) > Run till exit from #0 0x000000010005de36 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at > container.hh:159 > 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:456 > 456 comparator); } > Value returned is $8 = 32 > (gdb) > Run till exit from #0 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:456 > 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 340 int i = bsearch (&key, false, &comparator); > Value returned is $9 = 32 > (gdb) > Run till exit from #0 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst > (this=0x116b1bbd0, textblock=0x116bf7270, y=330882, h=1, > lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at > outofflowmgr.cc:424 > 424 int last = findFloatIndex (lastGB, lastExtIndex); > Value returned is $10 = 31 > (gdb) > Run till exit from #0 0x000000010005b986 in > dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, > textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, > lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 > 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, > textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=330882, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 > 2115 int first = list->findFirst (textblock, y, h, lastGB, > lastExtIndex, NULL); > Value returned is $11 = 29 > (gdb) > Run till exit from #0 0x000000010005bd1a in > dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, > side=dw::OutOfFlowMgr::LEFT, y=330882, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2115 > 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft > (this=0x116b1bb60, textblock=0x116bf7270, y=330882, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 > 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); > Value returned is $12 = true > (gdb) > Run till exit from #0 0x000000010005bdd0 in > dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, > textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2092 > 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, > lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 > 2045 effOofRef); > Value returned is $13 = true > (gdb) > Run till exit from #0 0x000000010006fdb2 in > dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) > at textblock_linebreaking.cc:2045 > dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, > wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, > tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, > thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, > diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, > lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, > breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 > 912 newLineHasFloatLeft || newLineHasFloatRight : false; > (gdb) > Run till exit from #0 dw::Textblock::balanceBreakPosAndHeight > (this=0x116bf7270, wordIndex=0, firstIndex=0, > searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, > borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, > wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, > lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, > breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 > dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, > wrapAll=false) at textblock_linebreaking.cc:749 > 749 int yNewLine = yOffsetOfLineToBeCreated (); > (gdb) > Run till exit from #0 dw::Textblock::wrapWordInFlow > (this=0x116bf7270, wordIndex=0, wrapAll=false) at > textblock_linebreaking.cc:749 > ^C > Program received signal SIGINT, Interrupt. > 0x000000010005d834 in > lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, > dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) > at container.hh:524 > 524 { return (V*)((untyped::HashTable*)this->base)->get(key); } > (gdb) finish > Run till exit from #0 0x000000010005d834 in > lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, > dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) > at container.hh:524 > 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock > (this=0x116b1bb60, textblock=0x116b1b9b0) at outofflowmgr.cc:1954 > 1954 TBInfo *tbInfo = tbInfosByTextblock->get (&key); > Value returned is $14 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116b1bf10 > (gdb) > Run till exit from #0 0x00000001000587fd in > dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, > textblock=0x116b1b9b0) at outofflowmgr.cc:1954 > 0x0000000100059aee in > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x117126ff0) at > outofflowmgr.cc:292 > 292 *t2 = oofm->getTextblock (f2->generatingBlock); > Value returned is $15 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116b1bf10 > (gdb) > Run till exit from #0 0x0000000100059aee in > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x117126ff0) at > outofflowmgr.cc:292 > 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, > end=38, comparator=0x7fff5fbfdd80) at container.cc:239 > 239 int c = comparator->compare (key, array[index]); > Value returned is $16 = -2 > (gdb) > Run till exit from #0 0x000000010009eaf6 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, > comparator=0x7fff5fbfdd80) at container.cc:239 > 0x000000010005de36 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:159 > 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } > Value returned is $17 = 32 > (gdb) > Run till exit from #0 0x000000010005de36 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at > container.hh:159 > 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:456 > 456 comparator); } > Value returned is $18 = 32 > (gdb) > Run till exit from #0 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, > comparator=0x7fff5fbfdd80) at container.hh:456 > 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 340 int i = bsearch (&key, false, &comparator); > Value returned is $19 = 32 > (gdb) > Run till exit from #0 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst > (this=0x116b1bbd0, textblock=0x116bf7270, y=616745, h=1, > lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at > outofflowmgr.cc:424 > 424 int last = findFloatIndex (lastGB, lastExtIndex); > Value returned is $20 = 31 > (gdb) > Run till exit from #0 0x000000010005b986 in > dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, > textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, > lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 > 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, > textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=616745, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 > 2115 int first = list->findFirst (textblock, y, h, lastGB, > lastExtIndex, NULL); > Value returned is $21 = 29 > (gdb) > Run till exit from #0 0x000000010005bd1a in > dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, > side=dw::OutOfFlowMgr::LEFT, y=616745, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2115 > 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft > (this=0x116b1bb60, textblock=0x116bf7270, y=616745, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 > 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); > Value returned is $22 = true > (gdb) > Run till exit from #0 0x000000010005bdd0 in > dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, > textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2092 > 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, > lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 > 2045 effOofRef); > Value returned is $23 = true > (gdb) > Run till exit from #0 0x000000010006fdb2 in > dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) > at textblock_linebreaking.cc:2045 > dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, > wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, > tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, > thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, > diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, > lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, > breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 > 912 newLineHasFloatLeft || newLineHasFloatRight : false; > (gdb) > Run till exit from #0 dw::Textblock::balanceBreakPosAndHeight > (this=0x116bf7270, wordIndex=0, firstIndex=0, > searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, > borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, > wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, > lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, > breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 > dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, > wrapAll=false) at textblock_linebreaking.cc:749 > 749 int yNewLine = yOffsetOfLineToBeCreated (); > (gdb) > Run till exit from #0 dw::Textblock::wrapWordInFlow > (this=0x116bf7270, wordIndex=0, wrapAll=false) at > textblock_linebreaking.cc:749 > ^C > Program received signal SIGINT, Interrupt. > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd30, o1=0x7fff5fbfdcc0, o2=0x116bcf1e0) at > outofflowmgr.cc:295 > 295 for (TBInfo *t = t1; t != NULL; t = t->parent) > (gdb) finish > Run till exit from #0 > dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare > (this=0x7fff5fbfdd30, o1=0x7fff5fbfdcc0, o2=0x116bcf1e0) at > outofflowmgr.cc:295 > 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, start=0, > end=38, comparator=0x7fff5fbfdd30) at container.cc:239 > 239 int c = comparator->compare (key, array[index]); > Value returned is $24 = 28 > (gdb) > Run till exit from #0 0x000000010009eaf6 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdcc0, mustExist=false, start=0, end=38, > comparator=0x7fff5fbfdd30) at container.cc:239 > 0x000000010005de36 in lout::container::untyped::Vector::bsearch > (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, > comparator=0x7fff5fbfdd30) at container.hh:159 > 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } > Value returned is $25 = 32 > (gdb) > Run till exit from #0 0x000000010005de36 in > lout::container::untyped::Vector::bsearch (this=0x116b1bc00, > key=0x7fff5fbfdcc0, mustExist=false, comparator=0x7fff5fbfdd30) at > container.hh:159 > 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdcc0, mustExist=false, > comparator=0x7fff5fbfdd30) at container.hh:456 > 456 comparator); } > Value returned is $26 = 32 > (gdb) > Run till exit from #0 0x000000010005de6b in > lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch > (this=0x116b1bbd0, key=0x7fff5fbfdcc0, mustExist=false, > comparator=0x7fff5fbfdd30) at container.hh:456 > 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 340 int i = bsearch (&key, false, &comparator); > Value returned is $27 = 32 > (gdb) > Run till exit from #0 0x000000010005b27f in > dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex > (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at > outofflowmgr.cc:340 > 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst > (this=0x116b1bbd0, textblock=0x116bf7270, y=948395, h=1, > lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at > outofflowmgr.cc:424 > 424 int last = findFloatIndex (lastGB, lastExtIndex); > Value returned is $28 = 31 > (gdb) > Run till exit from #0 0x000000010005b986 in > dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, > textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, > lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 > 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, > textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=948395, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 > 2115 int first = list->findFirst (textblock, y, h, lastGB, > lastExtIndex, NULL); > Value returned is $29 = 29 > (gdb) > Run till exit from #0 0x000000010005bd1a in > dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, > side=dw::OutOfFlowMgr::LEFT, y=948395, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2115 > 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft > (this=0x116b1bb60, textblock=0x116bf7270, y=948395, h=1, > lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 > 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); > Value returned is $30 = true > (gdb) > Run till exit from #0 0x000000010005bdd0 in > dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, > textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, > lastExtIndex=-1) at outofflowmgr.cc:2092 > 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, > lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 > 2045 effOofRef); > Value returned is $31 = true > (gdb) > Run till exit from #0 0x000000010006fdb2 in > dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) > at textblock_linebreaking.cc:2045 > dw::Textblock::initNewLine (this=0x116bf7270) at > textblock_linebreaking.cc:1990 > 1990 newLineAscent = newLineDescent = 0; > (gdb) > Run till exit from #0 dw::Textblock::initNewLine (this=0x116bf7270) > at textblock_linebreaking.cc:1990 > dw::Textblock::addLine (this=0x116bf7270, firstWord=0, lastWord=-1, > newLastOofPos=-1, temporary=false, minHeight=1) at > textblock_linebreaking.cc:523 > 523 return line; > (gdb) > Run till exit from #0 dw::Textblock::addLine (this=0x116bf7270, > firstWord=0, lastWord=-1, newLastOofPos=-1, temporary=false, > minHeight=1) at textblock_linebreaking.cc:523 > dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, > wrapAll=false) at textblock_linebreaking.cc:826 > 826 for(int i = breakPos + 1; i <= wordIndexEnd; i++) > Value returned is $32 = ('dw::Textblock::Line' *) 0x11ad3ca80 > (gdb) > Run till exit from #0 dw::Textblock::wrapWordInFlow > (this=0x116bf7270, wordIndex=0, wrapAll=false) at > textblock_linebreaking.cc:826 > 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116bf7270, > wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 > 606 n = wrapWordInFlow (wordIndex, wrapAll); > Value returned is $33 = 0 > (gdb) > Run till exit from #0 0x0000000100072e23 in dw::Textblock::wordWrap > (this=0x116bf7270, wordIndex=0, wrapAll=false) at > textblock_linebreaking.cc:606 > dw::Textblock::rewrap (this=0x116bf7270) at textblock_linebreaking.cc:1885 > 1885 for (int i = firstWord; i < words->size (); i++) { > Value returned is $34 = 0 > (gdb) > Run till exit from #0 dw::Textblock::rewrap (this=0x116bf7270) at > textblock_linebreaking.cc:1885 > dw::Textblock::sizeRequestImpl (this=0x116bf7270, > requisition=0x116bf7600) at textblock.cc:342 > 342 showMissingLines (); > (gdb) > Run till exit from #0 dw::Textblock::sizeRequestImpl > (this=0x116bf7270, requisition=0x116bf7600) at textblock.cc:342 > dw::core::Widget::sizeRequest (this=0x116bf7270, > requisition=0x116bf7600) at widget.cc:495 > 495 this->requisition = *requisition; > (gdb) > Run till exit from #0 dw::core::Widget::sizeRequest > (this=0x116bf7270, requisition=0x116bf7600) at widget.cc:495 > dw::Textblock::rewrap (this=0x116bf6ce0) at textblock_linebreaking.cc:1891 > 1891 wordWrap (i, false); > (gdb) > Run till exit from #0 dw::Textblock::rewrap (this=0x116bf6ce0) at > textblock_linebreaking.cc:1891 > dw::Textblock::sizeRequestImpl (this=0x116bf6ce0, > requisition=0x116bf8ac0) at textblock.cc:342 > 342 showMissingLines (); > (gdb) > Run till exit from #0 dw::Textblock::sizeRequestImpl > (this=0x116bf6ce0, requisition=0x116bf8ac0) at textblock.cc:342 > dw::core::Widget::sizeRequest (this=0x116bf6ce0, > requisition=0x116bf8ac0) at widget.cc:495 > 495 this->requisition = *requisition; > (gdb) > Run till exit from #0 dw::core::Widget::sizeRequest > (this=0x116bf6ce0, requisition=0x116bf8ac0) at widget.cc:495 > dw::Textblock::rewrap (this=0x116bf67c0) at textblock_linebreaking.cc:1891 > 1891 wordWrap (i, false); > (gdb) > Run till exit from #0 dw::Textblock::rewrap (this=0x116bf67c0) at > textblock_linebreaking.cc:1891 > dw::Textblock::sizeRequestImpl (this=0x116bf67c0, > requisition=0x11713ac20) at textblock.cc:342 > 342 showMissingLines (); > (gdb) > Run till exit from #0 dw::Textblock::sizeRequestImpl > (this=0x116bf67c0, requisition=0x11713ac20) at textblock.cc:342 > dw::core::Widget::sizeRequest (this=0x116bf67c0, > requisition=0x11713ac20) at widget.cc:495 > 495 this->requisition = *requisition; > (gdb) > Run till exit from #0 dw::core::Widget::sizeRequest > (this=0x116bf67c0, requisition=0x11713ac20) at widget.cc:495 > dw::Textblock::rewrap (this=0x116bf57d0) at textblock_linebreaking.cc:1891 > 1891 wordWrap (i, false); > (gdb) > Run till exit from #0 dw::Textblock::rewrap (this=0x116bf57d0) at > textblock_linebreaking.cc:1891 > dw::Textblock::sizeRequestImpl (this=0x116bf57d0, > requisition=0x117119680) at textblock.cc:342 > 342 showMissingLines (); > (gdb) > Run till exit from #0 dw::Textblock::sizeRequestImpl > (this=0x116bf57d0, requisition=0x117119680) at textblock.cc:342 > dw::core::Widget::sizeRequest (this=0x116bf57d0, > requisition=0x117119680) at widget.cc:495 > 495 this->requisition = *requisition; > (gdb) > Run till exit from #0 dw::core::Widget::sizeRequest > (this=0x116bf57d0, requisition=0x117119680) at widget.cc:495 > dw::Textblock::rewrap (this=0x116bf5590) at textblock_linebreaking.cc:1891 > 1891 wordWrap (i, false); > (gdb) > Run till exit from #0 dw::Textblock::rewrap (this=0x116bf5590) at > textblock_linebreaking.cc:1891 > dw::Textblock::sizeRequestImpl (this=0x116bf5590, > requisition=0x116bf5d80) at textblock.cc:342 > 342 showMissingLines (); > (gdb) bt > #0 dw::Textblock::sizeRequestImpl (this=0x116bf5590, > requisition=0x116bf5d80) at textblock.cc:342 > #1 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf5590, requisition=0x116bf5d80) at widget.cc:494 > #2 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf3c80) at > textblock_linebreaking.cc:1889 > #3 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116bf3c80, requisition=0x100941240) at textblock.cc:341 > #4 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116bf3c80, requisition=0x100941240) at widget.cc:494 > #5 0x0000000100070199 in dw::Textblock::rewrap (this=0x102277cd0) at > textblock_linebreaking.cc:1889 > #6 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x102277cd0, requisition=0x1009435c0) at textblock.cc:341 > #7 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x102277cd0, requisition=0x1009435c0) at widget.cc:494 > #8 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d7f0) at > textblock_linebreaking.cc:1889 > #9 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1d7f0, requisition=0x116b1daa0) at textblock.cc:341 > #10 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1d7f0, requisition=0x116b1daa0) at widget.cc:494 > #11 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d060) at > textblock_linebreaking.cc:1889 > #12 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1d060, requisition=0x116b1d3c0) at textblock.cc:341 > #13 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1d060, requisition=0x116b1d3c0) at widget.cc:494 > #14 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1ca30) at > textblock_linebreaking.cc:1889 > #15 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1ca30, requisition=0x116b1cd80) at textblock.cc:341 > #16 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1ca30, requisition=0x116b1cd80) at widget.cc:494 > #17 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1c570) at > textblock_linebreaking.cc:1889 > #18 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1c570, requisition=0x117125040) at textblock.cc:341 > #19 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1c570, requisition=0x117125040) at widget.cc:494 > #20 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b9b0) at > textblock_linebreaking.cc:1889 > #21 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1b9b0, requisition=0x116b1c180) at textblock.cc:341 > #22 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1b9b0, requisition=0x116b1c180) at widget.cc:494 > #23 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b4f0) at > textblock_linebreaking.cc:1889 > #24 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x116b1b4f0, requisition=0x116b1b6f4) at textblock.cc:341 > #25 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1b4f0, requisition=0x116b1b6f4) at widget.cc:494 > #26 0x0000000100058685 in dw::OutOfFlowMgr::ensureFloatSize > (this=0x1022478e0, vloat=0x116b1b6a0) at outofflowmgr.cc:2272 > #27 0x000000010005b067 in dw::OutOfFlowMgr::tellFloatPosition > (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1534 > #28 0x000000010005b1dc in dw::OutOfFlowMgr::tellPosition > (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1516 > #29 0x0000000100072aef in dw::Textblock::wrapWordInFlow > (this=0x116b1ad70, wordIndex=1, wrapAll=true) at > textblock_linebreaking.cc:788 > #30 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116b1ad70, > wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:606 > #31 0x000000010006fbb2 in dw::Textblock::showMissingLines > (this=0x116b1ad70) at textblock_linebreaking.cc:2113 > #32 0x000000010006b230 in dw::Textblock::sizeRequestImpl > (this=0x116b1ad70, requisition=0x10095b450) at textblock.cc:342 > #33 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x116b1ad70, requisition=0x10095b450) at widget.cc:494 > #34 0x0000000100070199 in dw::Textblock::rewrap (this=0x10210cdf0) at > textblock_linebreaking.cc:1889 > #35 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x10210cdf0, requisition=0x1009597c0) at textblock.cc:341 > #36 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x10210cdf0, requisition=0x1009597c0) at widget.cc:494 > #37 0x0000000100070199 in dw::Textblock::rewrap (this=0x10054a2c0) at > textblock_linebreaking.cc:1889 > #38 0x000000010006b227 in dw::Textblock::sizeRequestImpl > (this=0x10054a2c0, requisition=0x7fff5fbff040) at textblock.cc:341 > #39 0x000000010009c7a7 in dw::core::Widget::sizeRequest > (this=0x10054a2c0, requisition=0x7fff5fbff040) at widget.cc:494 > #40 0x00000001000586cc in dw::OutOfFlowMgr::doFloatsExceedCB > (this=0x1022478e0, side=dw::OutOfFlowMgr::LEFT) at > outofflowmgr.cc:1045 > #41 0x000000010005b757 in dw::OutOfFlowMgr::sizeAllocateEnd > (this=0x1022478e0, caller=0x10054a2c0) at outofflowmgr.cc:651 > #42 0x000000010006ae82 in dw::Textblock::sizeAllocateImpl > (this=0x10054a2c0, allocation=0x7fff5fbff240) at textblock.cc:757 > #43 0x000000010009cfb2 in dw::core::Widget::sizeAllocate > (this=0x10054a2c0, allocation=0x7fff5fbff240) at widget.cc:993 > #44 0x000000010008e4ff in dw::core::Layout::resizeIdle > (this=0x105109370) at layout.cc:912 > #45 0x0000000100076d9e in dw::fltk::FltkPlatform::generalIdle > (this=0x1051091c0) at fltkplatform.cc:627 > #46 0x0000000100076def in dw::fltk::FltkPlatform::generalStaticIdle > (data=0x1051091c0) at fltkplatform.cc:617 > #47 0x00000001000ad21e in fl_mac_flush_and_wait (time_to_wait=1e+20) > at Fl_cocoa.mm:806 > #48 0x00000001000b0025 in Fl::run () at Fl.cxx:589 > #49 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at > dillo.cc:588 > (gdb) > > > On 1/21/15, Jorge Arellano Cid <jcid at dillo.org> wrote: >> Hi there, >> >> Trying to read about this laptop on slashdot dillo >> locks with 100% CPU and increasing memory footprint. :-P >> >> >> [1] >> http://hardware.slashdot.org/story/15/01/20/1655242/librem-a-laptop-custom-… >> >> -- >> Cheers >> Jorge.- >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

July 31, 2015

different profiles for different sites

by dillo-dev＠toykeeper.net

Hi, I just wanted to share a simple idea I've found useful. Basically, I have two hotkeys to run dillo with different profiles using a trivial wrapper script: #!/bin/sh FLAVOR=$1 ; shift cd $HOME/.dillo cp dillorc.$FLAVOR dillorc dillo "$@" This way, I can have different user-agents per profile, to allow me to get different behaviors. If I want to use google images or get search results on the first page, I ask Dillo to pretend it's Lynx: http_user_agent="Lynx/2.8.8dev.3 libwww-FM/2.14 SSL-MM/1.4.1" Or if I want to do google searches like "5 meters in feet" or "local weather" or "pizza near me", I ask Dillo to pretend it's an old version of Firefox: http_user_agent="Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6" Many sites are picky about the user-agent and won't work right with my usual config, but this way I can get them all to function as desired. :) -- Selene

July 29, 2015

Weirdly scaled images (again)

by fusionfile＠gmail.com

The Dillo user v4hn recently sent a message to this list regarding incorrect image scaling. She or he expresses exactly what I have on my mind: http://lists.dillo.org/pipermail/dillo-dev/2015-July/010596.html I use Dillo 3.0.4 from the Debian stable repositories and I experience the ugly image scaling on many sites, for instance on the two largest news (paper) sites here in Sweden: http://www.dn.se http://www.svd.se I can imagine that most people trying out Dillo will find the stretched-out images very off-putting. Changing the aspect ratio of an image is something you almost never want do do, and changing the aspect ratio of a photo is a big no-no. What's your view on this? Do you use Dillo with CSS disabled? Actually, I think it would be better if image scaling was not implemented at all, rather than broken like this. I'm not familiar with the Dillo code base but I'm a programmer proficient with C and I know some C++, so if I (with some hints) can help I would be more than glad to. Regards, August

July 28, 2015

[DNG] Will there be a MirDevuan "WTF"?

by miro.rovis＠croatiafidelis.hr

--- I sent this message three hours ago, but didn't include the list address. Sorry! --- On Wed, Jul 22, 2015 at 10:49:34PM -0700, James Powell wrote: ( shouldn't it be like below?, by the netiqette --see KalolaZ just arrived letter in the Multi-seat thread-- ? ) > > Since you would still like it around, in opportunistic or in some other > > way that I should call it, I think a question is due. > > Can you tell to the public what is the purpose of the > > user-not-asked-about, in fact mostly user-never-even-knowing-about-it > > encrypted ssh channel that dbus sets up, along with all the > > non-GNU-compatible remote procedure calls (which are there for what > > purpose?) that dbus implements? > > > > Is that for FOSS stands for? > > > First off cool your jets, and trying call me out on knowing the > internals of an IPC in Userspace I didn't develop is very childish. > Why not? If you're promoting it, or persuading Devuan into the acceptance of it? Anyway, can anyone answer that question? > I honestly don't care if D-Bus what it does other than be a > communication and messaging relay between applications and processes, > as long as it does what it does, and doesn't infringe on anything > else. > > D-Bus is used and is a requirement for some services and software. > You're unfortunately not going to have your cake and coffee with > getting rid of D-Bus. Well then, keep it for those cases, don't put it in all the Devuan boxen by default. Will be fine! > Yes, it's not the greatest design, but it is > friendly at least to the whole UNIX spectrum. > "friendly"... No comment. > Devuan's main purpose is getting rid of systemd as a hard dependency > and allowing user choice in init software, not ripping apart every > project to cater to ever niche and fundamentalist out there preaching > what they feel is FOSS, and also to not start a witch hunt on software > projects. What fundamentalists? The Gentoo folks? Thorsten mirabilos Glaser with his MirDebian "WTF" project, a fundamentalist? Me, a fundamentalist? What do you mean? My desire to, after have achived it for me (but only in Gentoo), some freedom and some security, to teach, if we get a true-foss Devuan that can get its MirDevuan "WTF" fork for itself, to teach newbies to build their system hardened-against-intrusion and surveillance-defeating, that desire of mine a fundamentalist desire? --- The rest cut out because somewhat made disorderly and illegible by probably hotmail defaults (that the immediate sender who I'm replying to apparently uses) or for some other reason. --- Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 23, 2015

Gentoo live ebuild, WAS: Github..cookies

by miro.rovis＠croatiafidelis.hr

On Sat, Jul 18, 2015 at 01:04:55PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > Dillo ebuild is missing xft flag for fltk, causes eye-sore renamed: www-client/dillo should depend on x11-libs/fltk[xft] > > https://bugs.gentoo.org/show_bug.cgi?id=554588 There is more comments, by Walter Dnes, and by me. I saw the mail wasn't reported sent to Walter Dnes, so I thought I'd inform here. Thanks! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 19, 2015

Gentoo live ebuild, WAS: Github..cookies

by miroslav.rovis1＠zg.ht.hr

On Mon, Jul 13, 2015 at 02:26:55PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > Dillo ebuild is missing xft flag for fltk, causes eye-sore > https://bugs.gentoo.org/show_bug.cgi?id=554588 > I hope you'll find it interesting that that bug is now marked: RESOLVED WONTFIX https://bugs.gentoo.org/show_bug.cgi?id=554588#c2 "What if you want dillo, but not libXft or everything else it pulls in?" (Jeroen Roovers) -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 18, 2015

no text wrapping on Gentoo Bugzilla

by miroslav.rovis1＠zg.ht.hr

On Fri, Jul 17, 2015 at 09:57:31PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > On Fri, Jul 17, 2015 at 02:22:15PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > toggle header weeding in Mutt doesn't work > > https://bugs.gentoo.org/show_bug.cgi?id=555180 > > > > That was a dillo-3.1-dev issue. > After masking it in my portage, I emerged dillo-3.0.5, and as you can > see in the bug, posting is possible (mostly): > ( link same as already given above ) > https://bugs.gentoo.org/show_bug.cgi?id=555180 Nope! Have a look: https://bugs.gentoo.org/show_bug.cgi?id=555180#c8 (and that was with 3.0.5) > > -- > Miroslav Rovis > Zagreb, Croatia > http://www.CroatiaFidelis.hr > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 18, 2015

no text wrapping on Gentoo Bugzilla

by miroslav.rovis1＠zg.ht.hr

On Fri, Jul 17, 2015 at 02:22:15PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > It just happened, minutes ago. > > Easily seen in its effects: > > toggle header weeding in Mutt doesn't work > https://bugs.gentoo.org/show_bug.cgi?id=555180 > > (notice that also emerg --info that I attached has, instead of > spaces, the Α displayed, such as: > > https://555180.bugs.gentoo.org/attachment.cgi?id=406994 > 2.6-r1::gentoosys-devel/autoconf: ... > ) > > However, as I immediately after posted on: > > Mutt without Portage/in Local Overlay > https://forums.gentoo.org/viewtopic-t-1002146-start-50.html#7781834 > where the exactly same text can be perfectly readable as it is > wrapped just fine, and which I explain in the immediately > following post in the same topic: > https://forums.gentoo.org/viewtopic-t-1002146-start-50.html#7781838 > > Could that Dillo's fault? > > The whole session of what happened online from my going online, to > logging into Bugzilla, the entire posting, end the surprising look > at what the post came out like, all is in these: > > 6d8bc1e8d0868d6864d4beb8678e13a533e813cc6f2a26ff1a14cb7cced1aec5 > dump_150717_1211_g0n.pcap > dc465d190560a5b7a058a2d1f996d43ef68e032fb66e4be1b265a5bfdab95630 > Screen_150717_1211_g0n.mkv > > (the traffic dump and the screencast) > > just in case we would need to analyze what happened. > > The Dillo is the same one, like I built it back when I wrote my: > > A Tentative at dillo-3.1-dev ebuild > https://forums.gentoo.org/viewtopic-t-1021878.html > (haven't updated it since) > That was a dillo-3.1-dev issue. After masking it in my portage, I emerged dillo-3.0.5, and as you can see in the bug, posting is possible (mostly): ( link same as already given above ) https://bugs.gentoo.org/show_bug.cgi?id=555180 Cheers! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 17, 2015

no text wrapping on Gentoo Bugzilla

by miroslav.rovis1＠zg.ht.hr

It just happened, minutes ago. Easily seen in its effects: toggle header weeding in Mutt doesn't work https://bugs.gentoo.org/show_bug.cgi?id=555180 (notice that also emerg --info that I attached has, instead of spaces, the Α displayed, such as: https://555180.bugs.gentoo.org/attachment.cgi?id=406994 2.6-r1::gentoosys-devel/autoconf: ... ) However, as I immediately after posted on: Mutt without Portage/in Local Overlay https://forums.gentoo.org/viewtopic-t-1002146-start-50.html#7781834 where the exactly same text can be perfectly readable as it is wrapped just fine, and which I explain in the immediately following post in the same topic: https://forums.gentoo.org/viewtopic-t-1002146-start-50.html#7781838 Could that Dillo's fault? The whole session of what happened online from my going online, to logging into Bugzilla, the entire posting, end the surprising look at what the post came out like, all is in these: 6d8bc1e8d0868d6864d4beb8678e13a533e813cc6f2a26ff1a14cb7cced1aec5 dump_150717_1211_g0n.pcap dc465d190560a5b7a058a2d1f996d43ef68e032fb66e4be1b265a5bfdab95630 Screen_150717_1211_g0n.mkv (the traffic dump and the screencast) just in case we would need to analyze what happened. The Dillo is the same one, like I built it back when I wrote my: A Tentative at dillo-3.1-dev ebuild https://forums.gentoo.org/viewtopic-t-1021878.html (haven't updated it since) Regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 17, 2015

Dillo 3.0.5 released

by eocene＠gmx.com

Jeremy wrote: > Are there any new config files that should be described? Nope.

July 14, 2015

Dillo 3.0.5 released

by onepoint＠starurchin.org

eocene wrote: > > All right, release is official... Linux From Scratch project wiki page updated: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 Are there any new config files that should be described? Regards, Jeremy Henty

July 14, 2015

Gentoo live ebuild, WAS: Github..cookies

by miroslav.rovis1＠zg.ht.hr

On Wed, Jul 08, 2015 at 10:34:24AM -0400, Walter Dnes wrote: > > > And on Gentoo, it's the local overlay way for me to go. Studying to be > > able to accomplish that. > > I'm also a Gentoo user; not even a C programmer, let alone a > developer. I'd be interested in your ebuild. A Tentative at dillo-3.1-dev ebuild https://forums.gentoo.org/viewtopic-t-1021878.html And, Walter, I hope you noticed I gave you credit for my figuring out the bug in the current version at: Dillo ebuild is missing xft flag for fltk, causes eye-sore https://bugs.gentoo.org/show_bug.cgi?id=554588 Cheers! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 13, 2015

Fonts not found issue persists in 3.0.5

by miroslav.rovis1＠zg.ht.hr

On Sat, Jul 11, 2015 at 05:29:20PM -0300, Jorge Arellano Cid wrote: > On Thu, Jul 09, 2015 at 10:19:11PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > See this issue below? > > > > On Tue, Jul 07, 2015 at 09:29:18AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > > I got the new Dillo version 3.0.5 (in the master air-gapped box, which I > > > yet have to clone onto this, for online, same hardware box), as it is > > > available in gentoo: > > > > > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/dillo/ > > > > > > but my problem with fonts (the FAQ issue > > > http://www.dillo.org/FAQ.html#q27) to which eocene has kindly given the > > > tip for in his message: > > > > > > http://lists.dillo.org/pipermail/dillo-dev/2015-April/010500.html > > > > > > > And we thought: > > > For people reading this message offline, I'll paste his advice, since it is > > > also important: > > > > > > If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), > > > remove the leading underscore in > > > _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > > > to get > > > MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > > > and recompile, what does dillo say when you run it? > > > > > > > But we were wrong! And it was only something an unimaginative person > > like me can be capable of not figuring out despite urgent need and > > sincere desire because of that urgent need (my eyes have been hurting > > from the fixed not-much-more-than ASCII font that was all I've seen in, > > what?, a few months? > > > > We were wrong! It only needed that the fltk be recompiled with, guess > > what?, with the the XFT font renederer! > > > > That was the sole missing thing. > > I'm glad you finally nailed the issue, and have proper fonts. > > > > But I think I am going to file a bug on Gentoo Bugzilla about this! > > (But if anybody can tell a reason that justifies the xft use flag not > > being the default, pls. do tell me... in which case my filing the bug > > would not make sense; I don't see such reason though.) > > I neither see a reason for this... > > -- > Cheers > Jorge.- Thanx, boss! I think I found what was missing in the Gentoo ebuild, and I may have reported correctly on the Bugzilla: Dillo ebuild is missing xft flag for fltk, causes eye-sore https://bugs.gentoo.org/show_bug.cgi?id=554588 I tried to give credit where it was due, and you can find Walter Dnes name in the bug report above ;-) . Because this triggered my understanding,[...] > On Wed, Jul 08, 2015 at 10:34:24AM -0400, Walter Dnes wrote: ... > > You also have to have x11-libs/fltk on > > your system. For fltk, the "xft" USE flag is strongly recommended. I > > wonder if the "opengl" and "threads" USE flags would help fltk+dillo. [...]and the snippet of the dawning conversation can be found on: http://lists.dillo.org/pipermail/dillo-dev/2015-July/010594.html Cheers! On another note, still wrecking my nerves: it's a real torture accessing and posting bugs.gentoo.org with my current setup or with the something missing in dillo. It sure will take me time to really figure and deploy on my Gentoo the ebuilds in my local overlay with the current mercurial code (slowly making progress there too), so only then I'll know if the issue has been fixed in it... Just, in case anyone could see any reasons for the thousands per minute cookies.dpi lines as described in my Grsecurity Forums Dillo topic: Deploy RBAC on Dillo browser https://forums.grsecurity.net/viewtopic.php?f=5&t=4228 where my current policy for Dillo is at: https://forums.grsecurity.net/viewtopic.php?f=5&t=4228#p15372 Cheers! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 12, 2015

Fonts not found issue persists in 3.0.5

by jcid＠dillo.org

On Thu, Jul 09, 2015 at 10:19:11PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > See this issue below? > > On Tue, Jul 07, 2015 at 09:29:18AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > I got the new Dillo version 3.0.5 (in the master air-gapped box, which I > > yet have to clone onto this, for online, same hardware box), as it is > > available in gentoo: > > > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/dillo/ > > > > but my problem with fonts (the FAQ issue > > http://www.dillo.org/FAQ.html#q27) to which eocene has kindly given the > > tip for in his message: > > > > http://lists.dillo.org/pipermail/dillo-dev/2015-April/010500.html > > > > And we thought: > > For people reading this message offline, I'll paste his advice, since it is > > also important: > > > > If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), > > remove the leading underscore in > > _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > > to get > > MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > > and recompile, what does dillo say when you run it? > > > > But we were wrong! And it was only something an unimaginative person > like me can be capable of not figuring out despite urgent need and > sincere desire because of that urgent need (my eyes have been hurting > from the fixed not-much-more-than ASCII font that was all I've seen in, > what?, a few months? > > We were wrong! It only needed that the fltk be recompiled with, guess > what?, with the the XFT font renederer! > > That was the sole missing thing. I'm glad you finally nailed the issue, and have proper fonts. > But I think I am going to file a bug on Gentoo Bugzilla about this! > (But if anybody can tell a reason that justifies the xft use flag not > being the default, pls. do tell me... in which case my filing the bug > would not make sense; I don't see such reason though.) I neither see a reason for this... -- Cheers Jorge.-

July 11, 2015

weirdly scaled images

by miroslav.rovis1＠zg.ht.hr

On Fri, Jul 10, 2015 at 12:55:33AM +0200, v4hn wrote: > Hey everyone, > > thanks for the great project. :-) > It is awesome to have a graphical browser at ones hand > that starts up in less than a second > and still supports most of the stuff I need. > > Now, for quite some time I've been using dillo to read news > on http://www.heise.de and it has always annoyed me > that some of the images on the main page are weirdly scaled. > Because these images are of size 160x90 but are scaled to > what feels like 98% of the window's width, they are barely recognizable > and distracting. > Right: The images on: http://www.heise.de are not scaled as they should be, and there is probably a lot of layout missing. I don't even want to fire up Firefox or some other big browser to look it (I so much hate their harvesting of data) up, but it's so probably the case... > Now with the new release out which still shows this behaviour, > I thought I'd ask whether someone's got an idea what the problem > might be in this case. Because I'm not at all familiar with the dillo > source code and/or the resp. web standards I didn't dare to debug > this myself up to now. > > Would be absolutely awesome if someone could have a look at it, > > > v4hn (Not a dev myself, just a very keen supporter.) But I'm almost certain, that is a CSS issue. If you look at the Dillo homepage, and search for CSS, and opne the link: http://www.dillo.org/CSS.html there is more about it. Even some big browsers (forgot really exactly which one; was it Opera?, as I had read about it a few months ago, and the big count on the fingers on one hand only, hardly more, in the world) had stumbled a little on the implementation of CSS. Go look CSS3 standard on the w3.org: http://www.w3.org/Style/CSS/current-work and especially, Lord, there's the Level 4 now coming: CSS Cascading and Inheritance Level?4 http://www.w3.org/TR/2015/WD-css-cascade-4-20150421/ That must be an awful lot of work for developers to _implement_! (I had better go quiet for a while, I've been a little too talkative in the past week... ;-) ) Cheers! P.S. I can't help elaborating a little. The dev power of the big (see above) grows on their servise to surveillance subjects (see the harvesting mentioned above... the STASI's of the world... the tax payers moneys secretly flowing...). Dillo is the strongest among the honest browsers that don't lie to users. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 10, 2015

weirdly scaled images

by me＠v4hn.de

Hey everyone, thanks for the great project. :-) It is awesome to have a graphical browser at ones hand that starts up in less than a second and still supports most of the stuff I need. Now, for quite some time I've been using dillo to read news on http://www.heise.de and it has always annoyed me that some of the images on the main page are weirdly scaled. Because these images are of size 160x90 but are scaled to what feels like 98% of the window's width, they are barely recognizable and distracting. Now with the new release out which still shows this behaviour, I thought I'd ask whether someone's got an idea what the problem might be in this case. Because I'm not at all familiar with the dillo source code and/or the resp. web standards I didn't dare to debug this myself up to now. Would be absolutely awesome if someone could have a look at it, v4hn

July 9, 2015

Fonts not found issue persists in 3.0.5

by miroslav.rovis1＠zg.ht.hr

See this issue below? On Tue, Jul 07, 2015 at 09:29:18AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > I got the new Dillo version 3.0.5 (in the master air-gapped box, which I > yet have to clone onto this, for online, same hardware box), as it is > available in gentoo: > > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/dillo/ > > but my problem with fonts (the FAQ issue > http://www.dillo.org/FAQ.html#q27) to which eocene has kindly given the > tip for in his message: > > http://lists.dillo.org/pipermail/dillo-dev/2015-April/010500.html > And we thought: > For people reading this message offline, I'll paste his advice, since it is > also important: > > If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), > remove the leading underscore in > _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > to get > MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", > and recompile, what does dillo say when you run it? > But we were wrong! And it was only something an unimaginative person like me can be capable of not figuring out despite urgent need and sincere desire because of that urgent need (my eyes have been hurting from the fixed not-much-more-than ASCII font that was all I've seen in, what?, a few months? We were wrong! It only needed that the fltk be recompiled with, guess what?, with the the XFT font renederer! That was the sole missing thing. So, on my Gentoo, it's probably sufficient to simply, # cat >> /etc/portage/package.use x11-libs/fltk xft # [[ --> But I preferred: # cat >> /etc/portage/package.use x11-libs/fltk opengl doc examples xft www-client/dillo gif ipv6 jpeg png ssl doc --> ]] and: # emerge -tuvDN dillo which then first renstalls fltk, and then reinstalls dillo, and I get the fonts which I set in the ~/.dillo/dillorc, and, esp. they are scalable to my heart's content! > And I was saying that that problem I still have in my 3.0.5. > > I hoped it would have been solved, but since it hasn't been, for me who > am not really a developer, to go and recompile means first get (finally, > it's been waiting for me since long) a little really deeper and dirty > with the Gentoo ebuild system, and, basically compile my own ebuild... > or... I'll be going the ebuild way just the same, because I want to be able to get to know this really lean and mean browser. Too many things still missing... I can't wait to see CSS3 implemented, and those floats and all! (No, not impatient in a nervous way, it's a delightful expectation for me.) > > Or get Gentoo developers to do it for all of the Dillo Gentoo users. > I think I am going to file a very angry (no, not really, our devs are overwrought and as unimaginative, many of them, as I am)... But I think I am going to file a bug on Gentoo Bugzilla about this! (But if anybody can tell a reason that justifies the xft use flag not being the default, pls. do tell me... in which case my filing the bug would not make sense; I don't see such reason though.) Very kind regards! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 9, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

Hi Walter! On Wed, Jul 08, 2015 at 10:34:24AM -0400, Walter Dnes wrote: > > > And on Gentoo, it's the local overlay way for me to go. Studying to be > > able to accomplish that. > > I'm also a Gentoo user; not even a C programmer, let alone a > developer. I'd be interested in your ebuild. See in bottom in regard to that. > For the devel version, I > build it locally in my home directory. You need to include > "$HOME/.local/bin" in your PATH. (Correct me if I misunderstand something here, pls.) No, I really want to go the ebuild way, I'm studying, go and download it, it's just: wget -r https://devmanual.gentoo.org and, I'm studying, haven't browsed all that I downloaded yet (this time around, I was there online or offline a couple of times in some two years without finalizing my learning of it)... ...and all is there, the entire devmanual, I believe, for hours upon hours of study. > You also have to have x11-libs/fltk on > your system. For fltk, the "xft" USE flag is strongly recommended. I > wonder if the "opengl" and "threads" USE flags would help fltk+dillo. Wow! Noone told about that in no tips, and it's not the default. Could in here below lie some of the reason why my fonts are not found? (just, I have --ask in my /etc/portage/make.conf): # emerge flt These are the packages that would be merged, in order: Calculating dependencies ... done! [ebuild R ] x11-libs/fltk-1.3.3-r3:1::gentoo USE="opengl -cairo -debug -doc -examples -games -pdf -static-libs -threads -xft -xinerama" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] So you information is valuable to me! > I > have a script file ~/dillo/dbuild > > #!/bin/bash > #hg clone http://hg.dillo.org/dillo dillo3 > cd ${HOME}/dillo/dillo3 > CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables-fno-asynchronous-unwind-tables" > CXXFLAGS=${CFLAGS} > make clean > hg pull > hg update > ./autogen.sh > ./configure \ > --prefix=${HOME}/.local \ > --enable-ssl \ > --disable-ipv6 \ > --enable-cookies \ > --enable-png \ > --enable-jpeg \ > --enable-gif \ > --enable-threaded-dns \ > --enable-dependency-tracking \ > 2> ../build_err.txt > make > make install-strip > > The first time only, I uncoment the "hg clone" command. > > -- > Walter Dnes <waltdnes at waltdnes.org> I see. But, no, I really want to go the ebuild way this time around! I'll give it a few dozen hours dedicated work if necessary, I hope I make it. And for the ebuild and all of what I may learn in the process, you don't need to worry, I'm pretty talkative, and I often don't even hide what I should, for the desire to spread the use of good programs like Dillo. I hope I'll be figuring things about the overlay and the ebuild writing (the: /usr/portage/www-client/dillo/dillo-3.0.5.ebuild is probably what I will start from, copy it in my overlay (already created), and modify it to use the source (for which I'll ask your or any other Gentooers' help if I stumble on how to use it; I think the source has to be a snapshot, not a mercurial SCM source, and I know how to get git archives with cgit on apache, but not yet mercurial... will study that too)... And... And whatever comes my way... till I get it done. Surely I'll try and open a Gentoo Forums topic for this, to get help, and so that we can provide for others what we will have hopefully done... And surely I'll inform about that new topic on Gentoo Forums in this mailing list. --- ### --- As far as the the issue of cookies and those 1000/min lines, described in the Grsecurity Forums, linked already from this topic, there is also more that I plan on that issue too: Deploy RBAC on Dillo browser http://forums.grsecurity.net/viewtopic.php?f=5&t=4228&p=15358#p15358 About which I was wondering: did, as I wrote, the Dillo devs read what spender wrote: ( same Grsecurity Forums topic ) https://forums.grsecurity.net/viewtopic.php?f=5&t=4228#p15352 (and which I can't understand at this time, and maybe never will) -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 9, 2015

Github et alia login/cookies issue

by waltdnes＠waltdnes.org

> And on Gentoo, it's the local overlay way for me to go. Studying to be > able to accomplish that. I'm also a Gentoo user; not even a C programmer, let alone a developer. I'd be interested in your ebuild. For the devel version, I build it locally in my home directory. You need to include "$HOME/.local/bin" in your PATH. You also have to have x11-libs/fltk on your system. For fltk, the "xft" USE flag is strongly recommended. I wonder if the "opengl" and "threads" USE flags would help fltk+dillo. I have a script file ~/dillo/dbuild #!/bin/bash #hg clone http://hg.dillo.org/dillo dillo3 cd ${HOME}/dillo/dillo3 CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables-fno-asynchronous-unwind-tables" CXXFLAGS=${CFLAGS} make clean hg pull hg update ./autogen.sh ./configure \ --prefix=${HOME}/.local \ --enable-ssl \ --disable-ipv6 \ --enable-cookies \ --enable-png \ --enable-jpeg \ --enable-gif \ --enable-threaded-dns \ --enable-dependency-tracking \ 2> ../build_err.txt make make install-strip The first time only, I uncoment the "hg clone" command. -- Walter Dnes <waltdnes at waltdnes.org>

July 8, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

On Wed, Jul 08, 2015 at 04:35:22AM +0000, eocene wrote: > I wrote: > > 2. I was reluctant to follow the full date parsing in RFC 6265 until I had a > > compelling reason, but you have brought me a compelling reason. github's > > cookies have expiration dates like "Sat, 07 Jul 2035 13:24:19 -0000", which > > appears to be legal, but dillo doesn't recognize it. So I'll work on it. > > Committed some code that's more similar to the RFC, and it recognizes > the github cookies. The code didn't turn out badly, so I don't know why > I was hesitant at the time. Once I learn (maybe soon) to really do right my own overlay in Gentoo (my own ebuilds, as it's just not good to compile and install outside of the system, the LinuxFromScratch way, which I learned long ago), then I hope I'll be a more useful tester. I'll try and always keep an eye on Dillo development, from my as-best-I-can user understanding, anyway. I had decided to go for the fonts-not-found issue ( http://lists.dillo.org/pipermail/dillo-dev/2015-April/010499.html) before I stumbled on this (Gitbub et alia) cookies issue. But, indeed I should be able to solve both these issue together, because the install from source, and from new SCM source is needed for both. For the: http://lists.dillo.org/pipermail/dillo-dev/2015-April/010500.html where eocene wrote: If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), remove the leading underscore in _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", to get MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", and recompile, what does dillo say when you run it? And for the new changes regarding cookies that eocene writes in the quote in the top of this message. I did look at the code, by downloading with 'hg clone http://hg.dillo.org/dillo', I clearly see where to remove the underscore (but there is also the: 'and recompile'). And on Gentoo, it's the local overlay way for me to go. Studying to be able to accomplish that. May take me time. But I'm now keen to do what I can to get, or to help with my report to get, those (both fonts and cookies) sorted. May take me an undefined time, for shorter of for longer (and I know it could take the fixing of the source un undefined time, for shorter or for longer). -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 8, 2015

Github et alia login/cookies issue

by eocene＠gmx.com

I wrote: > 2. I was reluctant to follow the full date parsing in RFC 6265 until I had a > compelling reason, but you have brought me a compelling reason. github's > cookies have expiration dates like "Sat, 07 Jul 2035 13:24:19 -0000", which > appears to be legal, but dillo doesn't recognize it. So I'll work on it. Committed some code that's more similar to the RFC, and it recognizes the github cookies. The code didn't turn out badly, so I don't know why I was hesitant at the time.

July 8, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

Forgot to post the Gentoo Forums' my new post's address. Correcting that below. On Tue, Jul 07, 2015 at 05:25:32PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > On Tue, Jul 07, 2015 at 04:57:57PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > On Tue, Jul 07, 2015 at 01:53:22PM +0000, eocene wrote: > > > miroslav.rovis1 wrote: > > https://forums.grsecurity.net > > Deply RBAC on Dillo browser > https://forums.grsecurity.net/viewtopic.php?f=5&t=4228 > And I've posted on Gentoo Forums, with a note about the paxctl-ng being deployed yesterday, id est before the reports in this thread. INCLUDED: Deploy paxctl-ng XATTR markings on Dillo browser https://forums.gentoo.org/viewtopic-t-1021518.html INCLUDED NOW. A sad note: The cookies.txt is not anymore being written to, and I haven't made any changes in my Dillo configuration: $ ls -l ~/.dillo/cookies.txt -rw------- 1 miro miro 24868 2015-07-07 11:34 /home/miro/.dillo/cookies.txt $ ( It is now: 2014-10-12 16:36 ) and I have, obviously logged in to post on Gentoo Forums. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

Forgot to post the Gentoo Forums' my new post's address. Correcting that below. On Tue, Jul 07, 2015 at 05:25:32PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > On Tue, Jul 07, 2015 at 04:57:57PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > On Tue, Jul 07, 2015 at 01:53:22PM +0000, eocene wrote: > > > miroslav.rovis1 wrote: > > https://forums.grsecurity.net > > Deply RBAC on Dillo browser > https://forums.grsecurity.net/viewtopic.php?f=5&t=4228 > And I've posted on Gentoo Forums, with a note about the paxctl-ng being deployed yesterday, id est before the reports in this thread. INCLUDED: Deploy paxctl-ng XATTR markings on Dillo browser https://forums.gentoo.org/viewtopic-t-1021518.html INCLUDED NOW. A sad note: The cookies.txt is not anymore being written to, and I haven't made any changes in my Dillo configuration: $ ls -l ~/.dillo/cookies.txt -rw------- 1 miro miro 24868 2015-07-07 11:34 /home/miro/.dillo/cookies.txt $ ( It is now: 2014-10-12 16:36 ) and I have, obviously logged in to post on Gentoo Forums. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

On Tue, Jul 07, 2015 at 05:25:32PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > On Tue, Jul 07, 2015 at 04:57:57PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > On Tue, Jul 07, 2015 at 01:53:22PM +0000, eocene wrote: > > > miroslav.rovis1 wrote: > > https://forums.grsecurity.net > > Deply RBAC on Dillo browser > https://forums.grsecurity.net/viewtopic.php?f=5&t=4228 > And I've posted on Gentoo Forums, with a note about the paxctl-ng being deployed yesterday, id est before the reports in this thread. A sad note: The cookies.txt is not anymore being written to, and I haven't made any changes in my Dillo configuration: $ ls -l ~/.dillo/cookies.txt -rw------- 1 miro miro 24868 2015-07-07 11:34 /home/miro/.dillo/cookies.txt $ ( It is now: 2014-10-12 16:36 ) and I have, obviously logged in to post on Gentoo Forums. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

On Tue, Jul 07, 2015 at 04:57:57PM +0200, miroslav.rovis1 at zg.ht.hr wrote: > On Tue, Jul 07, 2015 at 01:53:22PM +0000, eocene wrote: > > miroslav.rovis1 wrote: > > > On Tue, Jul 07, 2015 at 10:27:30AM +0200, miroslav.rovis1 at zg.ht.hr wrote: ... > So next is posting the relevant current configuration on: > > https://forums.grsecurity.net Deply RBAC on Dillo browser https://forums.grsecurity.net/viewtopic.php?f=5&t=4228 > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

On Tue, Jul 07, 2015 at 01:53:22PM +0000, eocene wrote: > miroslav.rovis1 wrote: > > On Tue, Jul 07, 2015 at 10:27:30AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > > "Something went wrong with that request. Please try again." > > ... > > > $ cat ~/.dillo/cookiesrc > > > DEFAULT DENY > > > .github.com ACCEPT > > ... > > > $ > > > > > ... > > > LATER. I even got (and all the conf is the same, .gitbub,com is in > > > cookiesrc), just this morning 2015-07-07 09:35 right now, the: > > > > > > "Cookies must be enabled to use GitHub." > > I see what the problems are with github cookies. > > 1. In cookiesrc, ".github.com" is for subdomains of github, and "github.com" > is for that host itself, so you need a "github.com" rule. > Yeah. It did occur to me, and I had removed the leading '.'. So that line in 'cookiesrc' now looks: github.com ACCEPT But I still can't log in, and it probably is the 2. below that you write. > 2. I was reluctant to follow the full date parsing in RFC 6265 until I had a > compelling reason, but you have brought me a compelling reason. github's > cookies have expiration dates like "Sat, 07 Jul 2035 13:24:19 -0000", which > appears to be legal, but dillo doesn't recognize it. So I'll work on it. > > (By the way, I wonder why they think their cookie should last for 20 years. > Makes me feel that I haven't been wasting my time with being careful with > Year 2038 overflow on 32-bit machines...) > However, it's even worse than that. I get maybe a thousand of lines per minute such as: Jul 7 16:22:04 g0n kernel: grsec: (miro:U:/usr/lib64/dillo/dpi) exec of /usr/lib64/dillo/dpi/cookies/cookies.dpi (/usr/lib64/dillo/dpi/cookies/cookies.dpi ) by /usr/lib64/dillo/dpi/cookies/cookies.dpi[dpid:1362] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/dpid[dpid:6224] uid/euid:1000/1000 gid/egid:1000/1000 Now, the explanation is I use: # cat /proc/sys/kernel/grsecurity/exec_logging 1 # the exec_logging functionality of the grsecurity-patched kernel. Excessive logs, true, but often I get the clues from those logs... I said it was worse, and it this sense. My: ~/.dillo/cookies.txt had only that one line that I send in the message: http://lists.dillo.org/pipermail/dillo-dev/2015-July/010582.html but now it has a huge many more of them: $ ls -l ~/.dillo/cookies.txt -rw------- 1 miro miro 24868 2015-07-07 11:34 /home/miro/.dillo/cookies.txt $ $ cat ~/.dillo/cookies.txt | wc -l 108 $ , and almost all those lines are from phpbb2mysql: $ cat ~/.dillo/cookies.txt | grep -v phpbb2mysql # HTTP Cookie File # This is a generated file! Do not edit. # [domain subdomains path secure expiry_time name value] [cookies dpi]: Enabling cookies as per cookiesrc... [cookies dpi]: Cookies loaded: 1. [cookies dpi]: (v.1) accepting connections... [cookies dpi]: denied SET for github.com [cookies dpi]: denied SET for github.com [cookies dpi]: denied SET for github.com Equally, all those lines are from forums.gentoo.org: $ cat ~/.dillo/cookies.txt | grep -v forums.gentoo.org # HTTP Cookie File # This is a generated file! Do not edit. # [domain subdomains path secure expiry_time name value] [cookies dpi]: Enabling cookies as per cookiesrc... [cookies dpi]: Cookies loaded: 1. [cookies dpi]: (v.1) accepting connections... [cookies dpi]: denied SET for github.com [cookies dpi]: denied SET for github.com [cookies dpi]: denied SET for github.com They look I can if I need to, look up all the variants, or encrypt then to your key, or plaintext if someone convinces me there should be nothing dangerous in revealing cookie content in this massive fashion; I don't know, will be thankful for any advice)... So those lines look like (a random one of those cca 100: [cookies dpi]: forums.gentoo.org GETTING: Cookie: phpbb2mysql_sid_s=a0cdf2e2eb297aa1127ff47385553234; phpbb2mysql_data_s=a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%34333s%3A6%3A%22182646%22%3B%7D; phpbb2mysql_t=a%3A2%3A%7Bi%3A1016338%3Bi%3A1436261111%3Bi%3A1021456%3Bi%3A1436261138%3B%7D (I changed just a few chars for my protection, really little knowledge of cookies) And I have done more work, and intend to do more, but I'll try and get, I think I wrote that in some of the previous mails, the opinion from forums.gresecurity.net on how to deply gradm, the grsecurity administration utility, how to reconfofigure it on Dillo... If I manage to open forums.gresecurity.net, because for some, probably related reason, I can't currently. I tried, and it was just the Stop icon with an 'x' in it going red, but wouldn't open. Then I tried killing dillo (first I tried without '-9', not shown below): # ps aux | grep dillo root 1477 0.0 0.0 11584 2044 pts/10 S+ 16:36 0:00 grep --colour=auto dillo miro 4527 0.0 0.0 4284 1424 tty6 S 10:30 0:00 /usr/lib64/dillo/dpi/bookmarks/bookmarks.dpi miro 4528 0.0 0.0 4408 1692 tty6 S 10:30 0:00 /usr/lib64/dillo/dpi/file/file.dpi miro 4905 0.0 0.0 4288 1460 tty6 S 10:55 0:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi miro 6225 0.0 0.0 4284 1260 tty6 S 16:14 0:00 /usr/lib64/dillo/dpi/bookmarks/bookmarks.dpi # And: # killall -9 4527 4528 4905 6225 4527: no process found 4528: no process found 4905: no process found 6225: no process found # But still: # ps aux | grep dillo root 1485 0.0 0.0 11584 2168 pts/10 S+ 16:37 0:00 grep --colour=auto dillo miro 4527 0.0 0.0 4284 1424 tty6 S 10:30 0:00 /usr/lib64/dillo/dpi/bookmarks/bookmarks.dpi miro 4528 0.0 0.0 4408 1692 tty6 S 10:30 0:00 /usr/lib64/dillo/dpi/file/file.dpi miro 4905 0.0 0.0 4288 1460 tty6 S 10:55 0:00 /usr/lib64/dillo/dpi/cookies/cookies.dpi miro 6225 0.0 0.0 4284 1260 tty6 S 16:14 0:00 /usr/lib64/dillo/dpi/bookmarks/bookmarks.dpi # Anyway, all the dillo windows are close. Trying again: forums.gresecurity.net No. Finding it in https://duckduckgo.com/html and opening it from there: worked. Now, let me explain how it went (and I hope some of the advanced users --or maybe even spender or PaX Team-- if they are reading this, I hope it helps diagnose the problems, btwn you, devs od Dillo, and them, the grsec/PaX devs. (I will, next, try and post my dillo related configuration in a new post that I will try and open in forums.gresecurity.net and then it will be a complete report, without that post to be it is not yet.) So, let me explain how it went: The link (be it from grsecurity.net or from debian net domain, which I tried also, as I wanted to show you that I evangelize for you, in digressiona: http://forums.debian.net/viewtopic.php?f=16&t=108616&p=584160#p584160 where find: because I really like Gentoo and (Debian/Devuan?), and Dillo and Postfix, and a lot of other programs ) So [the link] begins to open, and those maybe 1000 lines per minute begin to flood my /var/log/messages, Another typical one, just like the one that I already gave closer to the start of this message of mine: Jul 7 16:47:16 g0n kernel: grsec: (miro:U:/usr/lib64/dillo/dpi) exec of /usr/lib64/dillo/dpi/cookies/cookies.dpi (/usr/lib64/dillo/dpi/cookies/cookies.dpi ) by /usr/lib64/dillo/dpi/cookies/cookies.dpi[dpid:28919] uid/euid:1000/1000 gid/egid:1000/1000, parent /usr/bin/dpid[dpid:28798] uid/euid:1000/1000 gid/egid:1000/1000 Then I, in another terminal, as root, issue: # killall dpid which for grsecurity.net page opening need be done maybe once or rarely twice if at all, but for debian.net page opening needs to be done a few times, as it keeps restarting... And, if I missed to explain something, I'll try and remember and explain in the next message. As I said, for this to be complete, I need to get a better understanding of how to sort my /etc/grsec/policy for my Dillo. So next is posting the relevant current configuration on: https://forums.grsecurity.net -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by eocene＠gmx.com

miroslav.rovis1 wrote: > On Tue, Jul 07, 2015 at 10:27:30AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > > "Something went wrong with that request. Please try again." > ... > > $ cat ~/.dillo/cookiesrc > > DEFAULT DENY > > .github.com ACCEPT > ... > > $ > > > ... > > LATER. I even got (and all the conf is the same, .gitbub,com is in > > cookiesrc), just this morning 2015-07-07 09:35 right now, the: > > > > "Cookies must be enabled to use GitHub." I see what the problems are with github cookies. 1. In cookiesrc, ".github.com" is for subdomains of github, and "github.com" is for that host itself, so you need a "github.com" rule. 2. I was reluctant to follow the full date parsing in RFC 6265 until I had a compelling reason, but you have brought me a compelling reason. github's cookies have expiration dates like "Sat, 07 Jul 2035 13:24:19 -0000", which appears to be legal, but dillo doesn't recognize it. So I'll work on it. (By the way, I wonder why they think their cookie should last for 20 years. Makes me feel that I haven't been wasting my time with being careful with Year 2038 overflow on 32-bit machines...)

July 7, 2015

The FAQ example on png/redirection not anymore accurate

by eocene＠gmx.com

miroslav.rovis1 wrote: > Correct me if I'm wrong, but what I write is in my best understanding > and with the intention to help my most used browser get even better. > > The FAQ entry: > "Why doesn't Dillo display certain images?" > at: > http://www.dillo.org/FAQ.html#q28 > > doesn't show any of: > ... > ... 'blog.reuters.com' to 'ad.doubleclick.net' > ... > > as the text currently reads, which probably means they have read our FAQ > and decided to change those redirections. Rewrote the FAQ entry in an effort to emphasize that it was showing what was happening at the time and isn't exactly what you're likely to see today. The hope is that people see the principle involved from the example, that sometimes it blocked things that you wanted, and sometimes it blocked things that you did not want.

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

On Tue, Jul 07, 2015 at 10:27:30AM +0200, miroslav.rovis1 at zg.ht.hr wrote: > "Something went wrong with that request. Please try again." ... > $ cat ~/.dillo/cookiesrc > DEFAULT DENY > .github.com ACCEPT ... > $ > ... > LATER. I even got (and all the conf is the same, .gitbub,com is in > cookiesrc), just this morning 2015-07-07 09:35 right now, the: > > "Cookies must be enabled to use GitHub." ... > Could it be an issue with hardened? What I did yesterday (I began > writing this message yesterday, which is all before the "LATER" mark > above), is I applied paxctl-ng -m on the binaries in > /usr/lib64/dillo/dpi/*/<the binary>, id est: I disabled the MPROTEXT on > them. I also have a text prepared on those, hopefully I send it next. > It certainly is (also) an issue with the hardened. I fix somewhat my /etc/grsec/policy (and some other errors are gone), but... Let me see: no, from the github I still get: "Cookies must be enabled to use GitHub." and stubbornly so... I'll try and see if I can get any insight into this on forums,grsecurity.net and will report back. > -- > Miroslav Rovis > Zagreb, Croatia > http://www.CroatiaFidelis.hr > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Github et alia login/cookies issue

by miroslav.rovis1＠zg.ht.hr

"Something went wrong with that request. Please try again." is what I get (in bottom of the login page). The: $ cat ~/.dillo/cookiesrc DEFAULT DENY .github.com ACCEPT .devuan.org ACCEPT .gentoo.org ACCEPT .wikibooks.org ACCEPT .grsecurity.net ACCEPT $ contains them. And the: $ cat ~/.dillo/cookies.txt # HTTP Cookie File # This is a generated file! Do not edit. # [domain subdomains path secure expiry_time name value] $ is empty! I saw no errors in /var/log/messages though! But I'll try something. If it works for me, it might be useful for others, if not, maybe I get some help on it. I've always been able to login fine into forums.debian.net, forums.gentoo,org, forums.grsecurity.net and forum.sleuthkit.org (after Google stopped banning me, in the captcha that they use to register; Google, the surveillor of the world, is my distasteful enemy... Nobody should be afraid of them, lots of us Liliputians will always overcome any ugly Gullivers like the Schmoog is). --- All the above was prepared for sending yesterday, 2015-07-06. LATER. I even got (and all the conf is the same, .gitbub,com is in cookiesrc), just this morning 2015-07-07 09:35 right now, the: "Cookies must be enabled to use GitHub." when making another attemt to log into Github. But that was when I rebooted into my old: 3.19.6-hardened kernel maybe half hour ago (for unrelated reasons). And take a look at the following: This is the cookies.txt file, Only gentoo wrote in it, so far (and I accessed all those since, and esp. I took care to try the github). # HTTP Cookie File # This is a generated file! Do not edit. # [domain subdomains path secure expiry_time name value] forums.gentoo.org TRUE / TRUE 1467787565 phpbb2mysql_data_s a%3A2%3A%7Bs%3A11%3A%22autologinid%22%3Bs%3A0%3A%22%22%3Bs%3A6%3A%22userid%22%3Bs%3A6%3A%22334555%22%3B%7D Don't know if there's any secrets detrimental for me, that I'd be revealing, do modified some numbers in that forums.gentoo.org entry, just in case. I need to be on the fonts issue (but I think some of you, is it even you, Jorge, who do the development in gentoo, not sure)... I thought I'd still post this, as this might be a useful report for you, devs. OTOH, I'll post the emerge --info and more when I try the bug report on the fonts. Just: $ uname -r 4.0.7-hardened-150705 $ Could it be an issue with hardened? What I did yesterday (I began writing this message yesterday, which is all before the "LATER" mark above), is I applied paxctl-ng -m on the binaries in /usr/lib64/dillo/dpi/*/<the binary>, id est: I disabled the MPROTEXT on them. I also have a text prepared on those, hopefully I send it next. -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

Fonts not found issue persists in 3.0.5

by miroslav.rovis1＠zg.ht.hr

I got the new Dillo version 3.0.5 (in the master air-gapped box, which I yet have to clone onto this, for online, same hardware box), as it is available in gentoo: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/dillo/ but my problem with fonts (the FAQ issue http://www.dillo.org/FAQ.html#q27) to which eocene has kindly given the tip for in his message: http://lists.dillo.org/pipermail/dillo-dev/2015-April/010500.html For people reading this message offline, I'll paste his advice, since it is also important: If you go to dw/fltkplatform.cc and, in FltkFont::initSystemFonts(), remove the leading underscore in _MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", to get MSG("Found font: %s%s%s\n", name, t & FL_BOLD ? " bold" : "", and recompile, what does dillo say when you run it? And I was saying that that problem I still have in my 3.0.5. I hoped it would have been solved, but since it hasn't been, for me who am not really a developer, to go and recompile means first get (finally, it's been waiting for me since long) a little really deeper and dirty with the Gentoo ebuild system, and, basically compile my own ebuild... or... Or get Gentoo developers to do it for all of the Dillo Gentoo users. Since my eyes are sore from too small and non configurable fonts, I'm afraid I will have to do one of the above... For the latter, since this issue has been discussed, and previous to eocene's message you can see that I extensively described it, what do kind Dillo devs think: the second route to take, which is: file a bug on Gentoo bugzilla with basically updated real output from the new Dillo 3.0.5, might probably be shorter route to get this issue fixed? That is what I should try first, isn't it. Oh, well, I hope I haven't been too lengthy.,, Another issue I also have. Can't log into: https://github.com/miroR And was able to log into it with lynx, and open my new repo https://github.com/miroR/flowstamp So it doesn't seem to be github follows the big JS-and-all browsers else-get-lost policy like soo many... Depending on the soonness of the fonts solution, I'd be willing to provide more information, such as the full screencast/traffic-dump of my future attempt to log into Github, so we get this done... Depending on that being solved (I'm not expert by any means, and who knows if I get any help from Gentoo devs, who are overworked). Really depending on the fonts issue being solve first, as my eyes hurt (born with somewhat poor eyesight, but getting worse, am 58 ys of age). Cheers, and keep up the good work. I hope you all keep in harmony, as soo much if missing for Dillo to become a complete browser... I'll be pretty sad if any bad rifts were to appear among the team... Pls. find the right way between yourselves, and do only what is right and honest for all of you! Much is missing in the Dillo, but, you seem to be the strongest around that keep free! Free from surveillors! I was really right when in what I posted on: Secure: yes, Though Features Missing; and Bugs http://lists.dillo.org/pipermail/dillo-dev/2015-April/010495.html (too much to paste for offline readers, but in short, I compared the Firefox harvesting on users with the sea-calm when online of kind and secure Dillo) Kind regards, -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

The FAQ example on png/redirection not anymore accurate

by miroslav.rovis1＠zg.ht.hr

Correct me if I'm wrong, but what I write is in my best understanding and with the intention to help my most used browser get even better. The FAQ entry: "Why doesn't Dillo display certain images?" at: http://www.dillo.org/FAQ.html#q28 doesn't show any of: ... ... 'blog.reuters.com' to 'ad.doubleclick.net' ... as the text currently reads, which probably means they have read our FAQ and decided to change those redirections. This is what I actually get when I uncomment the line which is commented the way the built-in default settings are, as it says in the top of ~/.dillo/dillorc to read: show_msg=YES (but it shows the same even if I leave if commented out; it's the default, I retried with it commented out: same) $ Domain: Default accept. dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://en.wikipedia.org' Dns_server [0]: en.wikipedia.org is 91.198.174.192 2620:0:862:ed1a::1 Connecting to 91.198.174.192 Nav_open_url: new url='https://en.wikipedia.org/' Nav_open_url: new url='https://en.wikipedia.org/wiki/Main_Page' NumPendingStyleSheets=1 NumPendingStyleSheets=2 Png_error_handling: iCCP: known incorrect sRGB profile So probably the example should be changed to reflect this changed reality, so users would not get confused as they will probably see none of those 'reuters' lines in the messages on their terminal. Maybe it would be sufficient to just rewrite that item of the FAQ to mean that previously they would have seen those messages... Don't know. Again, correct me if I'm wrong. On another note, I got the new 3.0.5, as it is available in gentoo, but I have the same fonts not found issue which I had previously described (and it's there in yesterday's real output form my system, further above; it was yesterday, the delay being for unrelated reasons), and about which (the fonts not found issue) I will next send another message, with different, appropriate subject, to this list, I hope. Cheers! -- Miroslav Rovis Zagreb, Croatia http://www.CroatiaFidelis.hr

July 7, 2015

what is done with the dillo project donation money?

by eocene＠gmx.com

I've wondered what is done with the dillo project donation money. Does it go toward Andreas's hosting costs or something?

July 6, 2015

Site is down?

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > Just noticed I can't contact the website, is it down? I can access it fine. Regards, Jeremy Henty

July 4, 2015

Site is down?

by abe＠deuxchevaux.org

Hi, On Fri, Jul 03, 2015 at 08:17:57PM -0300, Jorge Arellano Cid wrote: > Just noticed I can't contact the website, is it down? http://www.dillo.org/ works fine for me. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

July 3, 2015

Site is down?

by jcid＠dillo.org

Hi there, Just noticed I can't contact the website, is it down? -- Cheers Jorge.-

July 3, 2015

Dillo 3.0.5 released

by eocene＠gmx.com

All right, release is official... Thanks everyone! PS Here are the changes that found their way into ChangeLog: Image buffer/cache improvements. Fix for segfault when there's no dpid and view source is requested. Fix view-source dpi to handle null characters correctly. Made view-source dpi use CSS formatting (it's shorter and cleaner). Crosscompile/buildroot-friendly fltk-config test. Fix X11 icon name. In location bar, tend toward showing beginning of URL instead of end. Handle irix's version of vsnprintf(). INPUT, TEXTAREA placeholder attribute. Better notification when user's domainrc settings block page redirection. Fix bug with font_factor preference and CSS font-size:(larger|smaller). Recognize Menu key in keysrc. HTTPS: change cipher list to "ALL:!aNULL:!eNULL:!LOW:!EXPORT40:!RC4", disable SSL3, disable TLS compression. Avoid requesting background images if an ancestor has display:none. Ignore built-in search url if any are specified in dillorc.

July 2, 2015

Here's 3.0.5 RC1

by v4hn＠lunar-linux.org

On Tue, Jun 30, 2015 at 07:55:08PM +0000, eocene wrote: > Now there's a 3.0.5 tarball: > http://www.dillo.org/download/dillo-3.0.5.tar.bz2 > http://www.dillo.org/download/dillo-3.0.5.tar.bz2.asc > > Please test, send feedback, Builds and runs smoothly on Lunar-Linux. Thanks a lot! v4hn

July 1, 2015

Here's 3.0.5 RC1

by abe＠deuxchevaux.org

Hi, On Tue, Jun 30, 2015 at 07:55:08PM +0000, eocene wrote: > Now there's a 3.0.5 tarball: > http://www.dillo.org/download/dillo-3.0.5.tar.bz2 > http://www.dillo.org/download/dillo-3.0.5.tar.bz2.asc > > Please test, send feedback, and if all is well, I'll make an > official announcement in a couple of days... Built fine on all Debian architectures: https://buildd.debian.org/status/package.php?p=dillo http://buildd.debian-ports.org/status/package.php?p=dillo&suite=sid Works fine on at least Debian's amd64 architecture. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.nonhtmlmail.org/campaign.html | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://abe.noone.org/ (Web)

July 1, 2015

Here's 3.0.5 RC1

by Johannes.Hofmann＠gmx.de

On Tue, Jun 30, 2015 at 07:55:08PM +0000, eocene wrote: > > Now there's a 3.0.5 tarball: > http://www.dillo.org/download/dillo-3.0.5.tar.bz2 > http://www.dillo.org/download/dillo-3.0.5.tar.bz2.asc > > Please test, send feedback, and if all is well, I'll make an > official announcement in a couple of days... Works fine here on DragonFly BSD. Cheers, Johannes

July 1, 2015

Here's 3.0.5 RC1

by eocene＠gmx.com

Now there's a 3.0.5 tarball: http://www.dillo.org/download/dillo-3.0.5.tar.bz2 http://www.dillo.org/download/dillo-3.0.5.tar.bz2.asc Please test, send feedback, and if all is well, I'll make an official announcement in a couple of days...

June 30, 2015

Here's 3.0.5 RC1

by diegel＠work.de

Compiles and works on Irix 6.5 with very little changes. eocene wrote: > In my use of the 3.0.5 branch, there haven't been any unpleasant surprises, > so let's have an RC: > > http://www.dillo.org/download/dillo-3.0.5-rc1.tar.bz2 > > If it's any comfort to have the sha256sum, it's: > 484748e98b263ccd595ce349857edec4a431feb414e44cdbe86722a64387d000 > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >

June 19, 2015

Dillo version 3.1-dev hangs on http://www.nhl.com

by waltdnes＠waltdnes.org

I pulled a few minutes ago and built it (8-year-old Intel Core 2 Duo running 64-bit Gentoo linux). It runs OK on CNN.COM and even the NHL mobile site http://m.nhl.com but with most of the tabs not working (Javascript, I assume). However, going to the main NHL site http://www.nhl.com hangs dillo and pegs a CPU. Here's a line of output from "top c", showing 99.2% CPU usage... 19235 waltdnes 20 0 328552 114840 11708 R 99.2 3.7 0:09.89 /home/waltdnes/.local/bin/dillo I have to pop open an xterm window and kill the pid e.g. "kill -3 19235" "dillo -v" shows "Dillo version 3.1-dev" -- Walter Dnes <waltdnes at waltdnes.org>

June 18, 2015

Here's 3.0.5 RC1

by Johannes.Hofmann＠gmx.de

On Wed, Jun 17, 2015 at 04:37:01PM +0000, eocene wrote: > > In my use of the 3.0.5 branch, there haven't been any unpleasant surprises, > so let's have an RC: > > http://www.dillo.org/download/dillo-3.0.5-rc1.tar.bz2 > > If it's any comfort to have the sha256sum, it's: > 484748e98b263ccd595ce349857edec4a431feb414e44cdbe86722a64387d000 compiles and runs nicely on DragonFly BSD. Cheers, Johannes

June 18, 2015

Here's 3.0.5 RC1

by sgeerken＠dillo.org

Should have gone to the list ... On Mi, Jun 17, 2015, eocene wrote: > In my use of the 3.0.5 branch, there haven't been any unpleasant surprises, > so let's have an RC: > > http://www.dillo.org/download/dillo-3.0.5-rc1.tar.bz2 Works without problems. > If it's any comfort to have the sha256sum, it's: > 484748e98b263ccd595ce349857edec4a431feb414e44cdbe86722a64387d000 Correct! Sebastian

June 17, 2015

Here's 3.0.5 RC1

by eocene＠gmx.com

In my use of the 3.0.5 branch, there haven't been any unpleasant surprises, so let's have an RC: http://www.dillo.org/download/dillo-3.0.5-rc1.tar.bz2 If it's any comfort to have the sha256sum, it's: 484748e98b263ccd595ce349857edec4a431feb414e44cdbe86722a64387d000

June 17, 2015

splash links

by eocene＠gmx.com

Jorge wrote: > On Mon, Jun 15, 2015 at 04:33:03PM +0000, eocene wrote: > > 2. In my opinion, it wouldn't do any harm to remove the "News", "Additional > > Stuff", and "Essential Readings" links, as they have something of an > > Internet Circa 2002 flavor (in some ways it's a shame to think how > > pioneering projects like Project Gutenberg lose their preeminence as the > > pioneer days end, but I suppose that's the way of things). > > In my opinion those links are very important, and want to keep them > there. It later occurred to me that maybe the most accurate thing would be to label them as Jorge's Links, whereas they currently would be understood by a user to be the Dillo core team's links, which they aren't.

June 15, 2015

splash links

by jcid＠dillo.org

On Mon, Jun 15, 2015 at 04:33:03PM +0000, eocene wrote: > > 1. freecode. Between the fact that the site's been in suspended animation > for a year and there's been all of this sourceforge unpleasantness just > lately, it would be nice not to link to them. OK. > > 2. In my opinion, it wouldn't do any harm to remove the "News", "Additional > Stuff", and "Essential Readings" links, as they have something of an > Internet Circa 2002 flavor (in some ways it's a shame to think how > pioneering projects like Project Gutenberg lose their preeminence as the > pioneer days end, but I suppose that's the way of things). In my opinion those links are very important, and want to keep them there. > PS Been running on the 3.0.5 branch here, of course, and everything's been > fine so far. Good. -- Cheers Jorge.-

June 15, 2015

splash links

by eocene＠gmx.com

1. freecode. Between the fact that the site's been in suspended animation for a year and there's been all of this sourceforge unpleasantness just lately, it would be nice not to link to them. 2. In my opinion, it wouldn't do any harm to remove the "News", "Additional Stuff", and "Essential Readings" links, as they have something of an Internet Circa 2002 flavor (in some ways it's a shame to think how pioneering projects like Project Gutenberg lose their preeminence as the pioneer days end, but I suppose that's the way of things). PS Been running on the 3.0.5 branch here, of course, and everything's been fine so far.

June 15, 2015