- Dillo-dev - lists.mailman3.com

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