- Dillo-dev - lists.mailman3.com

CPU hog bug with https?

by sgeerken＠dillo.org

Hi Jorge, On Di, Mai 17, 2016, Jorge Arellano Cid wrote: > On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > > Hi, > > > > > > If I start current dillo with [1], an https dialog springs > > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > > answering "cancel" allows reading the page with no problems. > > > > > > FWIW, I've done that lots of times with other sites, and this is the > > > first CPU hog I get accross. > > > > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > > > I can reproduce this. However, profiling shows rather problems in the > > rendering code (dw::core::Widget::queueResize etc.), so the problem is > > probably not related to HTTPS. > > > > Also, mirroring this page ("wget -pkH") and displaying it locally > > shows the same symptoms. > > > > Looks that this belongs rather on my todo list. > > Good news on this one. > > Patch committed! Thanks for the good work! It also seems to fix the problems with netzpolitik.org and nachdenkseiten.de. (Others please check this, too.) I've one case in my list, which is already analyzed. More on this later. > I'd like to comment a bit on this bugfix for those that would like to > help making patches for dillo. You can check the patch and verbose > log with: "hg log -vp|less". > > It was hard to find, sometimes backtraces gave near 85 or more nested calls, > full of different functions. There was no CPU lock because it finally solved > the page (after more than two minutes in my machine). > > It took a few days of work, by reducing the testcase (a slashdot page) by: > * removing the scripting > * removing one stylesheet completely (no bug without CSS). > * removing sections of the HTML code > while checking the bug was still reproducible. And checking the backtrace > stack from gdb from time to time. gprof may have served also, but as there > where so many functions I decided to keep reducing the case. > > This is a trial&error iteration process. > > At some point I could clean the testcase enough to run tidy on it, and > no, it wasn't a tag soup corner case. > > Back to reducing the testcase. It started to solve in less time, but still > hogging my CPU for near 20 secs.. > > Then suddenly at some point, gdb's backtrace was still near the hundred > in depth, but a few functions remained. Studying the code in the involved > functions made me finally spot the hiding bug. Trivial to fix, but very > hard to find. > > For this case, what took more than 2 minutes to render, now takes near 1/8 > second. ;-) Yes, this is the usual way I track down bugs, too. This is much simpler for rendering bugs, which can be preserved while simplifying the page. This kind of bug is much more difficult since the effect (taking too much time) vanishes the more the simpler the page gets. Sebastian

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

I wrote: > On Wed, May 18, 2016 at 08:18:52PM +0100, Nick Warne wrote: > > AS to your question, what I don't understand is why there is a section > > for tab colours, and then later in the default theme section (which is > > active) more options for tab colour options? > > > > Perhaps move the 'stand-alone' tab colour options after the themes, so > > if the all the themes are #'ed out, these will take precedence? > > > > Or why have them at all? > > That's a good point. It looks like they evolved suboptimally. > First I was introducing color settings, and then Jorge made some > themes, and a theme became default. I'll clean it up. Hmm. I came up with something that makes it less inviting to set the individual preferences right there, but perhaps not as uninviting as I would prefer: # UI colors # Note that FLTK may sometimes override colors, generally for contrast and # readability. # # ui_fg_color, ui_main_bg_color, ui_text_bg_color, and ui_selection_color # map to concepts in the underlying FLTK toolkit which are described as: # "the default foreground color...used for labels and text", "default # background color", "the default background color for text, list, and # valuator widgets", and "the default selection/highlight color". They # sometimes have other uses in the more complex FLTK widgets. # # ui_button_highlight_color is the background used when the mouse cursor is # over a button. By default, this is a lightened version of the main # background color. # # ui_tab_active_fg_color and ui_tab_active_bg_color are used for the current # tab. By default, they are the main foreground color and the text background # color, respectively. # # ui_tab_fg_color and ui_tab_bg_color are used for the other tabs. By default, # they are the main foreground color and the main background color, # respectively. # # Note to packagers: leaving these variables for the system to guess # gives different results in different environments, so we played it safe # by defining the traditional colors. Please choose the color theme that # better fits your distro. # # Gray theme (traditional) # ...

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Wed, May 18, 2016 at 08:18:52PM +0100, Nick Warne wrote: > AS to your question, what I don't understand is why there is a section > for tab colours, and then later in the default theme section (which is > active) more options for tab colour options? > > Perhaps move the 'stand-alone' tab colour options after the themes, so > if the all the themes are #'ed out, these will take precedence? > > Or why have them at all? That's a good point. It looks like they evolved suboptimally. First I was introducing color settings, and then Jorge made some themes, and a theme became default. I'll clean it up.

May 18, 2016

New tab colours - suggestion

by nick＠linicks.net

On Wed, 18 May 2016 18:52:13 +0000 eocene <eocene at gmx.com> wrote: > > All fixed now using: > > > > ui_tab_active_bg_color=lightgrey > > ui_tab_bg_color=#808080 > > I wonder whether there'd be any value in printing a MSG complaining > when dillorc sets something more than once (search_url excepted). Actually, I am now using: ui_tab_active_fg_color=brown ui_tab_bg_color=#909090 which works great. AS to your question, what I don't understand is why there is a section for tab colours, and then later in the default theme section (which is active) more options for tab colour options? Perhaps move the 'stand-alone' tab colour options after the themes, so if the all the themes are #'ed out, these will take precedence? Or why have them at all? 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 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Wed, May 18, 2016 at 04:34:50PM +0100, Nick Warne wrote: > On Tue, 17 May 2016 19:05:34 +0000 > eocene <eocene at gmx.com> wrote: > > (Also check that > > they aren't being set again farther down in dillorc.) > > Thanks, I didn't thing of looking further down - the theme was setting > it. > > All fixed now using: > > ui_tab_active_bg_color=lightgrey > ui_tab_bg_color=#808080 I wonder whether there'd be any value in printing a MSG complaining when dillorc sets something more than once (search_url excepted).

May 18, 2016

CPU hog bug with https?

by nick＠linicks.net

On Wed, 18 May 2016 19:00:44 +0100 Nick Warne <nick at linicks.net> wrote: > On Tue, 17 May 2016 21:45:27 -0400 > Jorge Arellano Cid <jcid at dillo.org> wrote: > > > Then suddenly at some point, gdb's backtrace was still near the > > hundred in depth, but a few functions remained. Studying the code in > > the involved functions made me finally spot the hiding bug. Trivial > > to fix, but very hard to find. > > > > For this case, what took more than 2 minutes to render, now takes > > near 1/8 second. ;-) > > It is quiet amazing sometimes how a simple typo/mind mistake can take > ages to track down. > > Well down Jorge! Duh! Proves the point. Well done Jorge! 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 18, 2016

CPU hog bug with https?

by nick＠linicks.net

On Tue, 17 May 2016 21:45:27 -0400 Jorge Arellano Cid <jcid at dillo.org> wrote: > Then suddenly at some point, gdb's backtrace was still near the > hundred in depth, but a few functions remained. Studying the code in > the involved functions made me finally spot the hiding bug. Trivial > to fix, but very hard to find. > > For this case, what took more than 2 minutes to render, now takes > near 1/8 second. ;-) It is quiet amazing sometimes how a simple typo/mind mistake can take ages to track down. Well down Jorge! 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 18, 2016

New tab colours - suggestion

by nick＠linicks.net

On Tue, 17 May 2016 19:05:34 +0000 eocene <eocene at gmx.com> wrote: > On Tue, May 17, 2016 at 06:47:20PM +0100, Nick Warne wrote: > > Actually, I can't get this to work - the same bg colours do not > > change > > - the text colour does though. > > Do the tab background prefs work at all for you? Yes, they do now :) >I remember FLTK > sometimes was stubborn about colors if it felt a > foreground/background pair had too little contrast. (Also check that > they aren't being set again farther down in dillorc.) Thanks, I didn't thing of looking further down - the theme was setting it. All fixed now using: ui_tab_active_bg_color=lightgrey ui_tab_bg_color=#808080 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 18, 2016

Dillo_grows merged

by jcid＠dillo.org

On Mon, May 16, 2016 at 05:52:11PM +0200, Sebastian Geerken wrote: > 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. Much better! I still wander what a negative sectionIndex means (0 is in flow). It takes negative values sometimes. It should be commented. What should getPart() do upon a negative sectionIndex? HTH. -- Cheers Jorge.-

May 18, 2016

CPU hog bug with https?

by jcid＠dillo.org

Hi there, On Sun, May 01, 2016 at 09:58:53PM +0200, Sebastian Geerken wrote: > On So, Mai 01, 2016, Jorge Arellano Cid wrote: > > Hi, > > > > If I start current dillo with [1], an https dialog springs > > (untrusted certificate). Answering "continue" gets into a CPU hog, > > answering "cancel" allows reading the page with no problems. > > > > FWIW, I've done that lots of times with other sites, and this is the > > first CPU hog I get accross. > > > > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 > > I can reproduce this. However, profiling shows rather problems in the > rendering code (dw::core::Widget::queueResize etc.), so the problem is > probably not related to HTTPS. > > Also, mirroring this page ("wget -pkH") and displaying it locally > shows the same symptoms. > > Looks that this belongs rather on my todo list. Good news on this one. Patch committed! I'd like to comment a bit on this bugfix for those that would like to help making patches for dillo. You can check the patch and verbose log with: "hg log -vp|less". It was hard to find, sometimes backtraces gave near 85 or more nested calls, full of different functions. There was no CPU lock because it finally solved the page (after more than two minutes in my machine). It took a few days of work, by reducing the testcase (a slashdot page) by: * removing the scripting * removing one stylesheet completely (no bug without CSS). * removing sections of the HTML code while checking the bug was still reproducible. And checking the backtrace stack from gdb from time to time. gprof may have served also, but as there where so many functions I decided to keep reducing the case. This is a trial&error iteration process. At some point I could clean the testcase enough to run tidy on it, and no, it wasn't a tag soup corner case. Back to reducing the testcase. It started to solve in less time, but still hogging my CPU for near 20 secs.. Then suddenly at some point, gdb's backtrace was still near the hundred in depth, but a few functions remained. Studying the code in the involved functions made me finally spot the hiding bug. Trivial to fix, but very hard to find. For this case, what took more than 2 minutes to render, now takes near 1/8 second. ;-) -- Cheers Jorge.-

May 18, 2016

New tab colours - suggestion

by eocene＠gmx.com

On Tue, May 17, 2016 at 06:47:20PM +0100, Nick Warne wrote: > Actually, I can't get this to work - the same bg colours do not change > - the text colour does though. Do the tab background prefs work at all for you? I remember FLTK sometimes was stubborn about colors if it felt a foreground/background pair had too little contrast. (Also check that they aren't being set again farther down in dillorc.)

May 17, 2016

New tab colours - suggestion

by nick＠linicks.net

On Tue, 17 May 2016 18:37:58 +0100 Nick Warne <nick at linicks.net> wrote: > On Tue, 17 May 2016 18:26:29 +0100 > Nick Warne <nick at linicks.net> wrote: > > > I find that when opening a new tab, the colour of it changes to a > > sort of turquoise colour - which suggests it is in the background. > > > > I do find it confusing - could it be possible to change the working > > tab to the default grey and the background tabs to the turquoise > > colour? > > > > Just a suggestion. > > > > If it doesn't seem to bother anybody else, can someone point me to > > the area of code so I can do a local patch. > > Sorry, ignore the idiot - dillorc has it. Actually, I can't get this to work - the same bg colours do not change - the text colour does though. 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 17, 2016

New tab colours - suggestion

by nick＠linicks.net

On Tue, 17 May 2016 18:26:29 +0100 Nick Warne <nick at linicks.net> wrote: > I find that when opening a new tab, the colour of it changes to a sort > of turquoise colour - which suggests it is in the background. > > I do find it confusing - could it be possible to change the working > tab to the default grey and the background tabs to the turquoise > colour? > > Just a suggestion. > > If it doesn't seem to bother anybody else, can someone point me to the > area of code so I can do a local patch. Sorry, ignore the idiot - dillorc has it. Duh. 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 17, 2016

New tab colours - suggestion

by nick＠linicks.net

I find that when opening a new tab, the colour of it changes to a sort of turquoise colour - which suggests it is in the background. I do find it confusing - could it be possible to change the working tab to the default grey and the background tabs to the turquoise colour? Just a suggestion. If it doesn't seem to bother anybody else, can someone point me to the area of code so I can do a local patch. Thanks, 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 17, 2016

Dillo_grows merged

by nick＠linicks.net

On 16 May 2016 17:52:11 +0200 "Sebastian Geerken" <sgeerken at dillo.org> wrote: > > 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 Great work Guys, works well :) 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 16, 2016

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

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

"ok" for unnested body

by jcid＠dillo.org

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). 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. FYI, if you right click the bugmeter you can validate the page either with W3C or WDG (more info in the same menu). -- Cheers Jorge.-

May 3, 2016

Bug in meta tag refresh code [with cause]

by jcid＠dillo.org

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? -- Cheers Jorge.-

May 3, 2016

CPU hog bug with https?

by sgeerken＠dillo.org

On So, Mai 01, 2016, Jorge Arellano Cid wrote: > Hi, > > If I start current dillo with [1], an https dialog springs > (untrusted certificate). Answering "continue" gets into a CPU hog, > answering "cancel" allows reading the page with no problems. > > FWIW, I've done that lots of times with other sites, and this is the > first CPU hog I get accross. > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 I can reproduce this. However, profiling shows rather problems in the rendering code (dw::core::Widget::queueResize etc.), so the problem is probably not related to HTTPS. Also, mirroring this page ("wget -pkH") and displaying it locally shows the same symptoms. Looks that this belongs rather on my todo list. Sebastian

May 1, 2016

CPU hog bug with https?

by eocene＠gmx.com

On Sun, May 01, 2016 at 12:36:39PM -0300, Jorge Arellano Cid wrote: > If I start current dillo with [1], an https dialog springs > (untrusted certificate). Answering "continue" gets into a CPU hog, > answering "cancel" allows reading the page with no problems. > > FWIW, I've done that lots of times with other sites, and this is the > first CPU hog I get accross. > > > [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 I'm not getting a dialog here. What is the page pulling in that dillo is complaining about? I allowed linux.slashdot.org www.gstatic.com linux.slashdot.org analytics.slashdotmedia.com linux.slashdot.org a.fsdn.com linux.slashdot.org s3-us-west-2.amazonaws.com in domainrc, but it doesn't look like any of those are over https.

May 1, 2016

CPU hog bug with https?

by jcid＠dillo.org

Hi, If I start current dillo with [1], an https dialog springs (untrusted certificate). Answering "continue" gets into a CPU hog, answering "cancel" allows reading the page with no problems. FWIW, I've done that lots of times with other sites, and this is the first CPU hog I get accross. [1] https://linux.slashdot.org/comments.pl?sid=5852295&cid=48188823 -- Cheers Jorge.-

May 1, 2016

Bug in meta tag refresh code [with cause]

by nick＠linicks.net

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. Phew* 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 1, 2016

Minor bug in test/cookies.c

by jcid＠dillo.org

On Sun, May 01, 2016 at 11:05:27AM +0100, Nick Warne wrote: > Hi Jorge, > > I saw the two minor fixes you done today - here's another: > > :~/slackbuilds/dillo/hg/dillo$ grep -Rin "} if" * > test/cookies.c:426: } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { Right, committed, thks! -- Cheers Jorge.-

May 1, 2016

Minor bug in test/cookies.c

by nick＠linicks.net

Hi Jorge, I saw the two minor fixes you done today - here's another: :~/slackbuilds/dillo/hg/dillo$ grep -Rin "} if" * test/cookies.c:426: } if ((ret = Dpi_blocking_read(sock_fd)) == NULL) { 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 1, 2016

"ok" for unnested body

by genoob＠yandex.com

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). Cheers!

April 30, 2016

image overlaps text

by jcid＠dillo.org

On Sat, Apr 30, 2016 at 01:31:48PM +0200, Sebastian Geerken wrote: > On Fr, Apr 29, 2016, Jorge Arellano Cid wrote: > > On Fri, Apr 29, 2016 at 06:41:32PM +0200, Sebastian Geerken wrote: > > > On Fri, Apr 29, 2016, Nick Warne wrote: > > > > > > > > > > > > On 29/04/16 16:46, Alexander Voigt wrote: > > > > >I noticed, that in current Dillo (tip) there are cases where images > > > > >overlap surrounding text, making in unreadable. Here is an example page: > > > > > > > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > > > > > > > Strange, renders here OK (latest hg pull). > > > > > > As I wrote, this is hard to reproduce. > > > > Yes. > > > > (I can't reproduce it with your best URL :) > > > > Fortunately, today I managed to find&reduce a case that works all the time > > here. Attached it goes. Just resize horizontally to see the overlap. > > > > I hope it works there! > > Thanks, Jorge, for the perfect testcase. So far, I've tracked down the > problem, Great! :) :) > but I'm not yet sure how to fix it. Hopefully, the fix will > also solve the other issues with overlapping floats. Yes, I also hope in the same direction! FWIW, yesternight, without knowing whether the example would tackle it, I came with a different approach to testing (just in case). Do you remember our slow.cgi testing program? It can be made to serve adjustable chunks of data with adjustable delays, this way: slow.cgi?2048:1:/tmp/testcase.html for 2048 bytes in 1 second (for instance). This could help to reproduce the bug in the network dependent cases by finding the combination that triggers it. Just let me know if you need it as plan B. HTH. -- Cheers Jorge.-

April 30, 2016

image overlaps text

by sgeerken＠dillo.org

On Fr, Apr 29, 2016, Jorge Arellano Cid wrote: > On Fri, Apr 29, 2016 at 06:41:32PM +0200, Sebastian Geerken wrote: > > On Fri, Apr 29, 2016, Nick Warne wrote: > > > > > > > > > On 29/04/16 16:46, Alexander Voigt wrote: > > > >I noticed, that in current Dillo (tip) there are cases where images > > > >overlap surrounding text, making in unreadable. Here is an example page: > > > > > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > > > > > Strange, renders here OK (latest hg pull). > > > > As I wrote, this is hard to reproduce. > > Yes. > > (I can't reproduce it with your best URL :) > > Fortunately, today I managed to find&reduce a case that works all the time > here. Attached it goes. Just resize horizontally to see the overlap. > > I hope it works there! Thanks, Jorge, for the perfect testcase. So far, I've tracked down the problem, but I'm not yet sure how to fix it. Hopefully, the fix will also solve the other issues with overlapping floats. Sebastian

April 30, 2016

image overlaps text

by jcid＠dillo.org

On Fri, Apr 29, 2016 at 10:11:37PM +0100, higuita wrote: > On Fri, 29 Apr 2016 13:41:16 -0300, Jorge Arellano Cid <jcid at dillo.org> > wrote: > > Does going Back and Forward fix the problem? > > Yes, it solves the problem. Reload also solves this. > > For me, i can reproduce this ~70% of the attempts. > it seems just a race drawing the page and getting the resources > from the internet. That's my point. The rendering algorithm seems to make a decision on incomplete data (sometimes depending on available data) and, also sometimes, it can't recover when all data is got. Now, if you feed it the whole of the data, it seldom fails. I hope the reduced test case fails because it gets to that point in the algorithm and not because it always fails. -- Cheers Jorge.-

April 29, 2016

image overlaps text

by jcid＠dillo.org

On Fri, Apr 29, 2016 at 06:26:50PM -0300, Jorge Arellano Cid wrote: > [...] > > Fortunately, today I managed to find&reduce a case that works all the time > here. Attached it goes. Just resize horizontally to see the overlap. > > I hope it works there! Ooops, I forgot to attach the image. Here it goes. -- Cheers Jorge.-

April 29, 2016

image overlaps text

by jcid＠dillo.org

On Fri, Apr 29, 2016 at 06:41:32PM +0200, Sebastian Geerken wrote: > On Fri, Apr 29, 2016, Nick Warne wrote: > > > > > > On 29/04/16 16:46, Alexander Voigt wrote: > > >I noticed, that in current Dillo (tip) there are cases where images > > >overlap surrounding text, making in unreadable. Here is an example page: > > > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > > > Strange, renders here OK (latest hg pull). > > As I wrote, this is hard to reproduce. Yes. (I can't reproduce it with your best URL :) Fortunately, today I managed to find&reduce a case that works all the time here. Attached it goes. Just resize horizontally to see the overlap. I hope it works there! -- Cheers Jorge.- PD: subliminal message in the example. ;)

April 29, 2016

image overlaps text

by higuita7＠yahoo.co.uk

On Fri, 29 Apr 2016 13:41:16 -0300, Jorge Arellano Cid <jcid at dillo.org> wrote: > Does going Back and Forward fix the problem? Yes, it solves the problem. Reload also solves this. For me, i can reproduce this ~70% of the attempts. it seems just a race drawing the page and getting the resources from the internet. Best regards higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

April 29, 2016

dillo redraws part II

by jcid＠dillo.org

Hi there, Just committed the second part of this patch. It further reduces the number of redraws (see details in hg). The debug messages are active and will be shut after a brief testing period. Screen drawing *feels* cleaner here! :-) YMMV. -- Cheers Jorge.-

April 29, 2016

image overlaps text

by sgeerken＠dillo.org

On Fri, Apr 29, 2016, Nick Warne wrote: > > > On 29/04/16 16:46, Alexander Voigt wrote: > >I noticed, that in current Dillo (tip) there are cases where images > >overlap surrounding text, making in unreadable. Here is an example page: > > > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… > > Strange, renders here OK (latest hg pull). As I wrote, this is hard to reproduce. Sebastian

April 29, 2016

image overlaps text

by jcid＠dillo.org

Hi Alexander, On Fri, Apr 29, 2016 at 05:46:20PM +0200, Alexander Voigt wrote: > I noticed, that in current Dillo (tip) there are cases where images > overlap surrounding text, making in unreadable. Here is an example page: > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… It works here. Does going Back and Forward fix the problem? (I've noticed that several times with the old and newest dillo). -- Cheers Jorge.-

April 29, 2016

image overlaps text

by nick＠linicks.net

On 29/04/16 16:46, Alexander Voigt wrote: > I noticed, that in current Dillo (tip) there are cases where images > overlap surrounding text, making in unreadable. Here is an example page: > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… Strange, renders here OK (latest hg pull). 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"

April 29, 2016

image overlaps text

by sgeerken＠dillo.org

On Fr, Apr 29, 2016, Alexander Voigt wrote: > I noticed, that in current Dillo (tip) there are cases where images > overlap surrounding text, making in unreadable. Here is an example page: > > https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… Yes, I noticed this already several times on netzpolitik.org. Unfortunately, these cases are not always reproducable. The highest percentage I've found so far on this page: http://www.nachdenkseiten.de/?p=33180 It's at the top on my todo list. Sebastian

April 29, 2016

image overlaps text

by Hole.destructor＠gmx.de

I noticed, that in current Dillo (tip) there are cases where images overlap surrounding text, making in unreadable. Here is an example page: https://netzpolitik.org/2016/massenbeschlagnahme-von-mobiltelefonen-in-leip… Best regards, Alex

April 29, 2016