- Dillo-dev - lists.mailman3.com

Bugs 411 & 414 Solaris libs
by Mail.com Janke 07 Mar '03

07 Mar '03

It looks to me like perhaps older Solaris had -lposix4 and newer Solaris has -lrt for nanosleep(). On Solaris 8 posix4 is a symlink to rt. Perhaps configure can figure it out? This works on Solaris 8: dnl Workaround for nanosleep and solaris case $system in SunOS) AC_MSG_CHECKING(whether SunOS has -lrt ) LDSAVEFLAGS="$LDFLAGS" LDFLAGS="$LDFLAGS -lrt" AC_TRY_LINK_FUNC(nanosleep, rt_ok=yes, rt_ok=no) if test "x$rt_ok" = "xyes"; then AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) AC_MSG_CHECKING(whether SunOS has -lposix4 ) LDFLAGS="$LDSAVEFLAGS -lposix4" AC_TRY_LINK_FUNC(nanosleep, posix_ok=yes, posix_ok=no) if test "x$posix_ok" = "xyes"; then AC_MSG_RESULT(yes) else LDFLAGS=$LDSAVEFLAGS AC_MSG_RESULT(no) AC_MSG_WARN(*** Try setting LIBS or LDFLAGS manually to point to the library with nanosleep()***) fi fi ;; esac -- __________________________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup

1 0

Re: [Dillo-dev] Two branches?
by John Bradford 06 Mar '03

06 Mar '03

> > > Why don't we have a branch more like the Linux kernel? > > > > > > I would _love_ to have a cvs branch that had every bit of > > > developmental code in it so that we can see what's happening: > > > > To be honest, I would prefer not to use CVS at all, but instead just > > have a list of patches in unified diff format on the Dillo website, > > with a note saying which version they were made against. > > > > That way, everybody can apply whatever combination of patches they > > want to quickly and easily, and you can unapply a patch just using -R. > > > > Unified diff format makes it easier to apply patches against code that > > has already been modified. > > > > > Even though it will be _very_ unstable. > > > My theory is, if it is good enough for a screenshot, it's good enough > > > for the 'developmental' branch. > > > > > > This would also mean that the developer's personal trees will be > > > better sync'ed > > > > Having a separate development branch does create a fair amount of > > work, keeping the two in sync. > > > > John. > > I'm keen to either or both ideas. :) > > I'm a newbie to all this really, so I don't know too > much about serious advantages and disadvantages but I'm > in it primarily to enjoy myself and a fast-changing > unstable branch sounds like it could be fun. The decision is really up to Jorge :-). > Update on the issues John pointed out: > > 1. Disapearing list bullets. -- Solved, I'll make code > available if you are interested. Yes please. > But i'm busy at the moment. > > 2. List items other than the first in the list are > displayed slightly too far to the right. -- I've found > that Dw_widget_size_allocate is being called with an > extra +5 for the x coordinate of those list items. I > don't yet know why. > > 3. maximizing in FVWM2 -- I haven't looked into it at > all yet. > > > I'd like to have in my personal copy of Dillo two > features that have been available for Dillo in the past > but never made their way into CVS and were not > maintained: > > 1. Basic Authentication -- so I can use dillo > with the CUPS web interface. > > 2. Outside Html Source Viewer -- I'd rather > dillo spawn vim. Has anybody else noticed that when displaying very long lines in the source viewer, occasionally the arrows which indicate wrapped lines overlap the last letter on each screen line? > When I get a chance, I'll make the old patches and > probably some others available on my website. John.

1 0

freezing of dillo.0.7.0
by robert w hall 06 Mar '03

06 Mar '03

Is the description of the 'freezing' of dillo given in the README an uptodate description of the problem. This implies that it is a kernel version effect... I originally compiled dillo0.6.6 against slack 7, kernel 2.4.5 (IIRC, or even 2.2.18) with no problems. However dillo0.7.0 does freeze, even when compiled against the headers for, and run under, kernel 2.4.19. BUT it compiles and runs ok when compiled under slack8.1, with the same headers and kernel. Is this a gcc problem? (I'm using 2.91.66 with slack 7). (The suggested patch poll-fix-fast of course does not run in cleanly against 0.7.0., and though the source compiles the executable still freezes). Sorry if I've missed something on this. Bob Hall PS it all compiles fine on the playstation2 linux kit with the 2.2.21 kernel, and a real old gcc -- robert w hall

2 3

More bugfixes
by Jorge Arellano Cid 05 Mar '03

05 Mar '03

Hi there! I've been reviewing the bugtrack and receiving a lot of emails with regard to problems with solaris. There were several issues, some solved in CVS and others that escape our scope (Solaris is so inconsistent that some versions require certain libraries that others not, some fail, some work...) If someone has the patience to tweak configure.in to detect the different subversions of Solaris and add the magical options, I'd put it in. Just read the ChangeLog for a brief of the fixes. --------------------------------------------------- NOTE: There're lots of fixes, not just for Solaris. --------------------------------------------------- Please send me feedback about how it went. Sadly I just received _one_ mail report. Andreas: Please test the flock patch. It should work with *BSD as it defines flock(). Sebastian: Please review BUG#424, Keith says it's a trivial fix. Ah, can anyone reproduce/not_reproduce bug 406? Has anyone with a 64bit machine had NO trouble at all? :-) Cheers Jorge.-

3 2

Alternative toolbar icons
by Jorge Arellano Cid 05 Mar '03

05 Mar '03

Hi there! I just updated the Icons page (the toolbar alternatives) (BUG#410). Go give it a look! Cheers Jorge.-

1 0

Re: a vulnerability in dillo
by Jorge Arellano Cid 05 Mar '03

05 Mar '03

On Sun, 2 Mar 2003, Ivan Popov wrote: > Hello, > > having read the statement about dillo being a secure browser, It tries to be! > I want to draw your attention to the exploitable in different ways > bookmarks plugin interface. > > I submitted it as a bug and mentioned denial-of-service only, but creating > predictably named sockets in /tmp opens to other possible attacks > (e.g. spoofing your bookmarks) as well. > > I realize dillo and the plugins are evolving at fast rate, but this issue > can (and should?) be fixed even on the early stages of development. Probably (soon) socket file descriptors will reside in /tmp/dillo and use temporary filenames, or something akin (this also solves the problem of a pre-existent file with the same name). > Thanks for the great software! > I appreciate dillo - it is small, fast and functional. Thanks for your nice comments too. Cheers Jorge.-

2 1

Re: hidden fields in forms broken?
by Jorge Arellano Cid 05 Mar '03

05 Mar '03

Francis, > I've come across an apparent form anomaly when using dillo to test a > separate application. > > If I create a html form, the data submitted differs depending on whether > I use "text" or "hidden" input types -- specifically, the "hidden" type > is not parsed for html entities. This causes breakage when I want to set > the value to the four-character string x"'y, for example. > > The code for this is in html.c, around line 3077 (version 1.132), where > just using the same "init_str = (value) ? value : NULL;" as most other > types would work. > > >From the comment, it was clearly a deliberate decision to > leave out entity-parsing for DILLO_HTML_INPUT_HIDDEN (and > DILLO_HTML_INPUT_PASSWORD, around line 3049). The change appears to have > been made between revisions 1.5 and 1.6, where the "submit" (and others) > type explicitly had Html_parse_entities() called but the "hidden" type > didn't. > > I don't see any dispensation in the HTML DTD which makes "hidden" and > "password" immune to the entity rules. Is the exception in dillo an > oversight that just hasn't been spotted yet? Or is there some reasoning > that I'm missing behind the way things are? > > For reference, other web browsers I tried took the html fragment > > <form> > <input type=text name=plain value="x"x"> > <input type=hidden name=hide value="x"x"> > <input type=submit> > </form> > > and on submission, the URL had the same value for "plain" and "hide". > In dillo, the query string is plain=x%22x&hide=x%26quot%3Bx This is quite an interesting issue! I digged through the historical releases and the root of the problem is very far (before 0.3.2!). As I currently see it, the SGML type for those INPUT attribute values is CDATA, so entities SHOULD/MUST be parsed!!! Does anyone know otherwise? Cheers Jorge.-

2 1

Question about dpi interface ...
by Lars Segerlund 05 Mar '03

05 Mar '03

If I have dillo 0.7.0 with the bookmarks working through dpi, how can I add dpi functionality ? Can I make a dpi server without modyfying the dillo binary ? / rgards, Lars Segerlund.

2 1

Loosing bookmarks
by John Bradford 02 Mar '03

02 Mar '03

Since I started using using 7.0, my bookmarks have been lost on four occasions, but I haven't been able to reproduce the bug at will - has anybody else noticed this? John.

9 9

BUGFIX set close_on_exec (FD_CLOEXEC)
by Raphael Barabas 02 Mar '03

02 Mar '03

hello, in my neverending search for the perfect browser i stumbled across dillo. it looks great and quite usable, altough it's still alpha. unfortunately dillo 0.7.0 won't run on solaris8 (ultra30), so i wrote a fix. turns out every other os is affected by this bug, too. solaris just seems to be less forgiving in this matter :) to compile on solaris you may also need some workarounds, take a look at bugreports 402, 413 and 415. problem: solaris: see bugreport 416, dillo enters endless loop on startup, repeating "IO_write: Changing io->Buf (0)" linux: no immediate effect, although some filedescriptors are in state "open" for too long. i've not really looked into it but this should have negative effects in the long run. reason: in IO.c, function IO_submit, filedescriptor-flag close_on_exec is not set the right way (not at all). on solaris, as a direct result, non-blocking io will accidentally be handled via O_NDELAY instead of O_NONBLOCKING, resulting in an endless loop. patch: *** IO.c.org Sat Mar 1 21:56:13 2003 --- IO.c Sat Mar 1 21:56:54 2003 *************** *** 530,536 **** /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, ! O_NONBLOCK | FD_CLOEXEC | fcntl(r_io->FD, F_GETFL)); if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, --- 530,538 ---- /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, ! O_NONBLOCK | fcntl(r_io->FD, F_GETFL)); ! fcntl(r_io->FD, F_SETFD, ! FD_CLOEXEC | fcntl(r_io->FD, F_GETFD)); if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, disclaimer: this bugfix has been tested briefly on debian gnu/linux 2.4.20 and solaris 8. please review my code for correctness. also note that bugreport 417 has been proven wrong by this. regards, raphael

1 1