January 2006 - Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Dillo 0.8.5 with gmail

by Globe Trotter

Hi, I don't believe that dillo supports javascript and ever will. The author seems to believe that a browser should be as stripped down and non-functional as possible or as bloated as possible (such as mozilla or firefox), with nothing in between. I would like that something in between. I think a lot of us on this mailing list (me at least) would be very appreciative if you could make support for it. You may consider teaming up with http://teki.jpn.ph/pc/software/index-e.shtml which provides unofficial versions of dillo with additions. Be forewarned that dillo is going to change to fltk so you may want to wait for that to happen first. There is no point in wasting time and creating something that will go away. Apparently, two copies with fltk exist, but have never been released. They are supposed to be released in the next version. Many thanks and best wishes! > > --- Richard <judicator3(a)gmail.com> wrote: > > > Hello, > > > > I have compiled and installed Dillo 0.8.5 and enabled the https DPI. I am > > trying to use Dillo to log in to gmail. I have made sure that cookies are > > enabled for .gmail.com. I am able to get the gmail login page which is > > served through https but I cannot log in to my account. > > > > After clicking on the "Sign In" button and accepting all the certificate > > warnings messages, I am not redirected to my mailbox and I am stuck on the > > gmail login page. Does dillo support javascript ? and is that the reason > why > > I cannot login to gmail ? If javascript is the stopper that prevents dillo > > from being used on gmail, hotmail or yahoo etc... then I am willing to > > devote some time to get something like SpiderMonkey or some other JS engine > > to work with Dillo. > > > > I was running dillo from the command line and below is the output I got > from > > the console. Notice that dillo seems to die in the https.filter.dpi. I have > > looked at the mailing archives and I think I saw other people being able to > > at least login to gmail. So I am not sure what is going on in my case. Is > > there a later unstable version of Dillo I should use in order to login to > > gmail ? > > ============================================================== > > Dpi_parse_token: [<dpi cmd='dialog' msg='The remote certificate cannot be > > verified20' alt1='Continue' alt2='Cancel'>] > > a_Dpiapi_dialog: > > dpip_tag: <dpi cmd='dialog' msg='The remote certificate cannot be > > verified20' alt1='Continue' alt2='Cancel'> > > Dpi_parse_token: [<dpi cmd='start_send_page' url=' > > https://mail.google.com/mail/images/corner_tl.gif'>] > > { exiting https.dpi} > > Dpi: [Dpi_process_io] IOClose > > Nav_open_url: Url=>https://www.google.com/accounts/ServiceLoginAuth< > > main.c:154: get_command: dpid tag is NULL > > : main.c:328: main: get_command failed > > : {In https.filter.dpi} > > Dpi_parse_token: [<dpi cmd='dialog' msg='The remote certificate cannot be > > verified20' alt1='Continue' alt2='Cancel'>] > > a_Dpiapi_dialog: > > dpip_tag: <dpi cmd='dialog' msg='The remote certificate cannot be > > verified20' alt1='Continue' alt2='Cancel'> > > { exiting https.dpi} > > Dpi_parse_token: [<dpi cmd='start_send_page' url=' > > https://mail.google.com/mail/images/corner_tr.gif'>] > > Dpi: [Dpi_process_io] IOClose > > ============================================================== > > > > Thanks > > Best regards > > Richard Ta-Min > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev(a)dillo.org > > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Jan. 13, 2006

Current color control??

by Beartooth

I had my newsreader search 'color', but all I found was an exchange from 2003, and I doubt that's current. I have Dillo set as my default browser (under Fedora Core 4); every once in a while I get some site that's unreadable, because the text and background are too near the same color. My next move is to try the same URL in another browser; and that usually solves it. Can I make Dillo do whatever it is that the others do to remedy this, or not do whatever it does if it's creating it? -- Beartooth Stickster, Neo-Redneck Linux Enthusiast A wanderstaff like an Elvish rope should be long, and strong, and light -- and very smooth.

Jan. 13, 2006

Dillo 0.8.5 with gmail

by Richard

Hello, I have compiled and installed Dillo 0.8.5 and enabled the https DPI. I am trying to use Dillo to log in to gmail. I have made sure that cookies are enabled for .gmail.com. I am able to get the gmail login page which is served through https but I cannot log in to my account. After clicking on the "Sign In" button and accepting all the certificate warnings messages, I am not redirected to my mailbox and I am stuck on the gmail login page. Does dillo support javascript ? and is that the reason why I cannot login to gmail ? If javascript is the stopper that prevents dillo from being used on gmail, hotmail or yahoo etc... then I am willing to devote some time to get something like SpiderMonkey or some other JS engine to work with Dillo. I was running dillo from the command line and below is the output I got from the console. Notice that dillo seems to die in the https.filter.dpi. I have looked at the mailing archives and I think I saw other people being able to at least login to gmail. So I am not sure what is going on in my case. Is there a later unstable version of Dillo I should use in order to login to gmail ? ============================================================== Dpi_parse_token: [<dpi cmd='dialog' msg='The remote certificate cannot be verified20' alt1='Continue' alt2='Cancel'>] a_Dpiapi_dialog: dpip_tag: <dpi cmd='dialog' msg='The remote certificate cannot be verified20' alt1='Continue' alt2='Cancel'> Dpi_parse_token: [<dpi cmd='start_send_page' url=' https://mail.google.com/mail/images/corner_tl.gif'>] { exiting https.dpi} Dpi: [Dpi_process_io] IOClose Nav_open_url: Url=>https://www.google.com/accounts/ServiceLoginAuth< main.c:154: get_command: dpid tag is NULL : main.c:328: main: get_command failed : {In https.filter.dpi} Dpi_parse_token: [<dpi cmd='dialog' msg='The remote certificate cannot be verified20' alt1='Continue' alt2='Cancel'>] a_Dpiapi_dialog: dpip_tag: <dpi cmd='dialog' msg='The remote certificate cannot be verified20' alt1='Continue' alt2='Cancel'> { exiting https.dpi} Dpi_parse_token: [<dpi cmd='start_send_page' url=' https://mail.google.com/mail/images/corner_tr.gif'>] Dpi: [Dpi_process_io] IOClose ============================================================== Thanks Best regards Richard Ta-Min

Jan. 13, 2006

Re: [Dillo-dev] Re: patch: python filter DPI supporting the "data:" scheme from RFC 2397

by Jorge Arellano Cid

Hi Ben, On Fri, Dec 30, 2005 at 03:18:12PM -0800, Ben Wiley Sittler wrote: > yes!let me know when the c translation is uploaded and i will gladly > take a look. i have investigated the mp3 thing further, and basically > dillo is not well-prepared to deal with very long uris, especially not > ones handled by a dpi. probably a maximum should be chosen (max. pipe > buffer size less the size of the overhead bytes for the rest of the > dpi request, maybe?) and anything longer should generate an error > message inside dillo. The patch took some time because it uncovered a subtle parsing bug in Dpip. It's fixed now in CVS. Both the new datauri.c and the dpip fix were commited. This is a no-frills datauri dpi version. There're things to polish. For instance: URI="data:;,test" // empty base64 and media type, ";" should be ignored > > separately, much of the dillo core is unprepared to handle data: URIs; > for instance, it tried to generate filenames when saving that are > longer than the OS and filesystem maximum length, and also slow down > the GUI to unusable speeds due to font metric calculations. > furthermore it did not use the mime-types database to select a > filename extension, so they ended up with very cryptic names. Yes, this can also be improved. > as for the python dpi, maybe keep it as an example in the source tree > but don't install it when doing 'make install', and use the new C > implementation as the default? maybe some python programmer will take > it and turn it into something more useful... It didn't work for me so currently it's not in CVS. > also, do the dpi-handling functions in the python dpi seem correct, or > did i misunderstand the protocol? i was not so sure about the > quoting/escaping mechanisms... This was a bit fuzzy... I changed it a bit and commented much more in dpip/dpip.c. Data URIs are a bit delicate with regard to security. This also needs some work. Although datauri is enabled now, it may be disabled for the next release unless security is stronger. -- Cheers Jorge.-

Jan. 5, 2006

Re: [Dillo-dev] Fixing bug in parsing HTML 4.01 comments

by Michal Nowak

Sam Trenholme wrote: > You know, I would actually prefer it if Dillo does *not* fix this bug. > It would be nice to have a "hide from Dillo" HTML trick up my sleeve > for doing web design. For example, Dillo renders tables differently > than how Netscape/Firefox/MSIE renders tables. It would be nice to > be ale to make HTML code like this: > >  > > If Dillo fixes this bug, I will have to figure out some other way to hide > my HTML from Dillo (or be unable to make my web pages look good in Dillo-- > MSIE's CSS is just too primitive for me to completely get rid of tables) > > - Sam > Hello Sam, you are right - it's useful, but it is a hack. It's just hiding Dillo's style of table rendering (which is now being rewriten). I think we should follow specs. Maybe this tiny CSS hacks will help you: http://wellstyled.com/css-underscore-hack.html #item { color: black; /* style for all browsers */ _color: red; /* style for all IE/Win browsers */ _color/**/: orange; /* style for IE/Win 5.5+ browsers */ _co\lor: yellow; /* style for IE/Win 6.0+ browsers */ } I found that comment bug when I was passing by Acid2 test with dillo (http://webstandards.org/act/acid2/) Michal Nowak

Jan. 5, 2006

Re: [Dillo-dev] Fixing bug in parsing HTML 4.01 comments

by Sam Trenholme

You know, I would actually prefer it if Dillo does *not* fix this bug. It would be nice to have a "hide from Dillo" HTML trick up my sleeve for doing web design. For example, Dillo renders tables differently than how Netscape/Firefox/MSIE renders tables. It would be nice to be ale to make HTML code like this:  If Dillo fixes this bug, I will have to figure out some other way to hide my HTML from Dillo (or be unable to make my web pages look good in Dillo-- MSIE's CSS is just too primitive for me to completely get rid of tables) - Sam

Jan. 5, 2006

Fixing bug in parsing HTML 4.01 comments

by Michal Nowak

Hi developers there, I found (hope so) a bug in parsing HTML comments. Acording to HTML 4.01 spec it is possible to make such a comment: " tag. */ while ( (p = memchr(buf + buf_index, '>', bufsize - buf_index)) ){ buf_index = p - buf + 1; - if ( p[-1] == '-' && p[-2] == '-' ) break; + gint counter = -1; + while (isspace(p[counter])) + counter--; + if ( p[counter] == '-' && p[counter-1] == '-' ) break; } if ( p ) { /* Got the whole comment. Let's throw it away! :) */ It's hackish and ugly. I know. From: http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.2.4 "White space is not permitted between the markup declaration open delimiter("<!") and the comment open delimiter ("--"), but is permitted between the comment close delimiter ("--") and the markup declaration close delimiter (">"). A common error is to include a string of hyphens ("---") within a comment. Authors should avoid putting two or more adjacent hyphens inside comments." Michal Nowak

Jan. 5, 2006

Re: [Dillo-dev] Size of the new downloads.dpi

by Jorge Arellano Cid

Hi Michal, On Tue, Jan 03, 2006 at 08:08:30PM +0100, Michal Nowak wrote: > Hi dillo developers, > > I just compiled the CVS version of dillo (0.86-pre) with the FLTK based > downloads.dpi. I see it's statically linked against FLTK, but it's now > 450 KiB (here). I think it's quite big. > > When the whole dillo will be FLTK based, will it be staticaly linked > too? Or dynamically, like now with the GTK+ 1.2? > > Thank you all for great work you do. Don't Panic! strip downloads.dpi and it'll get near 310KB. Now, that's a _statically linked_ binary. This is something like linking statically the whole GTK1 library to dillo. Statical and shared FLTK2 can be done. For instance, in the future, it can be built an all shared FLTK2 dillo and dl dpi. Or both static. The advantage of static at this point is you don't need to include the library as a dependency in a package. -- Cheers Jorge.-

Jan. 3, 2006

Size of the new downloads.dpi

by Michal Nowak

Hi dillo developers, I just compiled the CVS version of dillo (0.86-pre) with the FLTK based downloads.dpi. I see it's statically linked against FLTK, but it's now 450 KiB (here). I think it's quite big. When the whole dillo will be FLTK based, will it be staticaly linked too? Or dynamically, like now with the GTK+ 1.2? Thank you all for great work you do. Michal Nowak

Jan. 3, 2006

Re: [Dillo-dev] FLTK2-based GUI dpi for downloads

by Jorge Arellano Cid

Hi There, > OK, tried this on FreeBSD 6 and ran into the following minor issues: > > - I needed to move dpi/downloads.c out of the way; otherwise > something(tm) always tried to build downloads.o using downloads.c > (Makefile and Makefile.in were correctly generated but > .deps/downloads.Po was wrong - could someone enlighten me what goes on > there?) > > - I needed to patch dpi/downloads.cc to make it build, I hope this fix > is correct: > [...] OK, the CVS now has FLTK2 GUI dpi for downloads as _default_. If you don't have FLTK2, you can: ./configure --disable-dlgui and get the old one. So far, the current HOWTO for FLTK2-GUI-dpi for downloads is: 1.- Get the latest CVS (it has dpi/downloads.cc) 2.- Go to http://www.fltk.org/software.php and get the "fltk-2.0.x-r4721.tar.bz2" tarball (or SVN at your option). __you need FLTK 2.0.x, FLTK 1.1.x won't work___ 3.- Install FLTK2 4.- Build Dillo, install & enjoy! e.g. ./configure; make; make install-strip For old (non GUI) downloads: 1.- Get the latest CVS (it has dpi/downloads.cc) 2.- Build Dillo, install & enjoy! e.g. ./configure --disable-dlgui; make; make install-strip -- Cheers Jorge.-

Jan. 3, 2006