- Dillo-dev - lists.mailman3.com

Altavista search does not work

by jcid＠dillo.org

On Mon, Oct 13, 2008 at 05:41:20PM +0100, Francis Daly wrote: > On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > > Christopher wrote: > > Hi there, > > > > Doing web searches using www.altavista.com does not work. It is as > > > if the search terms are not submitted. The following HTML errors > > > are detected: > > > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > > HTML warning: line 68, - forcing close of open tag: <form> > > > HTML warning: line 68, FORM lacks a Submit button > > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > > or "News" works well. > > > > > > Is this a problem with altavista rather than with dillo? > > > > It looks like altavista just threw together their form and table tags > > rather than nesting them. > > It's a problem with altavista, in that their HTML is invalid, and > therefore they rely on browser-fixups to get the result they probably > wanted. Yes. Both validators WDG and W3C (bug meter's right-click menu), explain this bug. In simple terms, the form declaration should be outside the table. Otherwise, following HTML rules, the form is closed. -- Cheers Jorge.-

Oct. 13, 2008

Altavista search does not work

by corvid＠lavabit.com

Francis wrote: > On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > > Christopher wrote: > > Hi there, > > > > Doing web searches using www.altavista.com does not work. It is as > > > if the search terms are not submitted. The following HTML errors > > > are detected: > > > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > > HTML warning: line 68, - forcing close of open tag: <form> > > > HTML warning: line 68, FORM lacks a Submit button > > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > > or "News" works well. > > > > > > Is this a problem with altavista rather than with dillo? > > > > It looks like altavista just threw together their form and table tags > > rather than nesting them. > > It's a problem with altavista, in that their HTML is invalid, and > therefore they rely on browser-fixups to get the result they probably > wanted. > > It's a problem with dillo, in that the submit button (presumably) works > for most other browsers. > > More specifically, the main difference between the (working) images page > and the (failing) web page is the presence of an explicit close-table-cell > </td> tag. > > If you remove the </td> on line 68 of the altavista index.html page, > then the submit button works. > > So presumably dillo is handling "explicit </td> before <td>" differently > from "no </td> immediately before <td>", at least in this case. I think dillo sees <td> ... <form> ... </td> and closes the form, which seems like the right behavior. > (dillo1 acts the same, except it doesn't show the input field or the > search button at all in the first case.) > > It doesn't look like a significant v1-v2 regression to me, apart from > the fact that it now looks like it might submit something.

Oct. 13, 2008

Altavista search does not work

by francis＠daoine.org

On Fri, Oct 10, 2008 at 12:43:59PM +0000, corvid wrote: > Christopher wrote: Hi there, > > Doing web searches using www.altavista.com does not work. It is as > > if the search terms are not submitted. The following HTML errors > > are detected: > > > > HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid) > > HTML warning: line 68, - forcing close of open tag: <form> > > HTML warning: line 68, FORM lacks a Submit button > > HTML warning: line 94, unexpected closing tag: </form>. -- expected </table> > > > > Searching for "Images", "MP3/Audio", or "Video" instead of "Web" > > or "News" works well. > > > > Is this a problem with altavista rather than with dillo? > > It looks like altavista just threw together their form and table tags > rather than nesting them. It's a problem with altavista, in that their HTML is invalid, and therefore they rely on browser-fixups to get the result they probably wanted. It's a problem with dillo, in that the submit button (presumably) works for most other browsers. More specifically, the main difference between the (working) images page and the (failing) web page is the presence of an explicit close-table-cell </td> tag. If you remove the </td> on line 68 of the altavista index.html page, then the submit button works. So presumably dillo is handling "explicit </td> before <td>" differently from "no </td> immediately before <td>", at least in this case. (dillo1 acts the same, except it doesn't show the input field or the search button at all in the first case.) It doesn't look like a significant v1-v2 regression to me, apart from the fact that it now looks like it might submit something. f -- Francis Daly francis(a)daoine.org

Oct. 13, 2008

aclocal.m4 and autom4te.cache in CVS

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Henty wrote: > Yes you're right, they're not in CVS/Entries . I've started managing > my dillo development by tracking the CVS checkout in one git > repository (the "remote") and developing in a cloned repository (the > "local"). So the remote repository should stay pristine, but it > didn't. Looks like I screwed up and ran autogen.sh in the remote at > some point. Apologies for the noise. > > BTW, is anyone else using git like this? I thought I saw some patches > on the list that looked git-generated. I am using bzr with a similar setup. Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjzaCIACgkQoPmwNWhsaZYENgCfSNnEZutmw0RoUbS7u4W+6r1P 8woAnjIPqNcBtZ5tAIY3jm4wW6mRa17p =LtQk -----END PGP SIGNATURE-----

Oct. 13, 2008

dillo-2.0 rc1 is in CVS

by jcid＠dillo.org

On Mon, Oct 13, 2008 at 06:45:23AM -0700, bf wrote: > The message about re-enabling https support (on line 667) in revision 1.3 of > dpi/https.c should refer to line 72, not line 65. Changed. > Ironically, > > http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/~checkout~/dillo/dillo2/dpi… > > fails with "Error: Unsupported content type: text/x-c++src". Maybe some > of dillo's type-checking needs to be revisited. Also problematic are some > other kinds of text files. Please post some other URLs. To be reviewed in the release after this one... -- Cheers Jorge.-

Oct. 13, 2008

aclocal.m4 and autom4te.cache in CVS

by Johannes.Hofmann＠gmx.de

On Mon, Oct 13, 2008 at 02:06:32PM +0100, Jeremy Henty wrote: > On Mon, Oct 13, 2008 at 09:17:37AM -0300, Jorge Arellano Cid wrote: > > On Sun, Oct 12, 2008 at 09:43:26AM +0100, Jeremy Henty wrote: > > > > > > Why have aclocal.m4 and autom4te.cache been added to CVS? > > > > Just checked in CVS Web and also a clean CVS checkout, and don't > > see those files added. > > Yes you're right, they're not in CVS/Entries . I've started managing > my dillo development by tracking the CVS checkout in one git > repository (the "remote") and developing in a cloned repository (the > "local"). So the remote repository should stay pristine, but it > didn't. Looks like I screwed up and ran autogen.sh in the remote at > some point. Apologies for the noise. > > BTW, is anyone else using git like this? I thought I saw some patches > on the list that looked git-generated. I'm using mercurial, which uses a similar patch format for exporting patches. Regards, Johannes

Oct. 13, 2008

dillo-2.0 rc1 is in CVS

by bf2006a＠yahoo.com

The message about re-enabling https support (on line 667) in revision 1.3 of dpi/https.c should refer to line 72, not line 65. Ironically, http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/~checkout~/dillo/dillo2/dpi… fails with "Error: Unsupported content type: text/x-c++src". Maybe some of dillo's type-checking needs to be revisited. Also problematic are some other kinds of text files. Regards, b.

Oct. 13, 2008

dillo-2.0 rc1 is in CVS

by jcid＠dillo.org

Hi, On Sat, Oct 11, 2008 at 02:03:50PM -0700, Kelson Vibber wrote: > Seems to compile and run okay on Fedora 9 x86_64. I uploaded the final dillo-2.0 to the website. It will be released tomorrow. It's rc1 with: * Release date in the splash page, * Directions on where to get the FLTK2 library in the README. It'd be good to have some packages for Debian and Fedora. PS: http://www.dillo.org/download/dillo-2.0.tar.bz2 -- Cheers Jorge.-

Oct. 13, 2008

aclocal.m4 and autom4te.cache in CVS

by onepoint＠starurchin.org

On Mon, Oct 13, 2008 at 09:17:37AM -0300, Jorge Arellano Cid wrote: > On Sun, Oct 12, 2008 at 09:43:26AM +0100, Jeremy Henty wrote: > > > > Why have aclocal.m4 and autom4te.cache been added to CVS? > > Just checked in CVS Web and also a clean CVS checkout, and don't > see those files added. Yes you're right, they're not in CVS/Entries . I've started managing my dillo development by tracking the CVS checkout in one git repository (the "remote") and developing in a cloned repository (the "local"). So the remote repository should stay pristine, but it didn't. Looks like I screwed up and ran autogen.sh in the remote at some point. Apologies for the noise. BTW, is anyone else using git like this? I thought I saw some patches on the list that looked git-generated. Regards, Jeremy Henty

Oct. 13, 2008

aclocal.m4 and autom4te.cache in CVS

by jcid＠dillo.org

On Sun, Oct 12, 2008 at 09:43:26AM +0100, Jeremy Henty wrote: > > Why have aclocal.m4 and autom4te.cache been added to CVS? Just checked in CVS Web and also a clean CVS checkout, and don't see those files added. > Or am I missing something? I hope. :-) -- Cheers Jorge.-

Oct. 13, 2008