February 2015 - Dillo-dev - lists.mailman3.com

Problem with page positioning.

by james.from.wellington＠gmail.com

Hi All, I can reproduce the reported behavior, with the reported test-case, with source up to change 986b7e7 I'm fairly sure that: - the page loads, and a scroll position is determined - the css loads, and the page is re-drawn -- wrongly, at the same scroll position, rather than at the scroll position that now matches the request I'm fairly sure that FRAGMENT is the part of the URL that contains a request to scroll to an anchor. If I was looking for a part of the code to blame, then my current pick is: "nav.c" line 303 and friends; possibly "nav.c" line 308 but I know that I don't have a taxonomy of all "repush"es, and how to determine that this is the one where that case should not apply :-) Regards, James. On 26/02/2015, John Found <johnfound at asm32.info> wrote: > Hi all. It is my first post on this mailing list. > > I want to use Dillo as a HTML help browser for my program. I need it, > because it has faster startup time and this is very important > for a help system, where the user presses F1 and expects the help to open > instantly. (What is not the case with all other browsers). > > Anyway, the problem I have is that when starting Dillo with URL that > contains local anchor ID, it first positions properly, but short time later, > (when the CSS get loaded?) it repositions the page and the needed element > moves somewhere else, very far from the current page position. > > Example that can be tested: > http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDo… > > Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking > on "Reload" button, repositions the page to the proper position. > > Is this problem can be easily solved? > I can try to fix it by myself, but my C/C++ skills are very low and then I > will need some assistance. > > Best Regards and thanks for the great browser. > > -- > http://fresh.flatassembler.net > http://asm32.info > John Found <johnfound at asm32.info> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Feb. 26, 2015

Problem with page positioning.

by johnfound＠asm32.info

Hi all. It is my first post on this mailing list. I want to use Dillo as a HTML help browser for my program. I need it, because it has faster startup time and this is very important for a help system, where the user presses F1 and expects the help to open instantly. (What is not the case with all other browsers). Anyway, the problem I have is that when starting Dillo with URL that contains local anchor ID, it first positions properly, but short time later, (when the CSS get loaded?) it repositions the page and the needed element moves somewhere else, very far from the current page position. Example that can be tested: http://fresh.flatassembler.net/index.cgi?page=content/articles/2_FreshLibDo… Once the page is loaded (on the wrong position), pressing Ctrl+R or clicking on "Reload" button, repositions the page to the proper position. Is this problem can be easily solved? I can try to fix it by myself, but my C/C++ skills are very low and then I will need some assistance. Best Regards and thanks for the great browser. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>

Feb. 25, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On So, Feb 15, 2015, eocene wrote: > As for speed, I'd spent enough time with dillo being pretty slow before > those optimizations were made in the past month or two that I've somewhat > lost my feel for how fast dillo is supposed to be... I sometimes use time(1) to compare 3.0.4 and 3.1-dev, and as far as I remember, the differences are not significant. Of course, except for show stoppers (hanging (really taking too much time), CPU hoggig etc.), which should be regarded as plain bugs. Sebastian

Feb. 16, 2015

what's currently broken in dillo

by eocene＠gmx.com

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

Feb. 15, 2015

outofflowmgr.cc:1527: Assertion `yReq >= 0' failed.

by eocene＠gmx.com

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

Feb. 12, 2015

page that hangs

by eocene＠gmx.com

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

Feb. 10, 2015

Core-dump pasting from one form field into another

by Johannes.Hofmann＠gmx.de

Hi James, On Sun, Feb 01, 2015 at 04:06:01PM +1300, James C wrote: > Hello Johannes et al, > > Unless circumstances intervene, a future release of FLTK will support > DND on OSX without RTTI:: > https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxj… thanks that you brought up the topic on the FLTK list! > > I vote for leaving DND disabled until the FLTK people are ready to > make that release. sure. Regards, Johannes > > Regards, > James. > > On 23/01/2015, James C <james.from.wellington at gmail.com> wrote: > > Hello Johannes et al, > > > > I've logged this with the FLTK people. > > http://www.fltk.org/str.php?L3178 > > > > Regards, > > James. > > > > On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: > >> Hi James, > >> > >> On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: > >>> Hi All, > >>> > >>> I think I've worked out what's going on with drag-and-drop. > >>> > >>> We're compiling with -fno-rtti and (some parts of) fltk do > >>> dynamic_cast, which needs rtti. The run-time handling for detecting > >>> the conflict is nonexistent/unforgiving. > >>> > >>> When I make the change below and rebuild, drag-and-drop starts working > >>> for > >>> me. > >> > >> Cool that you found the reason! > >> From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work > >> without rtti, but things might have changed of course. > >> It would be cool if you could bring up the topic on an fltk list to > >> see if it's intended like this. > >> > >> Cheers, > >> Johannes > >> > >> _______________________________________________ > >> Dillo-dev mailing list > >> Dillo-dev at dillo.org > >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > >> > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Feb. 2, 2015

Core-dump pasting from one form field into another

by james.from.wellington＠gmail.com

Hello Johannes et al, Unless circumstances intervene, a future release of FLTK will support DND on OSX without RTTI:: https://groups.google.com/forum/#!searchin/fltkgeneral/rtti/fltkgeneral/yxj… I vote for leaving DND disabled until the FLTK people are ready to make that release. Regards, James. On 23/01/2015, James C <james.from.wellington at gmail.com> wrote: > Hello Johannes et al, > > I've logged this with the FLTK people. > http://www.fltk.org/str.php?L3178 > > Regards, > James. > > On 20/01/2015, Johannes Hofmann <johannes.hofmann at gmx.de> wrote: >> Hi James, >> >> On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: >>> Hi All, >>> >>> I think I've worked out what's going on with drag-and-drop. >>> >>> We're compiling with -fno-rtti and (some parts of) fltk do >>> dynamic_cast, which needs rtti. The run-time handling for detecting >>> the conflict is nonexistent/unforgiving. >>> >>> When I make the change below and rebuild, drag-and-drop starts working >>> for >>> me. >> >> Cool that you found the reason! >> From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work >> without rtti, but things might have changed of course. >> It would be cool if you could bring up the topic on an fltk list to >> see if it's intended like this. >> >> Cheers, >> Johannes >> >> _______________________________________________ >> Dillo-dev mailing list >> Dillo-dev at dillo.org >> http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >> >

Feb. 1, 2015