- Dillo-dev - lists.mailman3.com

Dillo_grows merged

by sgeerken＠dillo.org

On So, Mai 15, 2016, Jorge Arellano Cid wrote: > Hi Sebastian, > > On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote: > > Hi there! > > > > On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > > > On Sat, 14 May 2016 22:48:12 +0000 > > > eocene <eocene at gmx.com> wrote: > > > > > > > > Searching the page doesn't cause any more, though. > > > > > > > > Searching backward causes segfaults with regularity. > > > > > > Messing about with this this morning, the segfault happens when using > > > 'previous' goes back past the first found 'next'. > > > > Yes. > > > > I sent this bug to Per Anderson a few weeks ago for him to debug, > > but didn't get an answer. @Per: did you get the email? > > > > Anyway, today I made a simple patch for it, but will investigate > > the issue a bit further before sending it to Sebastian for review. > > OK, the bisect shows the problem starts with commit 4241 which is > a new design for textblock iterators. > > The attached patch works OK for the text search, but I don't know > whether it fits with the overall design. > > It *seems to fit* but I'd prefer you to check it. ;) I've just pushed a variant of your patch, please give it a try. Sebastian

May 16, 2016

Dillo_grows merged

by jcid＠dillo.org

Hi Sebastian, On Sun, May 15, 2016 at 04:42:31PM -0400, Jorge Arellano Cid wrote: > Hi there! > > On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > > On Sat, 14 May 2016 22:48:12 +0000 > > eocene <eocene at gmx.com> wrote: > > > > > > Searching the page doesn't cause any more, though. > > > > > > Searching backward causes segfaults with regularity. > > > > Messing about with this this morning, the segfault happens when using > > 'previous' goes back past the first found 'next'. > > Yes. > > I sent this bug to Per Anderson a few weeks ago for him to debug, > but didn't get an answer. @Per: did you get the email? > > Anyway, today I made a simple patch for it, but will investigate > the issue a bit further before sending it to Sebastian for review. OK, the bisect shows the problem starts with commit 4241 which is a new design for textblock iterators. The attached patch works OK for the text search, but I don't know whether it fits with the overall design. It *seems to fit* but I'd prefer you to check it. ;) -- Cheers Jorge.-

May 16, 2016

Dillo_grows merged

by jcid＠dillo.org

Hi there! On Sun, May 15, 2016 at 01:17:40PM +0100, Nick Warne wrote: > On Sat, 14 May 2016 22:48:12 +0000 > eocene <eocene at gmx.com> wrote: > > > > Searching the page doesn't cause any more, though. > > > > Searching backward causes segfaults with regularity. > > Messing about with this this morning, the segfault happens when using > 'previous' goes back past the first found 'next'. Yes. I sent this bug to Per Anderson a few weeks ago for him to debug, but didn't get an answer. @Per: did you get the email? Anyway, today I made a simple patch for it, but will investigate the issue a bit further before sending it to Sebastian for review. -- Cheers Jorge.-

May 15, 2016

Dillo_grows merged

by nick＠linicks.net

On Sat, 14 May 2016 22:48:12 +0000 eocene <eocene at gmx.com> wrote: > > Searching the page doesn't cause any more, though. > > Searching backward causes segfaults with regularity. Messing about with this this morning, the segfault happens when using 'previous' goes back past the first found 'next'. i.e. start Dillo with the default home page and search text for 'the'. find the next 'the' a few times, and then use 'previous'. It will work OK until it gets back to the beginning when the next (and final) 'previous' will crash Dillo. Looks like the index is going off the bottom of the search list. I looked at the code a bit, but C++ is all greek to me. Strangely, gdb always reports: Program received signal SIGSEGV, Segmentation fault. 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 102 widget->outOfFlowMgr[sectionIndex - 1]->getWidget (index); this -> sectionIndex=5, index=8 and a backtrace: #0 0x080b4638 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart ( this=0x836ec60, sectionIndex=5, index=8, content=0x836ec64) at oofawarewidget_iterator.cc:102 #1 0x080b4822 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev ( this=0x836ec60) at oofawarewidget_iterator.cc:216 #2 0x080c3d5c in dw::core::DeepIterator::prev (this=this at entry=0x83712b0) at iterator.cc:708 #3 0x080c4058 in dw::core::CharIterator::prev (this=0x8360298) at iterator.cc:825 #4 0x080c2877 in dw::core::FindtextState::search (this=0x82c6244, key=key at entry=0x836e9d8 "the", caseSens=false, backwards=backwards at entry=true) at findtext.cc:135 #5 0x08058e43 in search (backwards=1, caseSens=false, str=0x836e9d8 "the", this=<optimized out>) at ../dw/layout.hh:431 #6 a_UIcmd_findtext_search (bw=0x82c5768, key=0x836e9d8 "the", case_sens=0, backward=1) at uicmd.cc:1484 #7 0x08089964 in Findbar::searchBackwards_cb (vfb=0x826d4c8) at findbar.cc:100 #8 0xb7ef2677 in Fl_Widget::do_callback(Fl_Widget*, void*) () from /usr/lib/libfltk.so.1.3 #9 0xb7e99d13 in Fl_Button::handle(int) () from /usr/lib/libfltk.so.1.3 #10 0xb7e91098 in ?? () from /usr/lib/libfltk.so.1.3 #11 0xb7e92ffd in Fl::handle_(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #12 0xb7e9340c in Fl::handle(int, Fl_Window*) () from /usr/lib/libfltk.so.1.3 #13 0xb7efa0a8 in fl_handle(_XEvent const&) () from /usr/lib/libfltk.so.1.3 ---Type <return> to continue, or q <return> to quit--- #14 0xb7efb400 in ?? () from /usr/lib/libfltk.so.1.3 #15 0xb7efb5f2 in ?? () from /usr/lib/libfltk.so.1.3 #16 0xb7e929c7 in Fl::wait(double) () from /usr/lib/libfltk.so.1.3 #17 0xb7e92ace in Fl::run() () from /usr/lib/libfltk.so.1.3 #18 0x080514e0 in main (argc=1, argv=0xbffff0d4) at dillo.cc:578 Hope that helps. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 15, 2016

Dillo_grows merged

by eocene＠gmx.com

On Sun, Apr 24, 2016 at 10:02:13PM +0000, eocene wrote: > On Sun, Apr 24, 2016 at 09:15:42PM +0200, Sebastian Geerken wrote: > > On Tue, Apr 19, 2016, eocene wrote: > > > > > > Here's a segfault backtrace that I just got: > > > > > > #0 0x080ab83d in dw::Textblock::sizeRequestReference (this=0x955e260, > > > index=-1224641713) at textblock.cc:423 > > > #1 0x080bcd63 in dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::numParts ( > > > this=0x9e446a8, sectionIndex=-1, numContentsInFlow=0) > > > at oofawarewidget_iterator.cc:84 > > > > I do not understand what has actually happens (look at the code). Did > > you compile dillo with -O2 or -O0? Can you provide a test case how > > this is reproduced? > > > > Perhaps this is related to another prolem: valgrind prints some > > warnings, which neither make sense to me. > > As I recall, I was double-checking whether the textarea row attr default > was still 2 in html5 (https://www.w3.org/TR/html51/sec-forms.html#the-textarea-element) > searching for "rows ". But when I try this again, it doesn't crash. > > FWIW, I compiled with -O0. > > *tries valgrind* > I do get a number of "Conditional jump or move depends on uninitialised value(s)" when the page loads. > > Searching the page doesn't cause any more, though. Searching backward causes segfaults with regularity. If I run under valgrind, I get: ==9344== Conditional jump or move depends on uninitialised value(s) ==9344== at 0x80A4493: dw::oof::OOFPositionedMgr::sizeAllocateStart(dw::oof::OOFAwareWidget*, dw::core::Allocation*) (oofpositionedmgr.cc:78) ==9344== by 0x809F7E6: dw::oof::OOFAwareWidget::sizeAllocateStart(dw::core::Allocation*) (oofawarewidget.cc:347) ==9344== by 0x80ABDB6: dw::Textblock::sizeAllocateImpl(dw::core::Allocation*) (textblock.cc:585) ==9344== by 0x80E0DAD: dw::core::Widget::sizeAllocate(dw::core::Allocation*) (widget.cc:1135) ==9344== by 0x80D3D77: dw::core::Layout::resizeIdle() (layout.cc:924) ==9344== by 0x80C1B63: dw::fltk::FltkPlatform::generalIdle() (fltkplatform.cc:630) ==9344== by 0x80C1AEB: dw::fltk::FltkPlatform::generalStaticIdle(void*) (fltkplatform.cc:620) ==9344== by 0x4120CDB: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x4691E45: (below main) (libc-start.c:244) ==9344== ==9344== Invalid read of size 4 ==9344== at 0x80BCFA7: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart(int, int, dw::core::Content*) (oofawarewidget_iterator.cc:102) ==9344== by 0x80BD27D: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev() (oofawarewidget_iterator.cc:204) ==9344== by 0x80D0AA3: dw::core::DeepIterator::prev() (iterator.cc:708) ==9344== by 0x80D0F91: dw::core::CharIterator::prev() (iterator.cc:825) ==9344== by 0x80CEC72: dw::core::FindtextState::search(char const*, bool, bool) (findtext.cc:104) ==9344== by 0x805AA00: dw::core::Layout::search(char const*, bool, int) (layout.hh:431) ==9344== by 0x805A702: a_UIcmd_findtext_search (uicmd.cc:1484) ==9344== by 0x8090AD6: Findbar::searchBackwards_cb(Fl_Widget*, void*) (findbar.cc:100) ==9344== by 0x411F4FF: Fl_Widget::do_callback(Fl_Widget*, void*) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x805306F: CustButton::handle(int) (tipwin.cc:194) ==9344== by 0x40D99B3: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x40DA255: Fl_Group::handle(int) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== Address 0x363 is not stack'd, malloc'd or (recently) free'd ==9344== ==9344== ==9344== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==9344== Access not within mapped region at address 0x363 ==9344== at 0x80BCFA7: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::getPart(int, int, dw::core::Content*) (oofawarewidget_iterator.cc:102) ==9344== by 0x80BD27D: dw::oof::OOFAwareWidget::OOFAwareWidgetIterator::prev() (oofawarewidget_iterator.cc:204) ==9344== by 0x80D0AA3: dw::core::DeepIterator::prev() (iterator.cc:708) ==9344== by 0x80D0F91: dw::core::CharIterator::prev() (iterator.cc:825) ==9344== by 0x80CEC72: dw::core::FindtextState::search(char const*, bool, bool) (findtext.cc:104) ==9344== by 0x805AA00: dw::core::Layout::search(char const*, bool, int) (layout.hh:431) ==9344== by 0x805A702: a_UIcmd_findtext_search (uicmd.cc:1484) ==9344== by 0x8090AD6: Findbar::searchBackwards_cb(Fl_Widget*, void*) (findbar.cc:100) ==9344== by 0x411F4FF: Fl_Widget::do_callback(Fl_Widget*, void*) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x805306F: CustButton::handle(int) (tipwin.cc:194) ==9344== by 0x40D99B3: ??? (in /usr/lib/i386-linux-gnu/libfltk.so.1.3) ==9344== by 0x40DA255: Fl_Group::handle(int) (in /usr/lib/i386-linux-gnu/libfltk.so.1.3)

May 14, 2016

Firefox bookmarks.html convertor for Dillo

by nick＠linicks.net

On Sat, 14 May 2016 13:19:30 +0100 Nick Warne <nick at linicks.net> wrote: > Attached is a short perl script that converts FF bookmarks.html (which > can be exported within FF itself) to Dillo format bm.txt. > > Simple to use, and the code has brief instructions. > > The only thing I am not sure about is if different versions of FF use > the same bookmarks.html format. A slightly improved version that doesn't strip all white space in the URL 'name', and also ignores rss feeds. I also forgot to mention that any bookmarks in the root (i.e. no section) get stuffed into the last section parsed - these can easily be handled in Dillos' bookmark menu 'modify'. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 14, 2016

Firefox bookmarks.html convertor for Dillo

by nick＠linicks.net

Hi all, Attached is a short perl script that converts FF bookmarks.html (which can be exported within FF itself) to Dillo format bm.txt. Simple to use, and the code has brief instructions. The only thing I am not sure about is if different versions of FF use the same bookmarks.html format. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 14, 2016

"ok" for unnested body

by jcid＠dillo.org

On Mon, May 02, 2016 at 10:14:39PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sat, Apr 30, 2016 at 11:48:18AM -0300, genoob wrote: > > Hello! > > I'm a noob, so I'm sorry if this is actually not an issue, but I've > > searched and haven't found anything on this. > > > > When creating a simple list using `ul` (I've replaced < > with `` in > > order to avoid html parsing by some readers) tags I accidentally > > placed it after `/body``/html` and to my surprise It wasn't marked as > > an html error and the data was correctly displayed, jus like it would > > be had the list been placed inside the `html``body` `/body``/html` > > tags. Unnesting `li` from `ul` however displayed nesting problem, but > > only referring to the `li` being out of `ul` or `ol` tags, not from it > > being unnested from `html` `body`. > > > > I realize my explanation might be a little confusing at this point, so > > this is what I mean: > > > > I put it on bpaste so this message wouldn't be flagged as spam: > > https://bpaste.net/show/ed1374304997 > > And this is a screenshot of the data being displayed and getting a > > thumbs-up from the browser in case its relevant: > > http://i.imgur.com/d1f9Pv9.png > > > > I'd like to report this in case it's a bug(invalid html being marked > > valid), however if it's a valid html you can disregard/exclude this > > message from the list with no hard feelings. > > > > I'm using dillo-3.0.5-r1 by the way. > > > > I'm sorry if this was confusing and wasted your time. > > In case you need more info on my system I'm happy to help however I can. > > > > And thanks for maintaining such a nice project (It really helped me a > > lot thus far). > > A bit of history... > > Long ago, dillo stopped rendering after BODY or HTML was closed. > > Unfortunately several free web hosting sites were serving their client's > sites wrapped within their formats (mainly advertising); fair enough. > But they were using poor HTML (tag soup) and used to close BODY even more > than twice. Dillo users complained that their sites were not visible with > Dillo... > > At some point we decided to keep rendering until EOF. > > Now, coding detection for this type of bug is possible and not that > complex, it is just low on priority (i.e. patch welcomed). Ooops! It was way more complex than I initially thought. > Anyway, it > needs a solid understanding of the parsing code. I'll give it a quick look > and if I can come with a short patch, it could be committed. After a quick look, and some patch tries it became clear that it was going to require a full re-understanding of the html stack-handling by the parser. It took a few days, but now I've refreshed my brain cells on what was exactly going on there, then decided a policy, spotted some bugs, and improved error detection and messages, in the bug meter. Patch committed to our hg repo. -- Cheers Jorge.-

May 11, 2016

Bug in meta tag refresh code [with cause]

by nick＠linicks.net

On Tue, 10 May 2016 19:20:21 +0000 eocene <eocene at gmx.com> wrote: > On Tue, May 10, 2016 at 10:38:57AM -0300, Jorge Arellano Cid wrote: > > Yes. This stems from two reasons: the meta-refresh element has no > > defined standard, and our code has evolved accomodating to work > > with what we've found along the way. > > They do have refresh in html5: > https://www.w3.org/TR/html51/document-metadata.html#statedef-http-equiv-ref… Quick reading, that is the way to go. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"

May 10, 2016

Bug in meta tag refresh code [with cause]

by eocene＠gmx.com

On Tue, May 10, 2016 at 10:38:57AM -0300, Jorge Arellano Cid wrote: > Yes. This stems from two reasons: the meta-refresh element has no > defined standard, and our code has evolved accomodating to work > with what we've found along the way. They do have refresh in html5: https://www.w3.org/TR/html51/document-metadata.html#statedef-http-equiv-ref…

May 10, 2016