- Dillo-dev - lists.mailman3.com

dillo-3.0-rc2 is out

by jcid＠dillo.org

Hi there, After: [ok] moveToWidget(). Jorge has code for this. [ok] downloads dpi string escaping. [ok] alt text wrapping (which looks like a nice feature). [ok] remove large panel. [ok] https dialog storm (BUG#868). [ok] The findbar input doesn't know about Ctrl+{a,e,d,k}. [ok] something other than "ctab%d" for initial tab label. [ok] single close tab button with tooltip. [ok] valgrind logs: close window [ok] valgrind logs: cancel expected url [ok] segfault with Ctrl-s (web search) [ok] UI_TEMPORARILY_SHOW_PANELS [ok] leave link into a native FLTK widget [ok] remove pointeronlink(), panelmode_cb_i() [ok] the panel problems when resizing from very small. [ok] resize problems when tabs overflow [ok] URL_ILLEGAL_CHARS [ok] Fixed CustLightButton "light" color deactivation. [ok] hoverTooltip glitch (tooltip linger when going into a child DIV). [ok] tab overflow (code a handler) [ok] valgrind error for first tab close, then resize(). [ok] update the Changelog [ok] default search engine [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ok] margin-bottom + some margin collapse [ok] fix doctree leak Today the rc2 was packaged. Please get it here: http://dillo.org/download/dillo-3.0-pre.tar.bz2 // tarball http://dillo.org/download/dillo-3.0-pre.tar.bz2.asc // signature The idea is to test the package in different OS/HW-Platforms and to report how the build process went, and how it works. Hopefully it'll become dillo-3.0. Afterall, it has been for a long enough time in testing phase. TIA for your feedback. -- Last but not the least: [ok] valgrind logs: cancel expected url I can't reproduce this anymore (after the committed fix). If somebody can still reproduce it, please report it. Details are in this thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-August/008810.html (the "expected url" is the one you've asked for but whose data bytes haven't started to arrive. If during this period of time you stop the request --e.g. by pressing Stop or clicking another URL, it's cancelled--). -- Cheers Jorge.-

Aug. 29, 2011

valgrind still unhappy despite expect changes

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > > > No valgrind error report before or after these debug messages: > > > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > > Dillo: normal exit! > > > > > > I tested by pushing a remote URL on CLI and closing the window > > > before the page data starts flowing (i.e. to cancel the > > > "expect"), and also with the cancelled download code path. > > > Neither one produced an error. > > > > I saw that there was another log entry the other day > > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > > > Do you think something sneaky could be going on, or does it seem > > like it must come down to configuration differences somehow? > > AFAIS, either one is possible... > > Me not being able to reproduce it says it's most probably be OK > for the codepaths I tested (FWIW, the ones I can see). If there's > an untested codepath, well... > > OTOH, valgrind produces some false positives (its docs say it) > and gcc optimization can also play a role... > > So, I'd try to find a simple test case that produces the log. > Then, test this problematic codepath here, and see what comes out > of the exercise. > > Can you reproduce the bug? Do you have a simple test case? No. I haven't really scrutinized the code at all. I've tried a little "I wonder whether this could do it" just from looking at the traces supplied by valgrind, but without hitting upon the trick.

Aug. 29, 2011

valgrind still unhappy despite expect changes

by jcid＠dillo.org

On Sun, Aug 28, 2011 at 06:53:54PM +0000, corvid wrote: > > I can't reproduce this with valgrind-3.6.1 on wheezy. > > > > No valgrind error report before or after these debug messages: > > > > a_Nav_cancel_expect_if_eq:: calling a_Nav_cancel_expect > > Dillo: normal exit! > > > > I tested by pushing a remote URL on CLI and closing the window > > before the page data starts flowing (i.e. to cancel the > > "expect"), and also with the cancelled download code path. > > Neither one produced an error. > > I saw that there was another log entry the other day > http://starurchin.org/dillo/valgrind/7ea9fc809376ddf7dde2908e2ecf999aea2741… > > Do you think something sneaky could be going on, or does it seem > like it must come down to configuration differences somehow? AFAIS, either one is possible... Me not being able to reproduce it says it's most probably be OK for the codepaths I tested (FWIW, the ones I can see). If there's an untested codepath, well... OTOH, valgrind produces some false positives (its docs say it) and gcc optimization can also play a role... So, I'd try to find a simple test case that produces the log. Then, test this problematic codepath here, and see what comes out of the exercise. Can you reproduce the bug? Do you have a simple test case? -- Cheers Jorge.-

Aug. 29, 2011

valgrind doctree leak

by Johannes.Hofmann＠gmx.de

On Sun, Aug 28, 2011 at 02:02:18AM +0000, corvid wrote: > > (from Jeremy's logs) > > ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 > ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) > ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) > ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) > ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) > ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) > ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) > ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) > ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) > ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) > ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) > ==2186== by 0x804F08A: main (dillo.cc:436) These valgrind log's are really helpful! Should be fixed now.

Aug. 28, 2011

problems with very long alt text

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 03:08:06PM -0300, Jorge Arellano Cid wrote: > On Fri, Aug 26, 2011 at 07:29:21PM +0200, hiro wrote: > > With tinycorelinux and Xorg-7.5 i915 on 1024x768 I get a completely > > garbled screen and unresponsive system, CPU ran hot and I had to > > reboot. > > I can reboot into VESA if you want. > > > [later hiro wrote:] > > Ok I don't get the bug with Xvesa, tinycorelinux' default Xserver. > > Excellent! > > This proves the point (AFAICS). > > Thank you very much. FWIW, later I also managed to run dillo nested in Xephyr (on top of the i915 xserver that crashes my notebok), and it renders without problems. -- Cheers Jorge.-

Aug. 28, 2011

valgrind doctree leak

by corvid＠lavabit.com

(from Jeremy's logs) ==2186== 928 (32 direct, 896 indirect) bytes in 1 blocks are definitely lost in loss record 815 of 958 ==2186== at 0x40275CC: operator new(unsigned int) (vg_replace_malloc.c:255) ==2186== by 0x806E258: Doctree::push() (doctree.hh:67) ==2186== by 0x806C1FC: StyleEngine::startElement(int) (styleengine.cc:93) ==2186== by 0x8076DB8: Html_process_tag(DilloHtml*, char*, int) (html.cc:3507) ==2186== by 0x8077A33: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3822) ==2186== by 0x8070543: DilloHtml::write(char*, int, int) (html.cc:552) ==2186== by 0x80775BD: Html_callback(int, _CacheClient*) (html.cc:3725) ==2186== by 0x80627AD: Cache_process_queue (cache.c:1195) ==2186== by 0x80629A2: Cache_delayed_process_queue_callback (cache.c:1260) ==2186== by 0x40C0876: Fl::wait(double) (in /usr/lib/libfltk.so.1.3) ==2186== by 0x40C0A30: Fl::run() (in /usr/lib/libfltk.so.1.3) ==2186== by 0x804F08A: main (dillo.cc:436)

Aug. 28, 2011

margin-bottom counted twice

by Johannes.Hofmann＠gmx.de

On Fri, Aug 26, 2011 at 04:48:46PM -0300, Jorge Arellano Cid wrote: > On Fri, Aug 26, 2011 at 09:43:39PM +0200, Johannes Hofmann wrote: > > On Fri, Aug 26, 2011 at 04:21:04PM +0000, corvid wrote: > > > Johannes wrote: > > > > I'm not 100% sure about removing the "if" in Textblock::wordWrap(), > > > > but why shouldn't a widget's top margin count in the first line of a > > > > paragraph? > > > > > > My first thought was that maybe it has something to do with cases like > > > > > > <div style="margin-top: 100px"> > > > <div style="margin-top: 100px"> > > > <img src="http://www.dillo.org/wearlab.png" style="margin-top: 100px"> > > > </div> > > > </div> > > > > > > where I was thinking those were all supposed to collapse. I haven't looked > > > into the spec at all yet, but we get a total of 300px on dillo, and firefox > > > has the divs collapse and the img margin is separate (maybe a block/inline > > > distinction?). > > > > seems so. changing it to > > <img src="http://www.dillo.org/wearlab.png" style="display: block; margin-top: 100px"> > > causes firefox to also collapse the img margin. > > I have margin collapsing also on my list. > > And on the textblock side, it seems to render just as before with > the patch. > > Johannes, please decide on whether to apply it before the release. > I'll try to pack RC2 this Monday. Committed, including some margin collapsing.

Aug. 27, 2011

margin-bottom counted twice

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 09:43:39PM +0200, Johannes Hofmann wrote: > On Fri, Aug 26, 2011 at 04:21:04PM +0000, corvid wrote: > > Johannes wrote: > > > I'm not 100% sure about removing the "if" in Textblock::wordWrap(), > > > but why shouldn't a widget's top margin count in the first line of a > > > paragraph? > > > > My first thought was that maybe it has something to do with cases like > > > > <div style="margin-top: 100px"> > > <div style="margin-top: 100px"> > > <img src="http://www.dillo.org/wearlab.png" style="margin-top: 100px"> > > </div> > > </div> > > > > where I was thinking those were all supposed to collapse. I haven't looked > > into the spec at all yet, but we get a total of 300px on dillo, and firefox > > has the divs collapse and the img margin is separate (maybe a block/inline > > distinction?). > > seems so. changing it to > <img src="http://www.dillo.org/wearlab.png" style="display: block; margin-top: 100px"> > causes firefox to also collapse the img margin. > I have margin collapsing also on my list. And on the textblock side, it seems to render just as before with the patch. Johannes, please decide on whether to apply it before the release. I'll try to pack RC2 this Monday. -- Cheers Jorge.-

Aug. 26, 2011

What's pending for RC2

by jcid＠dillo.org

Hi, [ok] new-tab and window title [ok] CSS adjacent sibling selectors [ ] default search engine [ ] margin-bottom > [ ] default search engine > I've been using search_url="http://duckduckgo.com/lite/?kp=-1&q=%s" > and it works quite well for me. > Please vote. > me: +1 for making it the default > > Also I'd like to add some default search engines. For instance, > this one is very useful for me: > search_url="Free Dictionary http://www.thefreedictionary.com/%s" > Comments/suggestions? Last chance to vote... > [ ] margin-bottom In evaluation stage. -- Cheers Jorge.-

Aug. 26, 2011

margin-bottom counted twice

by Johannes.Hofmann＠gmx.de

On Fri, Aug 26, 2011 at 04:21:04PM +0000, corvid wrote: > Johannes wrote: > > I'm not 100% sure about removing the "if" in Textblock::wordWrap(), > > but why shouldn't a widget's top margin count in the first line of a > > paragraph? > > My first thought was that maybe it has something to do with cases like > > <div style="margin-top: 100px"> > <div style="margin-top: 100px"> > <img src="http://www.dillo.org/wearlab.png" style="margin-top: 100px"> > </div> > </div> > > where I was thinking those were all supposed to collapse. I haven't looked > into the spec at all yet, but we get a total of 300px on dillo, and firefox > has the divs collapse and the img margin is separate (maybe a block/inline > distinction?). seems so. changing it to <img src="http://www.dillo.org/wearlab.png" style="display: block; margin-top: 100px"> causes firefox to also collapse the img margin. I have margin collapsing also on my list.

Aug. 26, 2011