- Dillo-dev - lists.mailman3.com

AW: [Dillo-dev] patch: text-indent

by johannes.hofmann＠gmx.de

-----Urspr?ngliche Nachricht----- An: dillo-dev(a)dillo.org; Von: corvid <corvid(a)lavabit.com> Gesendet: Do 11.11.2010 02:43 Betreff: Re: [Dillo-dev] patch: text-indent > Johannes wrote: > > We probabely want some isBlockLevelWidget() function... > > Using Widget::Flags, perhaps, or would you think it best generally > to save the flags for state that changes during a widget's life? > I was just thinking about something simple like bool isBlockLevelWidget(Widget *w) { return widget->instanceOf (Textblock::CLASS_ID) || widget->instanceOf (Table::CLASS_ID) ... ); } in textblock.cc to explain to the code reader why we are testing for exactly these widget types. Plus we might have to reuse at some point. Cheers, Johannes

Nov. 17, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by onepoint＠starurchin.org

On Mon, Nov 15, 2010 at 11:01:48PM +0100, Johannes Hofmann wrote: > Should be fixed in the repo now. Thanks for tracking this down! Yes, vanilla Dillo renders my test correctly now. Thank *you* for fixing this! Regards, Jeremy Henty

Nov. 16, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by Johannes.Hofmann＠gmx.de

On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > The CssParser class has an unfortunate interaction between nextToken() > and skipString(): they are both eager to call getChar(). The result > is that when skipString() succeeds it has already getChar()-ed the > character immediately after the string to be skipped, but nextToken() > insists on calling getChar() again. This means that the character > after the skipped string is also skipped. This causes two bugs. > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > the closing '*/' is ignored (because it has already been partly > skipped over). This generally causes most or all of the style to be > ignored as the parser searches for the end of the comment. You can > see this in the wild[1]! > > Secondly, if a token starts immediately after a CSS comment, then its > first character is lost. > > The attached example shows both bugs. The first bug stops the red > style from being applied to the element, and the second bug > applies the blue style to the element instead of the <li> element. > > The quick fix is for skipString() to call ungetChar() before returning > successfully (patch attached). Luckily only nextToken() calls > skipString(). Should I push this, or is there a better way to do it? Should be fixed in the repo now. Thanks for tracking this down! Cheers, Johannes

Nov. 16, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by jcid＠dillo.org

On Sun, Nov 14, 2010 at 02:35:20PM +0100, Johannes Hofmann wrote: > Hi Jeremy, > > On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > > > The CssParser class has an unfortunate interaction between nextToken() > > and skipString(): they are both eager to call getChar(). The result > > is that when skipString() succeeds it has already getChar()-ed the > > character immediately after the string to be skipped, but nextToken() > > insists on calling getChar() again. This means that the character > > after the skipped string is also skipped. This causes two bugs. > > > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > > the closing '*/' is ignored (because it has already been partly > > skipped over). This generally causes most or all of the style to be > > ignored as the parser searches for the end of the comment. You can > > see this in the wild[1]! > > > > Secondly, if a token starts immediately after a CSS comment, then its > > first character is lost. > > > > The attached example shows both bugs. The first bug stops the red > > style from being applied to the element, and the second bug > > applies the blue style to the element instead of the <li> element. > > > > The quick fix is for skipString() to call ungetChar() before returning > > successfully (patch attached). Luckily only nextToken() calls > > skipString(). Should I push this, or is there a better way to do it? > > Let me have a deeper look at the issue. I remember that there are > some quite subtle corner cases. BTW, comments that remark hidden complexities are very valuable Even with my own code, after some time passes, I can't remember all the implementation details. ;) -- Cheers Jorge.-

Nov. 15, 2010

Dillo-Win32 patches - dillo-r1755.dns.diff

by obeythepenguin＠gmail.com

On Sun, 14 Nov 2010 09:48:40 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > On Fri, Nov 12, 2010 at 11:05:38PM +0100, Joerg Sonnenberger wrote: >> On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: >> > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, >> > and I see that the latter is posix 2001. >> >> It is relatively easy to emulate the ipv4 part of getnameinfo(), but a >> lot harder to properly support IPv6 without using it. >> >> > Do we have an official position on posix 2001? > > Regarding the use of getnameinfo(), I'd be pragmatic. It's supported > by glibc, all Free-, Net-, and OpenBSD and also Android's libc. ...not to mention Microsoft's runtime library (inet_ntop wasn't added until Windows Vista, IIRC). So pretty much a win-win, then? > The memcpy however looks like it would create a stack overflow when > used with IPv6 addresses. What about using struct sockaddr_storage > and maybe even an additional assert() to make sure it doesn't overrun? I'll trust your judgment on this one. I was more or less learning the sockets interface as I went along, so I just went with the first thing that compiled and ran. I'm sure that's not the worst piece of code in there... > The "undef D_DNS_THREADED" would be more appropriate in the WIN32 > specific section of configure. Sounds good to me. That bit was coded before the autoconf stuff, so that's my excuse for not doing it sooner. :-) > Plus I'd skip the more "correct" thing in the comment, but that's > just my personal feeling. Fine with me. That wasn't really intended to stay, anyway; I just figured there should be some justification for the change. I will try to fix that patch as soon as possible. In the meantime I'll await further feedback Cheers, ~Benjamin

Nov. 14, 2010

Dillo-Win32 patches - dillo-r1755.dns.diff

by Johannes.Hofmann＠gmx.de

On Fri, Nov 12, 2010 at 11:05:38PM +0100, Joerg Sonnenberger wrote: > On Fri, Nov 12, 2010 at 09:41:53PM +0000, corvid wrote: > > I thought I'd at least look into the inet_ntop() -> getnameinfo() bit, > > and I see that the latter is posix 2001. > > It is relatively easy to emulate the ipv4 part of getnameinfo(), but a > lot harder to properly support IPv6 without using it. > > > Do we have an official position on posix 2001? Regarding the use of getnameinfo(), I'd be pragmatic. It's supported by glibc, all Free-, Net-, and OpenBSD and also Android's libc. So I don't see a problem using it. The memcpy however looks like it would create a stack overflow when used with IPv6 addresses. What about using struct sockaddr_storage and maybe even an additional assert() to make sure it doesn't overrun? The "undef D_DNS_THREADED" would be more appropriate in the WIN32 specific section of configure. Plus I'd skip the more "correct" thing in the comment, but that's just my personal feeling. Cheers, Johannes

Nov. 14, 2010

Dillo-Win32 patches, split and ready to merge

by Johannes.Hofmann＠gmx.de

Hi Benjamin, On Thu, Nov 11, 2010 at 06:44:47PM -0500, Benjamin Johnson wrote: > Here are the split Dillo-Win32 patches, ready to merge into the > upstream tree: > http://dillo-win32.sourceforge.net/patches.html > > I've cleaned up the code somewhat, such as removing the ugly > conditionals from dsock.h. This version no longer includes the > infamous "timeout kludge"; however, it must be built against a > patched FLTK2 library, as the upstream implementation is still very > badly broken. (The necessary patch is available from the > Dillo-Win32 SourceForge site.) > > These patches produce a working ./src/dillo.exe. DPI has not yet > been ported, as I presently have neither the time nor interest to do > so. I'll probably get a binary package and installer up sometime in > the next few days for anyone who wants to play around with the > latest and greatest. > > Let me know if I need to double-check anything. Thanks for taking the time to split and cleanup your patch. This way it will be easier to digest. I think we should discuss the individual patches in separate threads. Cheers, Johannes

Nov. 14, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sun, Nov 14, 2010 at 12:28:54PM +0000, Jeremy Henty wrote: > > The CssParser class has an unfortunate interaction between nextToken() > and skipString(): they are both eager to call getChar(). The result > is that when skipString() succeeds it has already getChar()-ed the > character immediately after the string to be skipped, but nextToken() > insists on calling getChar() again. This means that the character > after the skipped string is also skipped. This causes two bugs. > > Firstly, if there is a completely empty CSS comment, ie. '/**/', then > the closing '*/' is ignored (because it has already been partly > skipped over). This generally causes most or all of the style to be > ignored as the parser searches for the end of the comment. You can > see this in the wild[1]! > > Secondly, if a token starts immediately after a CSS comment, then its > first character is lost. > > The attached example shows both bugs. The first bug stops the red > style from being applied to the element, and the second bug > applies the blue style to the element instead of the <li> element. > > The quick fix is for skipString() to call ungetChar() before returning > successfully (patch attached). Luckily only nextToken() calls > skipString(). Should I push this, or is there a better way to do it? Let me have a deeper look at the issue. I remember that there are some quite subtle corner cases. Cheers, Johannes

Nov. 14, 2010

[bug]: CssParser::{nextToken, skipString}() skip an extra character.

by onepoint＠starurchin.org

The CssParser class has an unfortunate interaction between nextToken() and skipString(): they are both eager to call getChar(). The result is that when skipString() succeeds it has already getChar()-ed the character immediately after the string to be skipped, but nextToken() insists on calling getChar() again. This means that the character after the skipped string is also skipped. This causes two bugs. Firstly, if there is a completely empty CSS comment, ie. '/**/', then the closing '*/' is ignored (because it has already been partly skipped over). This generally causes most or all of the style to be ignored as the parser searches for the end of the comment. You can see this in the wild[1]! Secondly, if a token starts immediately after a CSS comment, then its first character is lost. The attached example shows both bugs. The first bug stops the red style from being applied to the element, and the second bug applies the blue style to the element instead of the <li> element. The quick fix is for skipString() to call ungetChar() before returning successfully (patch attached). Luckily only nextToken() calls skipString(). Should I push this, or is there a better way to do it? [1] http://layscience.net/node/1120

Nov. 14, 2010

Dillo-Win32 patches, split and ready to merge

by obeythepenguin＠gmail.com

On Fri, 12 Nov 2010 18:03:31 -0500, corvid <corvid(a)lavabit.com> wrote: > Joerg wrote: >> Primary issue with depending on certain C99 stuff is that Microsoft >> still hasn't managed to support it in the runtime library or insists on >> doing it in incompatible ways. E.g. %lld doesn't work on Windows. > > Yeah, I see that on http://en.wikipedia.org/wiki/C99#Implementations , > level of support is generally 'mostly' or 'partial'. I was thinking that > it might be valuable to decide on what subset is all right (which, > admittedly, "Using gcc and not seeing any warnings" can be regarded as, > after a fashion. :) -- even if only to bring awareness of "Oh, this is > a C99ism; I hadn't realized." > The dillo site does spell out, for instance, that for C++, "We also try > to keep the C++ relatively simple. Dillo does use inheritance and > templates, > but that's about all." I'm not sure how formal our guidelines would need to be, but if the main problem is Windows support, whatever subset we're currently using is just fine. The only problems I've encountered are upstream FLTK bugs (their Windows version is frankly abysmal), and explicit Unix-isms, mostly involving inter-process communication. For what it's worth I'm using gcc-3.4.6 from MinGW 5.1.6. A little outdated, I know, but it's the last version with a coherent installer. ~Benjamin

Nov. 13, 2010