- Dillo-dev - lists.mailman3.com

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 15, 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

Bug in meta tag refresh code [with cause]

by jcid＠dillo.org

On Tue, May 10, 2016 at 08:59:49AM +0200, Johannes Hofmann wrote: > On Mon, May 02, 2016 at 09:59:09PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > > > > I have two pages you can test on - one with the proper meta tag, and one > > > with out: > > > > > > http://irpi.linicks.net:8080/static_simple.html <- good > > > > > > http://fishpi.linicks.net:8081/static_simple.html <- bad - that shows the > > > bug > > > > > > If possible view both with that printf I put in - you can see what mr_url > > > returns. > > > > Please try to be clear & concise. > > > > There's a bug, yes. You may try this: > > > > diff -r c20e74568504 src/html.cc > > --- a/src/html.cc Sun May 01 10:49:17 2016 -0300 > > +++ b/src/html.cc Sun May 01 23:26:48 2016 -0300 > > @@ -3220,6 +3220,8 @@ static void Html_tag_open_meta(DilloHtml > > content = p + strlen("url="); > > else if ((p = strstr(content, ";"))) > > content = p + strlen(";"); > > + else > > + content = ""; > > /* Handle the case of a quoted URL */ > > if (*content == '"' || *content == '\'') { > > if ((p = strchr(content + 1, *content))) > > > > > > @Johannes, does it look OK to you? > > Looks ok to me, but the whole code there is a bit hairy. 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. Do you have a testcase battery for meta refresh? Currently, I'm working on the BODY and HTML element handling by the parser (special cases since their implicit optional-magic open and close). Fortunately I have the test cases for BODY and HTML. I also found my old set for META refresh, but I don't have the case you made the last patch for. It would be great to consolidate them. -- Cheers Jorge.-

May 10, 2016

Bug in meta tag refresh code [with cause]

by johannes.hofmann＠gmx.de

On Mon, May 02, 2016 at 09:59:09PM -0300, Jorge Arellano Cid wrote: > Hi, > > On Sun, May 01, 2016 at 04:06:51PM +0100, Nick Warne wrote: > > I have been looking at this for about 5 hours now, and it has fried my > > brain. > > > > Reading the code, and then reading the email thread about depreciated meta > > tag 'refresh', I agree with Dillo's actions. > > > > But what I found was that on some sites (mine included), if there was a tag: > > > > <meta http-equiv="refresh" content="15" /> > > > > Dillo reports and the warning message reports: > > > > The author wanted you to go _here_ after 10 seconds. > > > > What happens now is the link (_here_) gets appended with the refresh value, > > so for example: > > > > www.example.com/refesh.html > > > > becomes: > > > > www.example.com/10 (or 15 or whatever the refresh value is). > > > > I have found that if the meta tag is right: > > > > <meta http-equiv="refresh" content="5;URL='./index.html'" /> > > > > then the code creates the right URL (but it's not seen as no warning is > > given. > > > > html.cc from line 3218 > > > > if the meta tag refresh is correct HTML on the web page, mr_url returns the > > correct path to the refresh. If it isn't, then mr_url returns the value of > > the refresh - which fubars the warning messages link. > > > > I tested this running dillo from the commandline with this insertion and > > testing the correct and wrong meta tags: > > > > } > > /* Skip to anything after "URL=" or ";" if "URL=" is not found */ > > if ((p = dStriAsciiStr(content, "url="))) > > content = p + strlen("url="); > > else if ((p = strstr(content, ";"))) > > content = p + strlen(";"); > > /* Handle the case of a quoted URL */ > > if (*content == '"' || *content == '\'') { > > if ((p = strchr(content + 1, *content))) > > mr_url = dStrndup(content + 1, p - content - 1); > > else > > mr_url = dStrdup(content + 1); > > } else { > > mr_url = dStrdup(content); > > } > > //nick > > printf ("%s\n", mr_url); > > new_url = a_Html_url_new(html, mr_url, NULL, 0); > > // new_url = a_Html_url_new(html, ".", NULL, 0); > > > > > > Not being very good with C++, I can't work out what goes wrong here - but it > > looks like that if 'URL=' or';' isn't found, then the code still looks for > > quotes - which does something to the string? > > > > I have two pages you can test on - one with the proper meta tag, and one > > with out: > > > > http://irpi.linicks.net:8080/static_simple.html <- good > > > > http://fishpi.linicks.net:8081/static_simple.html <- bad - that shows the > > bug > > > > If possible view both with that printf I put in - you can see what mr_url > > returns. > > Please try to be clear & concise. > > There's a bug, yes. You may try this: > > diff -r c20e74568504 src/html.cc > --- a/src/html.cc Sun May 01 10:49:17 2016 -0300 > +++ b/src/html.cc Sun May 01 23:26:48 2016 -0300 > @@ -3220,6 +3220,8 @@ static void Html_tag_open_meta(DilloHtml > content = p + strlen("url="); > else if ((p = strstr(content, ";"))) > content = p + strlen(";"); > + else > + content = ""; > /* Handle the case of a quoted URL */ > if (*content == '"' || *content == '\'') { > if ((p = strchr(content + 1, *content))) > > > @Johannes, does it look OK to you? Looks ok to me, but the whole code there is a bit hairy. Cheers, Johannes

May 10, 2016

image overlaps text

by sgeerken＠dillo.org

Hi Alexander and others, On Mo, Mai 09, 2016, Alexander Voigt wrote: > Dear Sebastian, > > I think one of your recent commits (probably 4543:3cb86de1861a) > introduced a problem with hyphenation. See for example the rendering > of > > debian.org This commit fixes a problem which has hidden another problem which now shows up. I'm working on it. If you want a halfway usable recent version, stick to revision 4542. Sebastian

May 9, 2016

Bug in meta tag refresh code [with cause]

by nick＠linicks.net

On 03/05/16 01:59, Jorge Arellano Cid wrote: > Please try to be clear & concise. I thought I was :) > There's a bug, yes. You may try this: > > diff -r c20e74568504 src/html.cc > --- a/src/html.cc Sun May 01 10:49:17 2016 -0300 > +++ b/src/html.cc Sun May 01 23:26:48 2016 -0300 > @@ -3220,6 +3220,8 @@ static void Html_tag_open_meta(DilloHtml > content = p + strlen("url="); > else if ((p = strstr(content, ";"))) > content = p + strlen(";"); > + else > + content = ""; > /* Handle the case of a quoted URL */ > if (*content == '"' || *content == '\'') { > if ((p = strchr(content + 1, *content))) > > > @Johannes, does it look OK to you? OK, that doesn't quite work correctly - it removes the warning messages altogether. Using: content = "./"; produces the warning message and with the top level URL - but, a case like this: www.example.com/refresh.html should produce a refresh to that URL, but it drops the page and points to www.example.com/ Nearly there... 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 3, 2016