- Dillo-dev - lists.mailman3.com

[patch]: remove redundant #include in fltkflatview.cc
by onepoint＠starurchin.org April 30, 2008

April 30, 2008

A small cleanup: the "#include <fltk/damage.h>" in fltkflatview.cc is unnecessary. Regards, Jeremy Henty

2 1

[patch] fix table destructor
by Johannes.Hofmann＠gmx.de April 30, 2008

April 30, 2008

Hi, with memleaks in the news lately.... Here comes another one. Cheers, Johannes

2 1

patch: fltkimgbuf memleak
by corvid＠lavabit.com April 29, 2008

April 29, 2008

You should see a significant decrease in memory used.

3 2

Cheering some recent improvements in table layout
by onepoint＠starurchin.org April 29, 2008

April 29, 2008

Just to say that I'm seeing much better table rendering now. I have a page with a large two-column table. For a while recently this rendered very strangely in Dillo: it appeared with the two columns at opposite sides of the page, then the second column would move over to the left, one item at a time, to sit next to the first. But now the table immediately appears with both columns in the right place. I don't know what caused the strange realignment behaviour but I'm glad it's gone. Regards, Jeremy Henty

2 1

[patch] phrase search - take 2
by Johannes.Hofmann＠gmx.de April 29, 2008

April 29, 2008

Hi, here comes my second attempt on phrase search. As already described, I changed CharIterator back to not return \0s. Instead blanks are inserted when the space flag is set. This way CharIterator always returns a smooth stream of chars whether for normal html- or pre-text. Then there was a bug in DeepIterator::prev() that took me some time to find. I also adjusted charsEqual() to treat all space-chars equally. Finally I had to add a check in CharIterator::highlight() to avoid a crash when searching for the last word in pre-text with a blank appended. Cheers, Johannes

2 1

dillo seems to close file descriptors twice
by Johannes.Hofmann＠gmx.de April 29, 2008

April 29, 2008

Hi, I just noticed, that dillo seems to close file descriptors twice via IO_close_fd, which causes problems when other threads run in parallel for name server queries. Here are the two call stacks via which IO_close_fd is called for each fd: (gdb) b IO_close_fd Breakpoint 1 at 0x8070781: file IO.c, line 137. (gdb) r dillo.org Starting program: /home/hofmann/projects/dillo/plain/dillo2-hg/src/dillo-fltk dillo.org dillo_dns_init: Here we go! (threaded) Enabling cookies as from cookiesrc... Nav_open_url: new url='http://dillo.org' Dns_server [0]: dillo.org is 0x28559680 Connecting to 134.102.206.165 Nav_open_url: new url='http://www.dillo.org/' Breakpoint 1, IO_close_fd (io=0x28550a00, CloseCode=2) at IO.c:137 137 fprintf(stderr,"====> begin IO close (%d)\n", io->FD); Current language: auto; currently c (gdb) bt #0 IO_close_fd (io=0x28550a00, CloseCode=2) at IO.c:137 #1 0x0807094e in a_IO_ccc (Op=4, Branch=1, Dir=2, Info=0x285509e0, Data1=0x0, Data2=0x0) at IO.c:392 #2 0x0805633e in a_Chain_bcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:98 #3 0x0806ea14 in a_Http_ccc (Op=4, Branch=1, Dir=2, Info=0x2854df60, Data1=0x0, Data2=0x0) at http.c:522 #4 0x0805633e in a_Chain_bcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:98 #5 0x0805a514 in a_Capi_ccc (Op=4, Branch=1, Dir=2, Info=0x2854df40, Data1=0x0, Data2=0x0) at capi.c:491 #6 0x0805a39c in a_Capi_ccc (Op=4, Branch=2, Dir=1, Info=0x285509a0, Data1=0x0, Data2=0x0) at capi.c:601 #7 0x0805630a in a_Chain_fcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:86 #8 0x0806ffd1 in a_Dpi_ccc (Op=4, Branch=2, Dir=1, Info=0x28550bc0, Data1=0x0, Data2=0x0) at dpi.c:671 #9 0x0805630a in a_Chain_fcb (Op=4, Info=0x28550a00, Data1=0x0, Data2=0x0) at chain.c:86 #10 0x08070891 in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x28550c00, Data1=0x28550c20, Data2=0x0) at IO.c :410 #11 0x08070b64 in IO_callback (fd=<value optimized out>, io=0x28550c20) at IO.c:201 #12 0x08070beb in IO_fd_read_cb (fd=7, data=0x2) at IO.c:277 #13 0x080bcfe5 in fltk::wait () #14 0x080bd195 in fltk::run () #15 0x0804eadb in main (argc=0, argv=0x0) at dillo.cc:110 (gdb) c Continuing. ====> begin IO close (7) Breakpoint 1, IO_close_fd (io=0x28550c20, CloseCode=2) at IO.c:137 137 fprintf(stderr,"====> begin IO close (%d)\n", io->FD); (gdb) bt #0 IO_close_fd (io=0x28550c20, CloseCode=2) at IO.c:137 #1 0x0807089e in a_IO_ccc (Op=4, Branch=2, Dir=1, Info=0x28550c00, Data1=0x28550c20, Data2=0x0) at IO.c:411 #2 0x08070b64 in IO_callback (fd=<value optimized out>, io=0x28550c20) at IO.c:201 #3 0x08070beb in IO_fd_read_cb (fd=7, data=0x2) at IO.c:277 #4 0x080bcfe5 in fltk::wait () #5 0x080bd195 in fltk::run () #6 0x0804eadb in main (argc=0, argv=0x0) at dillo.cc:110 (gdb) c Continuing. ====> begin IO close (7) A line like fprintf(stderr,"====> begin IO close (%d)\n", io->FD); at the beginning of IO_close_fd() also shows the problem. Cheers, Johannes

3 3

Since we've been talking about name clashes, what about "assert"
by onepoint＠starurchin.org April 27, 2008

April 27, 2008

Because lout::misc defines an inline assert function, including dw/core.hh fails if you've already included anything that defines the standard assert macro (such the C++ iostream stuff). You can work around it by including dw/core.hh first, but that feels pretty fragile as it depends on nothing subsequently using the standard assert. What's the best fix? (Example appended.) Regards, Jeremy Henty For example: #include <ios> #include <dw/core.hh> yields (with GCC 3.4.3): In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:36:55: macro "assert" passed 3 arguments, but takes just 1 In file included from ./../Source/current/dw2/dw/../lout/object.hh:7, from ./../Source/current/dw2/dw/core.hh:39, from dw_assert.cc:9: ./../Source/current/dw2/dw/../lout/misc.hh:37: error: invalid function declaration ./../Source/current/dw2/dw/../lout/misc.hh:185:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:198:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh:213:30: macro "assert" passed 4 arguments, but takes just 1 ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T* lout::misc::SimpleVector<T>::getRef(int)': ./../Source/current/dw2/dw/../lout/misc.hh:184: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh:184: error: (Each undeclared identifier is reported only once for each function it appears in.) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `T lout::misc::SimpleVector<T>::get(int)': ./../Source/current/dw2/dw/../lout/misc.hh:197: error: `assert' undeclared (first use this function) ./../Source/current/dw2/dw/../lout/misc.hh: In member function `void lout::misc::SimpleVector<T>::set(int, T)': ./../Source/current/dw2/dw/../lout/misc.hh:212: error: `assert' undeclared (first use this function) make[1]: *** [dw_assert-dw_assert.o] Error 1

2 2

Re: patch: various IN_*s
by jcid＠dillo.org April 27, 2008

April 27, 2008

Hi, On Sun, Apr 27, 2008 at 02:15:37PM +0000, corvid wrote: > - disallow <button> or <input> inside <button>. > Nested buttons and image inputs inside buttons don't come out right, > and they aren't legal anyway. OK. > - disallow <input> inside <select>. > As I mentioned before, </select> does not like that, and it isn't legal. ok. > - disallow <isindex> inside <form>. > It's legal (%block goes inside form, and isindex is a %block), > but it splits a form into pieces, given dillo's current implementation. > Firefox handles it as a form within a form, but I don't want to add > complexity, and I know you don't want to add complexity :) ok. Committed. -- Cheers Jorge.-

1 0

"View Page source" scrolling problem
by 4winter＠informatik.uni-hamburg.de April 27, 2008

April 27, 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey folks :) I found another bug / feature... I use a trackstick with mouse wheel emulation. This allows me to scroll text by pressing the middle button and moving the stick. Someone in the xorg input layer maps this to buttons 4 - 7 (up, down, left, right). Problem is that it is impossible to just scroll up. You end up being off by some degree and you get a event for left and right every now and then (confirmed using xev). Unfortunately this kills the scrolling in the view page source window: http://teythoon.cryptobitch.de/stuff/scroll-problem.ogg It would also be nice to be able to scroll left/right with buttons 6 and 7. Since there are mouses that have special navigation buttons (most likely also being number 6 and 7) it would be nice to be able to configure the mapping (firefox does this) for these buttons. That would make trackstick users happy and also those of us that are stuck with a mouse with those navigation buttons (I have access to one of those and the buttons are located at the left side so that you can press them with your thumb [not a very left-handed friendly design]. To make a long story short you just end up pressing them by accident the moment you filled out some huge form...). But then again, some people might find them useful. Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIE+EdoPmwNWhsaZYRArv+AJ0ZO6hR5Caw/eaHXtnwWv9RFEgETACfYn6v FcJ5rxwibEXoAK5ZLtmTNEs= =t0nP -----END PGP SIGNATURE-----

1 0

[PATCH]: lout::misc::min
by onepoint＠starurchin.org April 27, 2008

April 27, 2008

I mean, this *has* to be a typo, right? Jeremy Henty

2 3

Docs question: dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE
by onepoint＠starurchin.org April 27, 2008

April 27, 2008

The description of dw::core::ui::ListResource::SelectionMode::SELECTION_AT_MOST_ONE does not make sense. Should "The user may not the only selected item." read "The user may unselect the only selected item."? Regards, Jeremy Henty

3 4

[patch] phrase search
by Johannes.Hofmann＠gmx.de April 26, 2008

April 26, 2008

Hi, attached is a patch that make phrase search work. I'm not 100% sure about the CharIterator::prev() change. CharIterator::next() returned \0 between words, prev() didn't. So something was wrong. I decided to go with current next() behaviour and made prev() return \0 as word separator too. Also the current implementation only works if one enters exactly one blank between words in the search dialog. Should we collapse multiple blanks into one automatically? Cheers, Johannes

2 2

Re: patch: Accept-Charset: utf-8,*;q=0.8
by jcid＠dillo.org April 26, 2008

April 26, 2008

On Thu, Apr 17, 2008 at 04:57:48PM +0000, corvid wrote: > It is good for dillo to state its preference for UTF-8 > over ISO-8859-1. > > Also, the RFC says that not mentioning '*' puts dillo > in theoretical danger of receiving 406 Not Acceptable. > Committed, assuming: "Accept-Charset: utf-8,*;q=0.8\r\n" means dillo2 leaves the door open to also receive iso-8859-1. -- Cheers Jorge.- > --- dillo2/src/IO/http.c 2008-04-11 19:48:51.000000000 +0000 > +++ dillo2-cur/src/IO/http.c 2008-04-17 16:17:17.000000000 +0000 > @@ -236,7 +236,7 @@ Dstr *a_Http_make_query_str(const DilloU > query, > "POST %s HTTP/1.1\r\n" > "Connection: close\r\n" > - "Accept-Charset: utf-8, iso-8859-1\r\n" > + "Accept-Charset: utf-8,*;q=0.8\r\n" > "Accept-Encoding: gzip\r\n" > "Host: %s%s\r\n" > "%s" > @@ -258,7 +258,7 @@ Dstr *a_Http_make_query_str(const DilloU > "GET %s HTTP/1.1\r\n" > "%s" > "Connection: close\r\n" > - "Accept-Charset: utf-8, iso-8859-1\r\n" > + "Accept-Charset: utf-8,*;q=0.8\r\n" > "Accept-Encoding: gzip\r\n" > "Host: %s%s\r\n" > "%s"

2 2

patch: /* todo: don't create things if button type is unknown */
by corvid＠lavabit.com April 26, 2008

April 26, 2008

2 1

Re: the last patch that I sent you BREAKS isindex.
by jcid＠dillo.org April 26, 2008

April 26, 2008

On Thu, Apr 17, 2008 at 06:17:04AM +0000, corvid wrote: > I shouldn't have moved isindex's connectActivate to close_form. > If you wish, I can make a new version. Yes, please. > > By the way, I found that the top of open_input needs > if (html->InFlags & IN_SELECT) { > MSG_HTML("INPUT inside SELECT\n"); > return; > } > Otherwise, if another input sneaks in there, close_select will crash. Please include it in the patch. -- Cheers Jorge.-

2 1

[patch] introduce lout namespace (was: namespace problem)
by Johannes.Hofmann＠gmx.de April 26, 2008

April 26, 2008

Hi, while trying to implement a fix to the namespace problem I came to the conclusion that the easiest and least intrusive way is to keep the existing namespaces in the lout directory and just wrap them in another namespace "lout". This fixes the name collision with signal. Cheers, Johannes

2 1

I figured out why charset handling has been all broken lately.
by corvid＠lavabit.com April 26, 2008

April 26, 2008

The top of Nav_open_url has bool_t ForceReload = (URL_FLAGS(url) & (URL_E2EReload + URL_ReloadFromCache)); When repushing URLs, URL_FLAGS contains URL_ReloadFromCache, which is 0x100. And remember how Jorge changed bool_t from int to unsigned char? I'd forgotten about it, too, which meant I wasted some time looking in the wrong places for this bug.

3 2

patch: image loading on demand for complex button
by corvid＠lavabit.com April 26, 2008

April 26, 2008

(Jorge: Okay. That gives me an opportunity to put this in the priority queue instead.) I was able to get the menus to work for buttons and image inputs, so image loading can be conditional now. My usual disclaimer applies regarding the dw2 side that I did something that made it work, but it may not be the right way.

2 1

namespace problem
by Johannes.Hofmann＠gmx.de April 24, 2008

April 24, 2008

Hi, some time ago I already reported a compilation problem that currently only exists on DragonFlyBSD. The namespace "signal" in the lout library collides with a function declaration in /usr/include/signal.h. For some reason DragonFly happens to include signal.h indirectly. But the same problem will appear on Linux too once we should need signal.h somewhere. Just try to compile the following C++ file (g++ -c <file>): #include <signal.h> namespace signal { } I'd like to resolve this issue before release. I see two options: * rename namespace "signal" to "loutsignal" - which is pretty ugly. The concept of namespaces exists to avoid such stuff... * put all classes in the lout directory into a single namespace "lout". At the moment I prefer the second option, but I don't know Sebastian's reasoning behind this naming. Any opinions? Cheers, Johannes

2 1

dillo-fltk exits on SIGPIPE
by Johannes.Hofmann＠gmx.de April 23, 2008

April 23, 2008

Hi, do you also see exits on SIGPIPE e.g. on: http://daily.daemonnews.org dillo 1 had signal(SIGPIPE, SIG_IGN); which dillo-fltk is missing. Cheers, Johannes

3 2

Good news from fltk!
by Johannes.Hofmann＠gmx.de April 19, 2008

April 19, 2008

Hi, I stumbled across this post on fltk.bugs: http://fltk.org/newsgroups.php?s5281+gfltk.bugs+v5290+T0 This is great for us, as it allows us to implement efficient double buffering without X11 specific hacks. Attached is a patch that enables double buffering for partial screen redraws (this is where the flickering is most annoying). You will need at least version r6079 of fltk2 to test. Cheers, Johannes

4 27

Collapsing whitespace
by jcid＠dillo.org April 17, 2008

April 17, 2008

Hi, Just submitted a patch I wanted to make long ago. It deals with collapsing whitespace. Here's one example: http://www.w3.org/TR/REC-html40/intro/sgmltut.html#h-3.2.1 BTW, I also changed the bool_t to "unsigned char". Please test whether it compiles cleanly. -- Cheers Jorge.-

2 1

Re: patch: BUTTON
by jcid＠dillo.org April 15, 2008

April 15, 2008

On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > The old code showed uncertainty about whether one can interact with the > stuff inside a button. The spec doesn't say. I suspect you aren't > supposed to be able to. Firefox doesn't let you. If FF doesn't allow interaction it will be hardly found in the WEB, unless IE allows. :-P > When trying to look up info on button nesting, I discovered -- by crashing -- > that I needed to test whether I was in a form. However, I learned that > section 17.2.1 says: > > "The elements used to create controls generally appear inside a FORM element, > but may also appear outside of a FORM element declaration when they are used > to build user interfaces. This is discussed in the section on intrinsic > events. [p.254] Note that controls outside a form cannot be successful > controls [p.245]." > > ..but I'll make a separate patch for controls outside of forms. AFAICS this may be useful with client side scripts, but we're a long way from suporting scripts. -- Cheers Jorge.-

2 1

[patch] fix cookies freezing dillo problem
by akemnade＠tzi.de April 15, 2008

April 15, 2008

Hi, after some debugging I found out that dillo was frozen because it waits for input on the unix socket from the cookies.dpi. cookies.dpi itself blocks on the read() on the connection socket. If you kill dillo and stop dpid, the next time the cookies.dpi starts, it finds the cookies files locked and terminates immedediately. Then dpid starts the cookies.dpi again and again in an infinite loop. In my theory, the freeze where both processes are hanging in read() is caused when a connection is creating via DEBUG_MSG(5, "Cookies.c: a_Cookies_set \n\t \"%s\" \n",cmd ); a_Capi_dpi_send_cmd(NULL, NULL, cmd, "cookies", 1); but the data is not send yet and /* Get the answer from cookies.dpi */ dpip_tag = a_Dpi_send_blocking_cmd("cookies", cmd); is called. I have attached a patch which uses a_Dpi_send_blocking_cmd(). It seems to fix the problem. dillo has not been frozen again yet. Maybe cookies.dpi should create the SockHandler only when there is data to read (checking for it with select() first). Greetings Andreas Kemnade

2 3

patch: image inputs
by corvid＠lavabit.com April 15, 2008

April 15, 2008

It works on the sites I tried, and the data sent looks right for other cases, but: - To get click position, I used event_x() and event_y() in fltkui.cc because they happened to have the right values in them and I didn't know the proper place to look for this information. - If the image could not be loaded and you click on the alt text, the click position is sent, even though it's not meaningful. - I don't prevent the image from being loaded even when automatic image loading is disabled (but I'm the only person who would notice anyway). (I would have to be able to get button 3 to bring up the image menu.)

2 5

Re: patch: file input
by jcid＠dillo.org April 15, 2008

April 15, 2008

Hi, On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > I just stuck it on a label button for now. It looks quite informative. > Already an improvement over Firefox, where I only > find out that I mistyped the filename when the server > doesn't get the file. > > Somewhere that accepts files: http://validator.w3.org > > Edge case that I just noticed: > If I read in a file, delete that file, and try to read it in again > (uses E2EReload), the submit will send the (now empty) file because > a_Capi_get_buf() finds the (now empty) entry in cache. > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. Yes. Please also add a file size threshold, to avoid a dillo exit from an out of memory condition. Committed! -- Cheers Jorge.-

2 10

[patch] fix warning in html.cc
by Johannes.Hofmann＠gmx.de April 14, 2008

April 14, 2008

Hi, html.cc: In function 'void a_Html_form_event_handler(void*, form::Form*, void*)': html.cc:4331: warning: 'input' may be used uninitialized in this function can be fixed with attached patch. Please review. Cheers, Johannes

3 2

[patch] make ComplexButton work
by Johannes.Hofmann＠gmx.de April 14, 2008

April 14, 2008

Hi, this patch fixes ComplexButton - at least it works here now :-) The patch includes the ComplexButton destructor proposed by place and enables the ComplexButton code in dw-ui-test. It requires my last FltkViewBase::draw() patch. Cheers, Johannes

3 2

[patch] cleanup FltkViewBase::draw
by Johannes.Hofmann＠gmx.de April 13, 2008

April 13, 2008

Hi, here comes a cleanup of FltkViewBase::draw(). It had grown too complicated... This patch also fixes two issues with nested views as they will exist with ComplexButtons. Cheers, Johannes

2 1

Re: patch: reset input
by jcid＠dillo.org April 13, 2008

April 13, 2008

Hi, Committed -- Cheers Jorge.-

1 0

Re: patch: ISINDEX
by jcid＠dillo.org April 13, 2008

April 13, 2008

On Sun, Apr 13, 2008 at 02:33:00AM +0000, corvid wrote: > Yeah, so very important... > > An isindex page: http://www.math.ncu.edu.tw/~shann/bcc16/7/html/isindex.cgi > Committed! Mmmm, ISINDEX, an old method that brings me back good memories. -- Cheers Jorge.-

1 0

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again
by Christian.Kellermann＠nefkom.net April 11, 2008

April 11, 2008

Skipped content of type multipart/mixed

4 9

Re: patch: url encode, append input
by jcid＠dillo.org April 9, 2008

April 9, 2008

Hi, On Mon, Apr 07, 2008 at 02:26:14PM +0000, corvid wrote: > a_Url_encode_hex_str() needed to accept a Dstr* because it is not > illegal to use url encoding on a file. Maybe a situation that'll > never happen, but then again, it's easy to leave off enctype. In that case the behaviour is not specified. i.e. (from http://www.ietf.org/rfc/rfc1867.txt) 5.8 File transfer with ENCTYPE=x-www-form-urlencoded If a form contains <INPUT TYPE=file> elements but does not contain an ENCTYPE in the enclosing <FORM>, the behavior is not specified. It is probably inappropriate to attempt to URN-encode large quantities of data to servers that don't expect it. > (However, Firefox -- as if it's any authority on anything, but still -- > doesn't send file contents for URL encoded forms. It just sends > the filename.) Probably is not a bad idea to follow this lead or investigate a bit further on what IE, Safari or Opera do, and then decide. At least, I'd feel more comfortable with a file-size limit for both GET&POST, thus avoiding Dillo to exit because it can't allocate enough memory for sending a huge file. > Html_append_input() becomes a few functions (I'd never felt good > about sending a boundary arg for url encoding anyway). OK. -- Cheers Jorge.-

2 2

Re: patch: urldecode base64 data uri
by jcid＠dillo.org April 8, 2008

April 8, 2008

On Sun, Apr 06, 2008 at 07:01:52PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Apr 06, 2008 at 05:07:30AM +0000, corvid wrote: > > > I took a better look at the RFC and it looks like I am wrong. > > > > > > I naively assumed that since it's been on the acid site for however > > > many years, somebody would have complained if it wasn't right, > > > and I took relatively little care in rfc-checking. > > > > > > On the other hand, I am coming to learn that RFCs are > > > not perfectly perfect things. > > > > > > The relevant RFC text: > > > The appearance of ";base64" means that the data > > > is encoded as base64. Without ";base64", the data (as a sequence of > > > octets) is represented using ASCII encoding for octets inside the > > > range of safe URL characters and using the standard %xx hex encoding > > > of URLs for octets outside that range. > > > > > > http://www.webstandards.org/action/acid2/guide/ says of the square: > > > Also, there is a 64px by 64px red box in the background (represented > > > by the PNG image in the data url, not reprinted in full). The red > > > box is not visible as the background-attachment is set to 'fixed' > > > which puts the red box outside of view. > > > > > > (as opposed to saying that it's supposed to break or something) > > > > Which in what regards to the patch, means? > > > > a) keep > > b) revert > > - To me, a strict reading of the RFC says revert. > > - I see that http://developer.mozilla.org/en/docs/The_data_URL_scheme > gives their base64 example as > "data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D" > > - At http://simonwillison.net/2003/Aug/11/selfContained/ > Simon Proctor claimed that Mozilla didn't like the URL encoding, > and Ian Hickson asserted that it was necessary. > > - Ian Hickson would appear to be the guy who wrote the "data: URI kitchen" > (http://software.hixie.ch/utilities/cgi/data/data) which is apparently > the main datauri-maker that people use, as well as being the guy who wrote > the acid2 test. > > On one hand, this means that dillo will encounter the URL encoding. > > On the other hand, if Hickson has any actual persuasive argument for > his viewpoint, I have not found it. OK, reverted. -- Cheers Jorge.-

1 0

Re: patch: escape for display
by jcid＠dillo.org April 7, 2008

April 7, 2008

On Sun, Apr 06, 2008 at 11:08:13PM +0000, corvid wrote: > > I ponder having a: > > > > const char *dStr_printable(dStr *in, int maxlen) > > > > that returns a pointer to an internal static dStr. It has > > the advantage of minimal interface overhead. e.g. > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + MSG_WARN(" \"%s\"\n", dStr_printable(io->Buf, 2048)); > > > > of course it's not MT-safe, but we don't need it now. > > > > Implementing a MT-safe version is easy, but involves more > > calling overhead: > > > > dStr *dStr_printable(dStr *in, int maxlen) > > > > - MSG_WARN(" \"%s\"\n", io->Buf->str); > > + Dstr *printable = dStr_printable(io->Buf, 2048)); > > + MSG_WARN(" \"%s\"\n", printable->str)); > > + dStr_free(printable, 1); > > > > and disabling the message is not as clean as prepending an "_" > > to the macro. > > > > I'd go with the first alternative. > > Attached. > > I wasn't too sure about representation. Text has \x0D where ^M would > be much less surprising, but \x is easier to read for arbitrary bytes. > > It's funny that I had been calling truncation a bug and now I'm > truncating intentionally, but there is only so much a person > wants to see... Committed. -- Cheers Jorge.-

1 0

Re: patch: dStr_memmem
by jcid＠dillo.org April 6, 2008

April 6, 2008

Hi, Committed with a minor modification: /* * Return a pointer to the first occurrence of needle in haystack. */ char *dStr_memmem(Dstr *haystack, Dstr *needle) { int i; if (needle && haystack) { if (needle->len == 0) return haystack->str; for (i = 0; i <= (haystack->len - needle->len); i++) { - if (!memcmp(haystack->str + i, needle->str, needle->len)) + if (haystack->str[i] == needle->str[0] && + !memcmp(haystack->str + i, needle->str, needle->len)) return haystack->str + i; } } return NULL; } The idea is to avoid a 3 parameters function call per each checked character. Maybe it's even better to implement it without a function call (like dStristr()), but I haven't done any profiling so I'm not sure. It looks like an improvement though. ;-) -- Cheers Jorge.-

1 0

patch: FltkViewport::adjustScrollbarValues()
by corvid＠lavabit.com April 5, 2008

April 5, 2008

You know how the edges of pages like to hide under the scrollbars? This makes them stop doing that.

3 2

patch names
by jcid＠dillo.org April 2, 2008

April 2, 2008

Hi, Please submit your patches in this format: diff -pru dillo2 dillo2-cur > Patch-Name-Here.dillo2 diff -pru dw2 dw2-cur > Patch-Name-Here.dw2 -- Cheers Jorge.-

1 0

(place->corvid) popup menus
by corvid＠lavabit.com April 2, 2008

April 2, 2008

Got back to looking at why popup menus are offset by the height of the control panel, and // Make the popup a child of the calling UI object ((Group *)bw->ui)->add(pm); caught my eye. I thought perhaps if I made them children of Main instead, they would work. But first I tried commenting it out completely -- and now everything seems to work fine. The popups even remember the previous item chosen, which would allow the removal of click-to-load for images. Does anybody remember whether the add() call was for some reason that I haven't noticed? (Jorge cleared the moderation bit for me, so I think you will get this mail!)

3 6

From the BLFS project: [theoldfellow@gmail.com: Dillo - going, going....]
by onepoint＠starurchin.org March 31, 2008

March 31, 2008

The Beyond Linux From Scratch project is removing Dillo Classic because they don't want to list unsupported GTK1 applications (in fact they are looking to ditch GTK1 completely). They seem pretty keen on Dillo-FLTK though! Jeremy Henty ----- Forwarded message from TheOldFellow <theoldfellow(a)gmail.com> ----- From: TheOldFellow <theoldfellow(a)gmail.com> To: blfs-dev(a)linuxfromscratch.org Subject: Dillo - going, going.... Date: Mon, 31 Mar 2008 11:14:42 +0100 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.1 Well no one screamed that it was their favourite web browser, so I'll comment it out of the book later today. As an aside, I built Dillo2, still very alpha, with FLTK2, in Beta. The result is quite good. Lightning fast, and some nice features as a browser to build first and read BLFS with while you build the GTK2 and Firefox ziggurat. I'll put a wiki page together for it later too. R. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page ----- End forwarded message -----

1 0

[patch] scroll cleanup
by Johannes.Hofmann＠gmx.de March 31, 2008

March 31, 2008

Hello, as promised here comes my attempt to cleanup the scrolling code a bit. scrollTo () is now the real method and scroll () is just a helper. I think that is more natural than the other way round. I also moved the call to updateCanvasWidgets () out of the draw () method again as I think draw () should not modify things if possible. I hope I have not reintroduced the widget scrolling bug place has just fixed. Can you verify this? Cheers, Johannes

3 2

Re: patch: Cookies_parse_one()
by jcid＠dillo.org March 29, 2008

March 29, 2008

On Thu, Mar 27, 2008 at 05:27:18PM +0000, place wrote: > I had to turn on cookies to try something, and the very first cookie I > saw threw the dpi into an infinite loop. > "TRK%5FLastLoginID=; expires=Fri, 27-Mar-2009 04:00:00 GMT; path=/" > > Instead of returning immediately on error, it eats its broken cookie up now. > And I added some dFree(attr)s. Good, thanks for the fixes; it's much simpler to debug functions that have a single return point. Committed. > > Oh, and the "catched" in Cookies_parse_string() should be "caught". > Should've put that in the patch, but I forgot. Committed. -- Cheers Jorge.-

1 0

Re: a_Url_cmp()
by jcid＠dillo.org March 29, 2008

March 29, 2008

On Sat, Mar 29, 2008 at 04:25:42AM +0000, place wrote: > 1. I happened to run into a preexisting bug in a_Url_cmp(). > > I hooked up the dialog code as the others had done for https, and the > first URL I tried was a redirect that goes > http://something -> https://something. The urls are identical except for > the scheme. It broke because a_Url_cmp() has > > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme) == 0))) > instead of > (st = URL_STR_FIELD_I_CMP(A->scheme, B->scheme)) == 0)) Committed. > 2. The mail I tried to send some days back from my new account(*) also > happened to be about a_Url_cmp(). When I was playing with file inputs, > I generated the URL file:///something, with file:/something already in > cache. Cache did not find it because the authority of one was NULL and > the authority of the other was "". URL_STR_FIELD_I_CMP thinks those are > different things. Which is possible. Knowing how weird the URL spec gets, > the code might reflect a genuine difference, but sounds more like an error. Yes, current URL handling follows the spec. The problem is that the rest of dillo is using URLs like file:/something freely, when they should be file:///something. It should be easy to switch the file server dpi to generate "file:///"-prefixed URLS, and the input location to also normalize file:/ prefixed ones. But, if they appear in an external html page, it may be better to make the URL code normalize it (or check what other browsers do). > That I should run into these two issues at the very same time that I'm > trying to change a_Url_cmp() for url->data is a strange coincidence. Peer reviewing is always an asset. > > * And it receives list mail just fine. Andreas seemed to think that > as long as I'm subscribed, I shouldn't have any moderation problems. > Strange. Out of my control, anyway. I gave a look at the list settings. Please let me know your new email address to find whether I can do something to enable it. BTW, with the new patch for "missing widgets", when I first went to http://lists.auriga.wearlab.de/cgi-bin/mailman/admin/dillo-dev the Password input widget was missing! (it worked the next tries). -- Cheers Jorge.-

1 0

patch: widget scrolling
by place＠gobigwest.com March 29, 2008

March 29, 2008

I've had lots of trouble with widgets disappearing because my machine is too slow to keep up. But today I had the good fortune to happen to stumble upon updateCanvasWidgets()... Johannes, are there any unintended consequences to this fix?

3 3

patch: URL data as a Dstr
by place＠gobigwest.com March 29, 2008

March 29, 2008

This is part one in a series for file inputs. Parts two and three are written. Parts four and five are contemplated. Maybe a part six if I feel like it. Part three is the one that makes it at least appear to work, though I'll need help in testing at that point. HTTPS note: If https does remain a dpi, somebody will have to decide what they want to do with Capi_dpi_build_cmd() if http_query can contain NULLs.

2 1

ComplexButton crashing
by place＠gobigwest.com March 26, 2008

March 26, 2008

For you dw people... I am working on getting ComplexButton to work (image inputs), and it would segfault when I'd close the bw. In FltkComplexButtonResource::createNewWidget, the button's child is a view. When the button is destroyed, since the button is a Group, its children get destroyed. Later on, the layout is being destroyed, and it deletes TopLevel. The toplevel widget destructor calls layout->removeWidget(), which tries to iterate through the views. To make the problem go away, I added: fltkcomplexbutton.hh: ~ComplexButton() {remove_all();} but I don't know any of this code well enough to know what _should_ be going on.

2 4

removeIdle: *** [unknown] This should not happen! *** Aborted
by place＠gobigwest.com March 26, 2008

March 26, 2008

I think I mentioned this problem some time ago, but playing with ComplexButton makes it much worse (when meta charset causes a repush). The backtrace shows that it's unhappy because IdleFunc doesn't have an equals(). To make the problem go away, I changed the remove in FltkPlatform::removeIdle() to a removeRef, but, again, I don't know this code well enough to know what should be going on. #0 0x40344c81 in kill () from /lib/libc.so.6 #1 0x401b04a1 in pthread_kill () from /lib/libpthread.so.0 #2 0x401b087b in raise () from /lib/libpthread.so.0 #3 0x403448f8 in raise () from /lib/libc.so.6 #4 0x40345f00 in abort () from /lib/libc.so.6 #5 0x0809e054 in misc::assertNotReached () at misc.hh:67 #6 0x080ad6f1 in object::Object::equals (this=0x81ab118, other=0x81ab118) at object.cc:49 #7 0x080aa182 in container::untyped::List::remove0 (this=0x81c1b90, element=0x81ab118, compare=true, doNotDeleteAtAll=false) at container.cc:254 #8 0x080891c7 in container::untyped::List::remove (this=0x81c1b90, element=0x81ab118) at ../lout/container.hh:169 #9 0x080891eb in container::typed::List<dw::fltk::FltkPlatform::IdleFunc>::remo ve (this=0x81c1960, element=0x81ab118) at ../lout/container.hh:376 #10 0x08086968 in dw::fltk::FltkPlatform::removeIdle (this=0x81c1b68, idleId=1) at fltkplatform.cc:319 #11 0x0809feaa in ~Layout (this=0x81c1bf8) at layout.cc:117

3 3

Re: cache entry status
by jcid＠dillo.org March 26, 2008

March 26, 2008

On Sun, Mar 23, 2008 at 05:29:00PM +0000, place wrote: > This is what I've ended up with. I suspect you'll regard it as overengineered... A bit too complex, yes. Although most of it stems from a not so clear design isolation between cache, dicache, capi and the rest. BTW, I suspect the dicache may have obsolete parts. > I couldn't bring myself to call it is_cached when it returned various flags, > so it's entry_status. > > I didn't know what to do about testing for Aborted. Aborted is not yet implemented. I committed a modified version (hopefully simpler). > English: I was looking at some docs the other day, and I started to notice > that you use "there're" sometimes... It's perfectly normal in speech, but it > looks odd when written. Committed. -- Cheers Jorge.-

1 0

Re: patch: concatenate Dstrs
by jcid＠dillo.org March 24, 2008

March 24, 2008

Hi, On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > I made a dStr_dstrcat(). > What's the main advantage of it, over dStr_append_l() ? I see the convenience and clarity of passing two parameters instead of three, but on the other hand, keeping APIs reduced to a functional minimum, helps to remember and to choose the right function call. There may be a point I don't yet see... -- Cheers Jorge.-

2 5

https plugin status
by Christian.Kellermann＠nefkom.net March 24, 2008

March 24, 2008

Dear list, is the https plugin supposed to work? Whenever I select a https URL dpid gets started but nothing happens whatsoever. I do have SSL enabled and all. I am aware that there is some work needed and that https support is considered as very basic. But what is supposed to be working atm? It is easier to fix bugs if you know what it should look like... Thanks, Christian -- You may use my gpg key for replies: pub 1024D/47F79788 2005/02/02 Christian Kellermann (C-Keen)

4 12