- Dillo-dev - lists.mailman3.com

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

problems with very long alt text

by jcid＠dillo.org

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

Aug. 26, 2011

margin-bottom counted twice

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 10:20:43AM +0200, Johannes Hofmann wrote: > Hi, > > I found that current dillo uses twice the given > margin-bottom: value. See attached margin_bottom.html. > It is related to commented out code in textblock.cc. > Attached patch tries to fix it while not breaking the test cases in > http://www.dillo.org/test/img/ > 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? AFAIR there was the "line1" offset stuff (which seem not to apply here because it's horizontal), and the handOverBreak() code which dealt with spacing between textblocks. I'm for applying the patch, but would give first a second look to handOverBreak() just to be sure. BTW, after a quick review it looks weird, as the value seems inherited (copied from previous stack object) most of the time... -- Cheers Jorge.-

Aug. 26, 2011

margin-bottom counted twice

by corvid＠lavabit.com

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?).

Aug. 26, 2011

problems with very long alt text

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 12:47:24PM -0300, Jorge Arellano Cid wrote: > On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote: > > > try booting with the 'i915.modeset=0' kernel parameter? > > It made no difference :-P Actually it made a difference. I can't change the resolution without the kernel argument. Thanks. BTW, although my custom xorg.conf says: Section "Device" Identifier "Card0" Driver "vesa" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 16 Modes "800x600" "1024x768" EndSubSection EndSection ... lsmod shows i915 is loaded. -- Cheers Jorge.-

Aug. 26, 2011

problems with very long alt text

by johannes.hofmann＠gmx.de

On Fri, Aug 26, 2011 at 12:47:24PM -0300, Jorge Arellano Cid wrote: > On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote: > > Jorge Arellano Cid (2011-08-26 09:34): > > > I can't get this Debian to go VESA. Hints welcomed. > > > > Perhaps make sure that you have the 'xserver-xorg-video-vesa' package > > It is there. > > > and > > try booting with the 'i915.modeset=0' kernel parameter? > > It made no difference :-P > > > But probably it is > > more stubborn than that, e.g. only the i915 driver knows how to initialize > > enough video RAM for the native resolution. > > I have a "Tiny Core" linux live CD that works without the intel > driver (AFAICT). No native resolution though. > > > > In such a case running > > `X -depth 8` could work, but delving any deeper is probably not worth the > > trouble. > > This gave me an idea, and guess what, if I run with the same > kernel/intel-driver that crashes but with a different resolution > (1024x768) there's no crash. > > Now, if VESA can't do the native resolution, I don't know how > to get closer to a proof of a bug in the i915 driver. Maybe with http://sourceforge.net/projects/xtrace/ you can determine the problematic X11 request. I can't reproduce the crash btw. Cheers, Johannes

Aug. 26, 2011

problems with very long alt text

by jcid＠dillo.org

On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote: > Jorge Arellano Cid (2011-08-26 09:34): > > I can't get this Debian to go VESA. Hints welcomed. > > Perhaps make sure that you have the 'xserver-xorg-video-vesa' package It is there. > and > try booting with the 'i915.modeset=0' kernel parameter? It made no difference :-P > But probably it is > more stubborn than that, e.g. only the i915 driver knows how to initialize > enough video RAM for the native resolution. I have a "Tiny Core" linux live CD that works without the intel driver (AFAICT). No native resolution though. > In such a case running > `X -depth 8` could work, but delving any deeper is probably not worth the > trouble. This gave me an idea, and guess what, if I run with the same kernel/intel-driver that crashes but with a different resolution (1024x768) there's no crash. Now, if VESA can't do the native resolution, I don't know how to get closer to a proof of a bug in the i915 driver. -- Cheers Jorge.-

Aug. 26, 2011

problems with very long alt text

by rogutes＠googlemail.com

Jorge Arellano Cid (2011-08-26 09:34): > I can't get this Debian to go VESA. Hints welcomed. Perhaps make sure that you have the 'xserver-xorg-video-vesa' package and try booting with the 'i915.modeset=0' kernel parameter? But probably it is more stubborn than that, e.g. only the i915 driver knows how to initialize enough video RAM for the native resolution. In such a case running `X -depth 8` could work, but delving any deeper is probably not worth the trouble. > It looks like an intel driver bug as corvid suggested. No crashes here with dillo3-tip and the radeon driver. -- -- Rogut?s Sparnuotos

Aug. 26, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 09:12:17PM -0300, Jorge Arellano Cid wrote: > On Thu, Aug 25, 2011 at 10:53:50PM +0000, corvid wrote: > > furaisanjin wrote: > > > 2011/8/26 corvid <corvid(a)lavabit.com>: > > > > I just tried running from my older slackware-13.1 partition and there > > > > was no memory-eating! > > > > > > I don't have any issue on FreeBSD 8.2. it sounds like particular linux > > > libc or kernel issue. > > > > Jorge: Do you use the Intel x.org driver as well? It is notoriously and > > chronically buggy, despite(?) being written by Intel guys, and maybe > > that's it. > > Yes! > > This notebook has it and the kernel loads "i915". Will try "vesa"... So far, it works on FreeBSD 8.2, also for corvid with vesa, and for me in another computer with ATI video, and in my same notebook with intel drivers but from linux-2.6.32.31 times. I can't get this Debian to go VESA. Hints welcomed. It looks like an intel driver bug as corvid suggested. -- Cheers Jorge.-

Aug. 26, 2011

margin-bottom counted twice

by johannes.hofmann＠gmx.de

Hi, I found that current dillo uses twice the given margin-bottom: value. See attached margin_bottom.html. It is related to commented out code in textblock.cc. Attached patch tries to fix it while not breaking the test cases in http://www.dillo.org/test/img/ 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? Cheers, Johannes

Aug. 26, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 10:53:50PM +0000, corvid wrote: > furaisanjin wrote: > > 2011/8/26 corvid <corvid(a)lavabit.com>: > > > I just tried running from my older slackware-13.1 partition and there > > > was no memory-eating! > > > > I don't have any issue on FreeBSD 8.2. it sounds like particular linux > > libc or kernel issue. > > Jorge: Do you use the Intel x.org driver as well? It is notoriously and > chronically buggy, despite(?) being written by Intel guys, and maybe > that's it. Yes! This notebook has it and the kernel loads "i915". Will try "vesa"... -- Cheers Jorge.-

Aug. 26, 2011

problems with very long alt text

by corvid＠lavabit.com

I wrote: > furaisanjin wrote: > > 2011/8/26 corvid <corvid(a)lavabit.com>: > > > I just tried running from my older slackware-13.1 partition and there > > > was no memory-eating! > > > > I don't have any issue on FreeBSD 8.2. it sounds like particular linux > > libc or kernel issue. > > Jorge: Do you use the Intel x.org driver as well? It is notoriously and > chronically buggy, despite(?) being written by Intel guys, and maybe > that's it. Tried the vesa driver, and dillo worked happily.

Aug. 26, 2011

problems with very long alt text

by corvid＠lavabit.com

furaisanjin wrote: > 2011/8/26 corvid <corvid(a)lavabit.com>: > > I just tried running from my older slackware-13.1 partition and there > > was no memory-eating! > > I don't have any issue on FreeBSD 8.2. it sounds like particular linux > libc or kernel issue. Jorge: Do you use the Intel x.org driver as well? It is notoriously and chronically buggy, despite(?) being written by Intel guys, and maybe that's it.

Aug. 26, 2011

problems with very long alt text

by furaisanjin＠gmail.com

2011/8/26 corvid <corvid(a)lavabit.com>: > I just tried running from my older slackware-13.1 partition and there > was no memory-eating! I don't have any issue on FreeBSD 8.2. it sounds like particular linux libc or kernel issue.

Aug. 26, 2011

problems with very long alt text

by corvid＠lavabit.com

Johannes wrote: > On Thu, Aug 25, 2011 at 08:03:05PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote: > > > > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > > > > > Jorge wrote: > > > > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > > > > > > > > > With remote stylesheets off and images off, opening > > > > > > > http://www.dillo.org/test/long_alt_text.html > > > > > > > and dragging the horizontal scrollbar left and right > > > > > > > for a little while will make my machine suddenly start > > > > > > > to page madly. > > > > > > > > > > > > Whoooooohooooo! > > > > > > > > > > > > Good catch: I got an instantaneous X server crash here. > > > > > > > > > > > > Will look into it. > > > > > > > > > > With XFT disabled, this page doesn't give me any memory difficulties. > > > > > > > > *it surprises me* > > > > > > > > I've found this: > > > > > > > > * fl_width() returns OK when called by FltkPlatform::textWidth() > > > > * dillo-2.2.1 also crashes my X server. > > > > > > > > With this little data I tend to think there's a bug in Dillo. > > > > Maybe a huge allocation request... > > > > > > * There's no need to disable CSS nor images here to have a > > > crash. > > > > > > To discard an utf8 kill-sequence, I changed the testcase into a > > > 1106 'a' character repetition (attached). After applying the > > > attached debug-patch, it crashes consistently [1] with max_c=734 > > > but not with max_c=733. I see the expected memory usage with > > > max_c=733 . > > > > > > Is this also true in your machine? > > > > With 733, I scroll back and forth, and mem used in the Mem line in > > top goes up, up, up, while nothing out of the ordinary happens to dillo > > or X, and the paging begins, and it takes a minute or so to notice the > > ctrl-Q. A MSG() in drawSimpleWrappedText() says "width 5864 height 17", > > which adds to the evidence that it may not be a 16-bit overflow. > > > > 733 vs 734 makes no difference for me. > > Maybe it has to do with MAXBUF in fl_draw.cxx? I just tried running from my older slackware-13.1 partition and there was no memory-eating! Same dillo, same fltk, but older kernel and libs. (It still wraps my original example onto four lines instead of looking nice, but I believe I did see something one day in fltk's wrapping that breaks at ~1k bytes or glyphs or something.)

Aug. 25, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 08:03:05PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote: > > > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > > > > > > > With remote stylesheets off and images off, opening > > > > > > http://www.dillo.org/test/long_alt_text.html > > > > > > and dragging the horizontal scrollbar left and right > > > > > > for a little while will make my machine suddenly start > > > > > > to page madly. > > > > > > > > > > Whoooooohooooo! > > > > > > > > > > Good catch: I got an instantaneous X server crash here. > > > > > > > > > > Will look into it. > > > > > > > > With XFT disabled, this page doesn't give me any memory difficulties. > > > > > > *it surprises me* > > > > > > I've found this: > > > > > > * fl_width() returns OK when called by FltkPlatform::textWidth() > > > * dillo-2.2.1 also crashes my X server. > > > > > > With this little data I tend to think there's a bug in Dillo. > > > Maybe a huge allocation request... > > > > * There's no need to disable CSS nor images here to have a > > crash. > > > > To discard an utf8 kill-sequence, I changed the testcase into a > > 1106 'a' character repetition (attached). After applying the > > attached debug-patch, it crashes consistently [1] with max_c=734 > > but not with max_c=733. I see the expected memory usage with > > max_c=733 . > > > > Is this also true in your machine? > > With 733, I scroll back and forth, and mem used in the Mem line in > top goes up, up, up, while nothing out of the ordinary happens to dillo > or X, and the paging begins, and it takes a minute or so to notice the > ctrl-Q. Here memory keeps frozen while scrolling back and forth. > A MSG() in drawSimpleWrappedText() says "width 5864 height 17", > which adds to the evidence that it may not be a 16-bit overflow. > > 733 vs 734 makes no difference for me. Here, 733 has altTextWidht=8063 // works OK 734 has altTextWidht=8074 // crashes -- Cheers Jorge.-

Aug. 25, 2011

problems with very long alt text

by Johannes.Hofmann＠gmx.de

On Thu, Aug 25, 2011 at 08:03:05PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote: > > > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > > > > > > > With remote stylesheets off and images off, opening > > > > > > http://www.dillo.org/test/long_alt_text.html > > > > > > and dragging the horizontal scrollbar left and right > > > > > > for a little while will make my machine suddenly start > > > > > > to page madly. > > > > > > > > > > Whoooooohooooo! > > > > > > > > > > Good catch: I got an instantaneous X server crash here. > > > > > > > > > > Will look into it. > > > > > > > > With XFT disabled, this page doesn't give me any memory difficulties. > > > > > > *it surprises me* > > > > > > I've found this: > > > > > > * fl_width() returns OK when called by FltkPlatform::textWidth() > > > * dillo-2.2.1 also crashes my X server. > > > > > > With this little data I tend to think there's a bug in Dillo. > > > Maybe a huge allocation request... > > > > * There's no need to disable CSS nor images here to have a > > crash. > > > > To discard an utf8 kill-sequence, I changed the testcase into a > > 1106 'a' character repetition (attached). After applying the > > attached debug-patch, it crashes consistently [1] with max_c=734 > > but not with max_c=733. I see the expected memory usage with > > max_c=733 . > > > > Is this also true in your machine? > > With 733, I scroll back and forth, and mem used in the Mem line in > top goes up, up, up, while nothing out of the ordinary happens to dillo > or X, and the paging begins, and it takes a minute or so to notice the > ctrl-Q. A MSG() in drawSimpleWrappedText() says "width 5864 height 17", > which adds to the evidence that it may not be a 16-bit overflow. > > 733 vs 734 makes no difference for me. Maybe it has to do with MAXBUF in fl_draw.cxx?

Aug. 25, 2011

problems with very long alt text

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote: > > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > > > > > With remote stylesheets off and images off, opening > > > > > http://www.dillo.org/test/long_alt_text.html > > > > > and dragging the horizontal scrollbar left and right > > > > > for a little while will make my machine suddenly start > > > > > to page madly. > > > > > > > > Whoooooohooooo! > > > > > > > > Good catch: I got an instantaneous X server crash here. > > > > > > > > Will look into it. > > > > > > With XFT disabled, this page doesn't give me any memory difficulties. > > > > *it surprises me* > > > > I've found this: > > > > * fl_width() returns OK when called by FltkPlatform::textWidth() > > * dillo-2.2.1 also crashes my X server. > > > > With this little data I tend to think there's a bug in Dillo. > > Maybe a huge allocation request... > > * There's no need to disable CSS nor images here to have a > crash. > > To discard an utf8 kill-sequence, I changed the testcase into a > 1106 'a' character repetition (attached). After applying the > attached debug-patch, it crashes consistently [1] with max_c=734 > but not with max_c=733. I see the expected memory usage with > max_c=733 . > > Is this also true in your machine? With 733, I scroll back and forth, and mem used in the Mem line in top goes up, up, up, while nothing out of the ordinary happens to dillo or X, and the paging begins, and it takes a minute or so to notice the ctrl-Q. A MSG() in drawSimpleWrappedText() says "width 5864 height 17", which adds to the evidence that it may not be a 16-bit overflow. 733 vs 734 makes no difference for me.

Aug. 25, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote: > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > > > With remote stylesheets off and images off, opening > > > > http://www.dillo.org/test/long_alt_text.html > > > > and dragging the horizontal scrollbar left and right > > > > for a little while will make my machine suddenly start > > > > to page madly. > > > > > > Whoooooohooooo! > > > > > > Good catch: I got an instantaneous X server crash here. > > > > > > Will look into it. > > > > With XFT disabled, this page doesn't give me any memory difficulties. > > *it surprises me* > > I've found this: > > * fl_width() returns OK when called by FltkPlatform::textWidth() > * dillo-2.2.1 also crashes my X server. > > With this little data I tend to think there's a bug in Dillo. > Maybe a huge allocation request... * There's no need to disable CSS nor images here to have a crash. To discard an utf8 kill-sequence, I changed the testcase into a 1106 'a' character repetition (attached). After applying the attached debug-patch, it crashes consistently [1] with max_c=734 but not with max_c=733. I see the expected memory usage with max_c=733 . Is this also true in your machine? *puzzled* [1] Before and after rebooting the machine. -- Cheers Jorge.-

Aug. 25, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > > > With remote stylesheets off and images off, opening > > > http://www.dillo.org/test/long_alt_text.html > > > and dragging the horizontal scrollbar left and right > > > for a little while will make my machine suddenly start > > > to page madly. > > > > Whoooooohooooo! > > > > Good catch: I got an instantaneous X server crash here. > > > > Will look into it. > > With XFT disabled, this page doesn't give me any memory difficulties. *it surprises me* I've found this: * fl_width() returns OK when called by FltkPlatform::textWidth() * dillo-2.2.1 also crashes my X server. With this little data I tend to think there's a bug in Dillo. Maybe a huge allocation request... -- Cheers Jorge.-

Aug. 25, 2011

problems with very long alt text

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > > > With remote stylesheets off and images off, opening > > http://www.dillo.org/test/long_alt_text.html > > and dragging the horizontal scrollbar left and right > > for a little while will make my machine suddenly start > > to page madly. > > Whoooooohooooo! > > Good catch: I got an instantaneous X server crash here. > > Will look into it. With XFT disabled, this page doesn't give me any memory difficulties.

Aug. 25, 2011

problems with very long alt text

by jcid＠dillo.org

On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote: > > With remote stylesheets off and images off, opening > http://www.dillo.org/test/long_alt_text.html > and dragging the horizontal scrollbar left and right > for a little while will make my machine suddenly start > to page madly. Whoooooohooooo! Good catch: I got an instantaneous X server crash here. Will look into it. -- Cheers Jorge.-

Aug. 25, 2011

problems with very long alt text

by corvid＠lavabit.com

With remote stylesheets off and images off, opening http://www.dillo.org/test/long_alt_text.html and dragging the horizontal scrollbar left and right for a little while will make my machine suddenly start to page madly. from what I could see from valgrind and top, nothing looked amiss in dillo or X, but even after dillo can finally close (if it can), too many resources are tied up somehow and I need to restart X to have a really usable system. I changed the alt text back to using drawText(), and it didn't matter much that I could see. I tried using a width of 16K instead of the 25K or so that was the real value. This didn't seem to help either.

Aug. 25, 2011

What's pending for RC2

by corvid＠lavabit.com

Jorge wrote: > BTW, at this point the Changelog has a summary of user-visible > changes, which reduces clutter given that the full history is in hg. > Please vote. > me: +1 on keeping it this way. *agrees, as you'd expect* > [ ] 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 I hadn't known about this lighter version. It's nice.

Aug. 24, 2011

What's pending for RC2

by abe＠deuxchevaux.org

Hi, On Wed, Aug 24, 2011 at 01:21:58PM -0300, Jorge Arellano Cid wrote: > Subject: What's pending for RC2 > > So far we have: [big list of ok-checks] Yay! > [ok] update the Changelog > Corvid and Johannes may have some pending items to add. > BTW, at this point the Changelog has a summary of user-visible > changes, which reduces clutter given that the full history is in hg. > Please vote. > me: +1 on keeping it this way. +1 > [ ] 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 +1 > 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? search_url="Scroogle https://ssl.scroogle.org/cgi-bin/nbbwssl.cgi?Gw=%s" Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe(a)deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe(a)noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Aug. 24, 2011

What's pending for RC2

by jcid＠dillo.org

Hi there, So far we have: [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 [ ] default search engine [ ] new-tab and window title [ ] CSS adjacent sibling selectors I'd like to comment some: [ok] tab overflow (code a handler) Please send feedback on how it works. Remember that polish and eye candy was left for the next release. [ok] update the Changelog Corvid and Johannes may have some pending items to add. BTW, at this point the Changelog has a summary of user-visible changes, which reduces clutter given that the full history is in hg. Please vote. me: +1 on keeping it this way. [ ] 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? [ ] new-tab and window title This is a simple deatail that I'll look into quickly. [ ] CSS adjacent sibling selectors Johannes has to decide on this. -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Jorge wrote: > On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > > Jorge wrote: > > > OK, current repo has a bare bones handler. It is simple and > > > easy to extend. The idea is to have something solid for the > > > release (and to polish it afterwards). > > > > > > Please test it and send feedback. > > > > It doesn't refresh well after middle-clicking to close. > > > > Also, when you open a new tab and it gets focus, the window title isn't > > updated. > > Please check current tip... It seems to be working well in general so far, but what I mean about the new tab is that I press ctrl-T and I still see the old page title.

Aug. 24, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > Jorge wrote: > > OK, current repo has a bare bones handler. It is simple and > > easy to extend. The idea is to have something solid for the > > release (and to polish it afterwards). > > > > Please test it and send feedback. > > It doesn't refresh well after middle-clicking to close. > > Also, when you open a new tab and it gets focus, the window title isn't > updated. Please check current tip... -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Tue, Aug 23, 2011 at 09:17:12PM +0000, corvid wrote: > Jorge wrote: > > OK, current repo has a bare bones handler. It is simple and > > easy to extend. The idea is to have something solid for the > > release (and to polish it afterwards). > > > > Please test it and send feedback. > > It doesn't refresh well after middle-clicking to close. > > Also, when you open a new tab and it gets focus, the window title isn't > updated. Oh, I made a stupid mistake (which I'll look for now). It worked perfectly until the last commit where making the proverbial "little change that doesn't need testing" screwed the whole thing. Sorry... -- Cheers Jorge.-

Aug. 24, 2011

Tab close button gets clobbered by tabs

by corvid＠lavabit.com

Jorge wrote: > OK, current repo has a bare bones handler. It is simple and > easy to extend. The idea is to have something solid for the > release (and to polish it afterwards). > > Please test it and send feedback. It doesn't refresh well after middle-clicking to close. Also, when you open a new tab and it gets focus, the window title isn't updated.

Aug. 23, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Sun, Aug 21, 2011 at 01:38:11PM -0300, Jorge Arellano Cid wrote: > Hi there, > > On Wed, Aug 17, 2011 at 09:44:16AM -0400, Jorge Arellano Cid wrote: > [...] > > [ ] tab overflow (code a handler) > > The idea is to have a tab overflow handler for the release. > > After sorting lots of details, the code I was making works, but > adds lots of complexity for little gain, so I decided to try a > different approach (adding all this stuff just before the > release is too dangerous). > > Fortunately the second prototype works much better and is way > simpler. > > I'll try to have it in the repo soon. If by some reason this > doesn't happen by Aug 24, the release will roll without a > polished tab overflow handler. > > > > I hope to soon have something that works enough for the > > release. In the meanwhile, the repo has had a good testing window > > so the RC dance should be short. > > Please treat current repo as release candidate 1. OK, current repo has a bare bones handler. It is simple and easy to extend. The idea is to have something solid for the release (and to polish it afterwards). Please test it and send feedback. FYI, even though eye-candy animation looked cool here I preferred to leave it out of the source tree for the release. -- Cheers Jorge.-

Aug. 23, 2011

modifier keys (Re: [Dillo-dev] Two bugs in the Dillo GUI (both Mac and ubuntu))

by corvid＠lavabit.com

I wrote: > Can anyone with windows keys verify that they don't set FL_META? > There _is_ code for: > > // For the first few years, there wasn't a good consensus on what the > // Windows keys should be mapped to for X11. So we need to help out a > // bit and map all variants to the same FLTK key... > switch (keysym) { > case XK_Meta_L: > case XK_Hyper_L: > case XK_Super_L: > keysym = FL_Meta_L; > break; > case XK_Meta_R: > case XK_Hyper_R: > case XK_Super_R: > keysym = FL_Meta_R; > break; > } > > and maybe there's something going on somewhere that I haven't noticed. > I ask because perhaps we'll want to open an STR to get FL_META set. I think I see what happens. On X (well, x.org, anyway), it apparently comes through for free as the Mod4Mask bit in XButtonEvent.state, so expecting to see the word 'meta' somewhere was no good.

Aug. 22, 2011

modifier keys (Re: [Dillo-dev] Two bugs in the Dillo GUI (both Mac and ubuntu))

by corvid＠lavabit.com

I wrote: > By the way, the only mention of FL_META in Fl_x.cxx is > > # ifdef __sgi > // get the meta key off PC keyboards: > if (fl_key_vector[18]&0x18) Fl::e_state |= FL_META; > # endif > > I'd assumed that, for FLTK under X, Meta was a synonym for Alt, > or maybe the windows keys or something (which I don't have). Can anyone with windows keys verify that they don't set FL_META? There _is_ code for: // For the first few years, there wasn't a good consensus on what the // Windows keys should be mapped to for X11. So we need to help out a // bit and map all variants to the same FLTK key... switch (keysym) { case XK_Meta_L: case XK_Hyper_L: case XK_Super_L: keysym = FL_Meta_L; break; case XK_Meta_R: case XK_Hyper_R: case XK_Super_R: keysym = FL_Meta_R; break; } and maybe there's something going on somewhere that I haven't noticed. I ask because perhaps we'll want to open an STR to get FL_META set.

Aug. 22, 2011

Two bugs in the Dillo GUI (both Mac and ubuntu)

by corvid＠lavabit.com

I wrote: > Back in June, reza wrote: > > 4. This one is more of a feature request. Like most Mac applications, the > > shortcuts should work with Command key instead of control key. (I know it's > > low priority, and I might give it a shot myself later on). > > I'm wondering whether it would be helpful to mention in keysrc that > meta = command, or would that already be known by (or at least exceedingly > obvious to) everyone using osx? By the way, the only mention of FL_META in Fl_x.cxx is # ifdef __sgi // get the meta key off PC keyboards: if (fl_key_vector[18]&0x18) Fl::e_state |= FL_META; # endif I'd assumed that, for FLTK under X, Meta was a synonym for Alt, or maybe the windows keys or something (which I don't have).

Aug. 22, 2011

Two bugs in the Dillo GUI (both Mac and ubuntu)

by corvid＠lavabit.com

Back in June, reza wrote: > 4. This one is more of a feature request. Like most Mac applications, the > shortcuts should work with Command key instead of control key. (I know it's > low priority, and I might give it a shot myself later on). I'm wondering whether it would be helpful to mention in keysrc that meta = command, or would that already be known by (or at least exceedingly obvious to) everyone using osx? BTW, 1.3 has #ifdef __APPLE__ # define FL_COMMAND FL_META ///< An alias for FL_CTRL on WIN32 and X11, or FL_META on MacOS X # define FL_CONTROL FL_CTRL ///< An alias for FL_META on WIN32 and X11, or FL_CTRL on MacOS X #else # define FL_COMMAND FL_CTRL ///< An alias for FL_CTRL on WIN32 and X11, or FL_META on MacOS X # define FL_CONTROL FL_META ///< An alias for FL_META on WIN32 and X11, or FL_CTRL on MacOS X #endif // __APPLE__ although I don't think this can do us any good in our circumstances.

Aug. 22, 2011

right_click_closes_tab

by corvid＠lavabit.com

dillorc has: # A mouse's middle click over a tab closes the Tab. # With mousewheel mouses, right click feels way better (set to YES). #right_click_closes_tab=NO I'm thinking that if the default is no and we start by talking about middle click, it would make the most sense to call it middle_click_closes_tab.

Aug. 22, 2011

Re: dillo close dialog and fluxbox on dual head

by higuita7＠yahoo.co.uk

Hi again >> if i do the same thing for all other dillo dialogs, like open >> file, search (title ask), etc , i fluxbox puts the window in the >> configured head. If i try to set the position and head, fluxbox puts the >> dialog in the right position, but in the wrong head. >How are you instructing fluxbox to do this? I can edit the ~/.fluxbox/apps and manually set things, or, a lot easier, right click on the dialog titlebar, select remember->head and save on close... and move it to the place where it should popup later and close the dialog. it will set the apps file with the correct data >Does xprop show any interesting differences between a choice5 window >and an ask window? Not really, the only difference is the *_name value, set to the respective title name. thanks 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

Aug. 22, 2011

http://mobile.wikipedia.org/

by rogerx.oss＠gmail.com

> On Sun, Aug 21, 2011 at 09:05:56PM +0000, corvid wrote: >Roger wrote: >> The following XML website seems to have problems within Dillo-fltk1.3: >> >> http://mobile.wikipedia.org/ > >The server sends it as "text/vnd.wap.wml". > >Using a firefox User-Agent header, I get ordinary html. > >If I just change the Accept header to show that I only want text/html, >text/plain, text/css, it...still sends me text/vnd.wap.wml. *sigh* > >(Sometimes everything about the web seems so screwed up in general that >I wonder what historical precedents there might be.) Ditto. -- Roger http://rogerx.freeshell.org/

Aug. 22, 2011

http://mobile.wikipedia.org/

by corvid＠lavabit.com

Roger wrote: > The following XML website seems to have problems within Dillo-fltk1.3: > > http://mobile.wikipedia.org/ The server sends it as "text/vnd.wap.wml". Using a firefox User-Agent header, I get ordinary html. If I just change the Accept header to show that I only want text/html, text/plain, text/css, it...still sends me text/vnd.wap.wml. *sigh* (Sometimes everything about the web seems so screwed up in general that I wonder what historical precedents there might be.)

Aug. 21, 2011

ping?

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 19, 2011 at 03:23:58AM +0100, higuita wrote: > > > > ping? > > > > i can see my post and corvid replies in the archives, but i got neither > > of then in my email... is there some problem with the list? > > I received all the archived emails. Probably not a problem > in dillo-dev. In the archive, I see a msg that Roger wrote earlier today that I haven't received.

Aug. 21, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

Hi there, On Wed, Aug 17, 2011 at 09:44:16AM -0400, Jorge Arellano Cid wrote: > On Wed, Aug 10, 2011 at 05:31:38PM -0400, Jorge Arellano Cid wrote: > > On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > > > Rob wrote: > > > > 2) From a practical standpoint, the old tabs seemed to behave a little > > > > nicer, in that they would adjust their size a little bit to show more > > > > of the title of the page opened in it. As it stands with Dillo 3, you > > > > can't see much of the title text before it gets an ellipsis. > > > > > > I, too, would prefer titles that were not so short and that didn't have > > > their descenders clipped. > > > > The attached code does this. I don't have much time now, so > > please give it a look. > > > > Maybe the main point is to decide how to code tab-overflow > > handling in a practical way (and to avoid complex code on the > > details/preferences, but having a few ;). > > Well, I haven't had much time these days, but gave it a try > anyway; Wow, this is full of details! [ ] tab overflow (code a handler) The idea is to have a tab overflow handler for the release. After sorting lots of details, the code I was making works, but adds lots of complexity for little gain, so I decided to try a different approach (adding all this stuff just before the release is too dangerous). Fortunately the second prototype works much better and is way simpler. I'll try to have it in the repo soon. If by some reason this doesn't happen by Aug 24, the release will roll without a polished tab overflow handler. > I hope to soon have something that works enough for the > release. In the meanwhile, the repo has had a good testing window > so the RC dance should be short. Please treat current repo as release candidate 1. -- Cheers Jorge.-

Aug. 21, 2011

http://mobile.wikipedia.org/

by rogerx.oss＠gmail.com

The following XML website seems to have problems within Dillo-fltk1.3: http://mobile.wikipedia.org/ -- Roger http://rogerx.freeshell.org/

Aug. 21, 2011

Re: Dillo Hangs

by jcid＠dillo.org

Hi, On Fri, Aug 19, 2011 at 10:36:36AM +0800, Pedro Caliente wrote: > Gretings, > > I am a long time user of Dillo and have recently given a donation. Thanks! It's always good to know people appreciate the project. > I seem to have a small problem with Dillo-2.2.1 and I m not sure if this > is the right place to report since I cannot find a contact link on your > home page. The best place to ask is dillo-dev (our mailing list), you only have to subscribe and you're set. Contacting me is suboptimal because: * my spam filter will seldom allow a new address (agressive filter for a web-published address for more than 10 years). * dillo-dev concentrates all the developers, i.e. not only my knowledge. BTW, I'm CC'ing this to dillo-dev, and wrote the reasons partly as a reminder to myself for adding a "contact" page (instead of just "Security contact"). > Well this is the problem and I encounter it for the first time with > Dillo. > > Dillo-2.2.1 browser occasionally hangs X. Have not yet found why and > when. Hangs X meaning mouse and KB working, however,? clicking > on dillo or trying to change work-place nothing happens. > > To get out of it: Ctrl-Alt-F2, login as root, kill pid of dillo, logout, > Alt-F7 back in X and all works well again. > > Just thought to let you know. Thanks for the report. 1.- Are you running dillo as root? (otherwise, loging into the user account should be enough to kill dillo). 2.- What happens if you just: Ctrl-Alt-F2, login as root, logout, Alt-F7 back in X (does it "fix" the problem?) 3.- Does it happen with dillo-3.0-pre? 4.- What OS/window-manager/FLTK2 version are you using? -- Cheers Jorge.-

Aug. 19, 2011

ping?

by jcid＠dillo.org

On Fri, Aug 19, 2011 at 03:23:58AM +0100, higuita wrote: > > ping? > > i can see my post and corvid replies in the archives, but i got neither > of then in my email... is there some problem with the list? I received all the archived emails. Probably not a problem in dillo-dev. PS: CC'ed this to your address too. -- Cheers Jorge.-

Aug. 19, 2011

ping?

by higuita7＠yahoo.co.uk

ping? i can see my post and corvid replies in the archives, but i got neither of then in my email... is there some problem with the list? thanks 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

Aug. 19, 2011

Tab close button gets clobbered by tabs

by jcid＠dillo.org

On Wed, Aug 10, 2011 at 05:31:38PM -0400, Jorge Arellano Cid wrote: > On Tue, Aug 09, 2011 at 01:42:57AM +0000, corvid wrote: > > Rob wrote: > > > 2) From a practical standpoint, the old tabs seemed to behave a little > > > nicer, in that they would adjust their size a little bit to show more > > > of the title of the page opened in it. As it stands with Dillo 3, you > > > can't see much of the title text before it gets an ellipsis. > > > > I, too, would prefer titles that were not so short and that didn't have > > their descenders clipped. > > The attached code does this. I don't have much time now, so > please give it a look. > > Maybe the main point is to decide how to code tab-overflow > handling in a practical way (and to avoid complex code on the > details/preferences, but having a few ;). Well, I haven't had much time these days, but gave it a try anyway; Wow, this is full of details! I hope to soon have something that works enough for the release. In the meanwhile, the repo has had a good testing window so the RC dance should be short. -- Cheers Jorge.-

Aug. 17, 2011