- Dillo-dev - lists.mailman3.com

Fixed a mistake in the CSS-box-model PNG image (style-box-model.png).

by jcid＠dillo.org

Hi, I just committed this fix. The wrong documentation image mislead me a lot while working on the redraw problems. Now it's accurate (CSS box model in namespacedw_1_1core_1_1style.html). -- Cheers Jorge.-

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 02:15:39PM +0000, I wrote: > Dillo has been neglecting its valgrind cleanliness recently and it > turns out the culprit is dw::Table, ... Oops, I missed one! Here's a followup patch for consistency. Jeremy Henty

March 2, 2008

dw::Table valgrind-friendliness

by jcid＠dillo.org

On Sun, Mar 02, 2008 at 02:15:39PM +0000, Jeremy Henty wrote: > > Dillo has been neglecting its valgrind cleanliness recently and it > turns out the culprit is dw::Table, which resizes its internal vectors > without initialising any new values that appear. If you valgrind > dillo and immediately close the splash window, valgrind reports 121 > "Conditional jump or move depends on uninitialised value" errors! > This patch reduces that number to 2! AFAIU, this patch covers the symptoms of a BUG that current CVS fixes. Please test current CVS against valgrind. -- Cheers Jorge.-

March 2, 2008

dw::Table valgrind-friendliness

by onepoint＠starurchin.org

Dillo has been neglecting its valgrind cleanliness recently and it turns out the culprit is dw::Table, which resizes its internal vectors without initialising any new values that appear. If you valgrind dillo and immediately close the splash window, valgrind reports 121 "Conditional jump or move depends on uninitialised value" errors! This patch reduces that number to 2! Regards, Jeremy Henty

March 2, 2008

a drawing segfault

by onepoint＠starurchin.org

On Sun, Mar 02, 2008 at 06:30:03AM +0000, place wrote: > I was just opening file:///tmp/, which is not normally a problem... > > *** [unknown] Assertion failed! *** > Array index out of bounds: 28 >= 28 > > Program received signal SIGABRT, Aborted. I see this occasionally too, though it seems to be sporadic. I can't figure what the trigger is. Does it happen every time you open the directory or only occasionally? Jeremy Henty

March 2, 2008

patch: multipart/form-data encoding for form submission

by jcid＠dillo.org

Hi, On Sun, Mar 02, 2008 at 01:25:28AM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 29, 2008 at 10:37:04PM +0000, place wrote: > > > > Have you tried something like?: > > > > > > > > </pseudocode> > > > > > > > > Html_submit_form2() > > > > ... > > > > if (ENC_MULTIPART) { > > > > append every single "name" "value" pair into a Dstr > > > > do { > > > > make boundary > > > > } while (strstr(Dstr, boundary) || maxtries); > > > > } > > > > ... > > > > encode as usual. > > > > > > > > </pseudocode> > > I gave it a try and ended up with the attached compiles-but-hardly-tested > code. I had somehow forgotten earlier that I was going to have to use > Dlists of values due to SELECT elements. > > This runs through the inputs once for boundary creation, and > a second time for url->data creation. > > I was tempted to try > - go through once, making a Dlist of name/value pairs > - if (MULTIPART) determine a boundary, strstr()ing names and values > - give each pair in the Dlist to Html_append_input > but that's no good because I wouldn't know whether I had data from > a file input when making url->data (Content-Disposition is different). > > > Thoughts? Yes. As form-submitting is not a frequent operartion, much less with multipart, there's no compelling need to optimize it further. This version of the patch is easier to read and understand. Please comment the Html_get_input_values() function. For: > + // BUG: strstr stops at NULL. Cannot use for file inputs. > + success = !strstr(DataStr->str, boundary->str); please use memcmp(). Some basic testing would be welcomed, but the main probe will be done by usage when committed. -- Cheers Jorge.-

March 2, 2008

a drawing segfault

by jcid＠dillo.org

On Sun, Mar 02, 2008 at 06:30:03AM +0000, place wrote: > I was just opening file:///tmp/, which is not normally a problem... Yesterday I committed a patch just for this! Please check the CVS and send some feedback. -- Cheers Jorge.-

March 2, 2008

a drawing segfault

by place＠gobigwest.com

I was just opening file:///tmp/, which is not normally a problem... *** [unknown] Assertion failed! *** Array index out of bounds: 28 >= 28 Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 31812)] 0x40344c81 in kill () from /lib/libc.so.6 (gdb) bt #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0806e0ac in misc::assert (cond=false, format=0x8109030 "Array index out of bounds: %d >= %d") at ../lout/misc.hh:46 #6 0x0807ca1e in misc::SimpleVector<int>::get (this=0x81f1ff0, i=28) at ../lout/misc.hh:183 #7 0x0807b3d7 in dw::Table::draw (this=0x81b1128, view=0x8152d68, area=0xbffff414) at table.cc:242 #8 0x0807f708 in dw::Textblock::drawLine (this=0x8238228, line=0x8221594, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1364 #9 0x0807f827 in dw::Textblock::draw (this=0x8238228, view=0x8152d68, area=0xbffff4c8) at textblock.cc:1500 #10 0x0809c2aa in dw::core::Layout::draw (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.cc:402 #11 0x08096b55 in dw::core::Layout::expose (this=0x8152808, view=0x8152d68, area=0xbffff568) at layout.hh:163 #12 0x08095fc0 in dw::fltk::FltkViewBase::draw (this=0x8152d68) at fltkviewbase.cc:113 #13 0x08090c4f in dw::fltk::FltkViewport::draw_area (data=0x8152d68, ---Type <return> to continue, or q <return> to quit--- cr=@0xbffff728) at fltkviewport.cc:168 #14 0x080d7167 in fltk::scrollrect (r=@0xbffff728, dx=0, dy=2526, draw_area=0x8090c28 <dw::fltk::FltkViewport::draw_area(void*, fltk::Rectangl e const&)>, data=0x8152d68) at scrollrect.cxx:115 #15 0x08090dfe in dw::fltk::FltkViewport::draw (this=0x8152d68) at fltkviewport.cc:189 #16 0x080bbc4b in fltk::Group::update_child (this=0x8140b40, w=@0x8152d6c) at Group.cxx:769 #17 0x080bc85a in fltk::Group::draw (this=0x8140b40) at Group.cxx:697 #18 0x080bbc4b in fltk::Group::update_child (this=0x81416d0, w=@0x8140b40) at Group.cxx:769 #19 0x080bc85a in fltk::Group::draw (this=0x81416d0) at Group.cxx:697 #20 0x080d3ed0 in fltk::Window::flush (this=0x81416d0) at x11/run.cxx:2559 #21 0x080d13ac in fl_window_flush (window=0x81416d0) at run.cxx:651 #22 0x080d146c in fltk::flush () at run.cxx:685 #23 0x080d6297 in fltk::wait (time_to_wait=0) at run.cxx:480 #24 0x080d62fd in fltk::run () at run.cxx:393 #25 0x0804ef03 in main (argc=1, argv=0xbffffb44) at dillo.cc:110

March 2, 2008

patch: multipart/form-data encoding for form submission

by place＠gobigwest.com

Jorge wrote: > On Fri, Feb 29, 2008 at 10:37:04PM +0000, place wrote: > > > Have you tried something like?: > > > > > > </pseudocode> > > > > > > Html_submit_form2() > > > ... > > > if (ENC_MULTIPART) { > > > append every single "name" "value" pair into a Dstr > > > do { > > > make boundary > > > } while (strstr(Dstr, boundary) || maxtries); > > > } > > > ... > > > encode as usual. > > > > > > </pseudocode> I gave it a try and ended up with the attached compiles-but-hardly-tested code. I had somehow forgotten earlier that I was going to have to use Dlists of values due to SELECT elements. This runs through the inputs once for boundary creation, and a second time for url->data creation. I was tempted to try - go through once, making a Dlist of name/value pairs - if (MULTIPART) determine a boundary, strstr()ing names and values - give each pair in the Dlist to Html_append_input but that's no good because I wouldn't know whether I had data from a file input when making url->data (Content-Disposition is different). Thoughts?

March 2, 2008

What shall we do with the buggy RFC?

by joerg.sonnenberger＠web.de

On Sat, Mar 01, 2008 at 05:15:52PM +0000, Jeremy Henty wrote: > On Sat, Mar 01, 2008 at 05:16:13PM +0100, Joerg Sonnenberger wrote: > > On Sat, Mar 01, 2008 at 03:56:35PM +0000, Jeremy Henty wrote: > > > The problem appears when resolving a relative URI reference such > > > as "?foo=bar" relative to a URI such as "http://a.b.c/e/f".i > > > > I don't think that's a valid relative URI, > > RFC 2396 disagrees. Section "C.1. Normal Examples" explicitly cites > "?y" as an example URI. That example also parses according to the > regular expression they provide: I'm interpreting the grammar for rel_segment in section 5 a bit different.. > > ... but I would threat the empty path component as ".". > > I think that would be consistent with RFC 2396 but not the earlier RFC > 1808. As I said elsewhere I think RFC 1808 is clearly right on this > point and I'm puzzled that RFC 2396 does not explain or even mention > the change. I read step 5 different. If the embedded URL path is empty, it inherits the base URL. That is what RFC 1808 says and what is consistent with interpreting it as ".". Joerg

March 1, 2008