- Dillo-dev - lists.mailman3.com

Large Panel

by tuna＠supertunaman.com

On Sat, Apr 16, 2011 at 8:04 AM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > ?Does anybody use "panel_size=large" in dillorc? > > ?I'd like to remove the option in the 1.3 branch, and keep > tiny, small and medium. > Like Rob, I only just now knew about this. I agree with your decision, if there's only one pulldown menu, why have it on a separate bar? Kind of confused as to why it's called "File" though. I realize that's common for the first pulldown menu to be called 'File', but it doesn't make a whole lot of sense here. Why not just "Menu" like Opera? > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 16, 2011

HTML5

by mr_semantics＠hotmail.com

> From: mr_semantics(a)hotmail.com > To: dillo-dev(a)dillo.org > Date: Sat, 16 Apr 2011 12:09:39 -0400 > Subject: [Dillo-dev] HTML5 > > > Hello all, > Forgive me if this has been discussed before (I do not recall seeing it since I have been following the mailing list). I recently started experimenting with some HTML5 stuff on a page I maintain, and as expected, dillo indicated an error in the html source. You can see the page here: > http://www3.sympatico.ca/rsquared/gdb/ > The error is: "HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid)" > Now this does not surprise me at all, as I presume dillo is not expecting the new doctype declaration. Anyway, I thought I might raise this issue, and see what sort of mind the devs have about implementing HTML5 in dillo. Of course, I realise you fellows are probably up to your ears in the FLTK 1.3 port, but I thought this might make for an interesting discussion, if nothing else. To start off, I suppose the danger in implementing any of the new html stuff is that it is not standardised at all yet. See here for more: > http://en.wikipedia.org/wiki/HTML5#W3C_standardization_process > I guess the worry is that it could possibly be a bit of a moving target. > Rob Blast it! I just figured out how to build the new 1.3 port, and realised that you fellows have at least addressed the HTML5 issue in part. ? As an aside, with the new browser brings a different issue, which I will address a little later in a different thread.

April 16, 2011

HTML5

by mr_semantics＠hotmail.com

Hello all, Forgive me if this has been discussed before (I do not recall seeing it since I have been following the mailing list). ?I recently started experimenting with some HTML5 stuff on a page I maintain, and as expected, dillo indicated an error in the html source. ?You can see the page here: http://www3.sympatico.ca/rsquared/gdb/ The error is: "HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid)" Now this does not surprise me at all, as I presume dillo is not expecting the new doctype declaration. ?Anyway, I thought I might raise this issue, and see what sort of mind the devs have about implementing HTML5 in dillo. ?Of course, I realise you fellows are probably up to your ears in the FLTK 1.3 port, but I thought this might make for an interesting discussion, if nothing else. ?To start off, I suppose the danger in implementing any of the new html stuff is that it is not standardised at all yet. ?See here for more: http://en.wikipedia.org/wiki/HTML5#W3C_standardization_process I guess the worry is that it could possibly be a bit of a moving target. Rob

April 16, 2011

Large Panel

by mr_semantics＠hotmail.com

> Date: Sat, 16 Apr 2011 12:04:26 -0300 > From: jcid(a)dillo.org > To: dillo-dev(a)dillo.org > Subject: [Dillo-dev] Large Panel >? > Hi there, >? > Does anybody use "panel_size=large" in dillorc? >? > I'd like to remove the option in the 1.3 branch, and keep > tiny, small and medium.My apologies for sending that last email to your address, Jorge. ?I am part of another mailing list, where when I hit reply it goes to the list, instead of the sender. ?I should look into changing this somehow with my email, as this is not the first time I have made this mistake. ?Anyway, as to my thoughts on the large panel size... I had actually been using the default, and had completely forgotten that you could change this. ?Now that you brought it up, I think I will be using the "tiny" setting. ?Long story short, you would have no objection from me if you got rid of the large setting. Rob?

April 16, 2011

Large Panel

by jcid＠dillo.org

Hi there, Does anybody use "panel_size=large" in dillorc? I'd like to remove the option in the 1.3 branch, and keep tiny, small and medium. -- Cheers Jorge.-

April 16, 2011

Question about local file browsing

by rogutes＠googlemail.com

Benjamin Johnson (2011-04-09 14:17): <...snip...> > One other thing that concerns me: a Windows user might start Dillo, > see a bunch of unfamiliar DPI programs running, and worry that it's > some kind of virus/spyware infection. Even if someone explained > that it's just part of the browser, they might not be convinced, > since -- say -- Firefox doesn't start all that stuff in the > background. Spyware is increasingly a very real and very serious > concern, so many users are justifiably suspicious of anything even > remotely out of the ordinary. Firefox does start some stuff in the background (plugin-container.exe, since Firefox 3.6.4). Though your point seems to be valid, at least on Windows: http://google.com/search?q=plugin-container.exe -- -- Rogut?s Sparnuotos

April 9, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

On Sat, 09 Apr 2011 13:52:43 -0400, corvid <corvid(a)lavabit.com> wrote: > Benjamin wrote: >> A much more practical solution, as far as I'm concerned, is simply to >> build that functionality into the browser: >> - It's simpler, since there's on interprocess communication required. >> - It's more portable, for the same reason. >> - It's easier to distribute, since you only need one executable. > > I personally like the idea of dillo in one piece. I think a lot of > people who give it a try don't get dillo + dpid + the dpis talking > to each other correctly, and then they don't want to waste their > time fighting with a random unfamiliar computer program. Personally, I'm not opposed to DPI in and of itself. I think it's an interesting extension mechanism, but I'd like it to remain just that -- a way of extending the browser. I don't think it should be used to offload major functionality that any reasonable user would expect to come built in. One other thing that concerns me: a Windows user might start Dillo, see a bunch of unfamiliar DPI programs running, and worry that it's some kind of virus/spyware infection. Even if someone explained that it's just part of the browser, they might not be convinced, since -- say -- Firefox doesn't start all that stuff in the background. Spyware is increasingly a very real and very serious concern, so many users are justifiably suspicious of anything even remotely out of the ordinary. Of course, I know I'm still in the minority here, which is why I just keep hacking away at it and try to let my code speak for itself. :-) ~Benjamin

April 9, 2011

Question about local file browsing

by corvid＠lavabit.com

Benjamin wrote: > A much more practical solution, as far as I'm concerned, is simply to > build that functionality into the browser: > - It's simpler, since there's on interprocess communication required. > - It's more portable, for the same reason. > - It's easier to distribute, since you only need one executable. I personally like the idea of dillo in one piece. I think a lot of people who give it a try don't get dillo + dpid + the dpis talking to each other correctly, and then they don't want to waste their time fighting with a random unfamiliar computer program. (Semi-relevant: I'm trying softphone programs out now, and they all demand lots of everything, and I can't tell which ones are worth how much trouble.)

April 9, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

On Thu, 07 Apr 2011 03:53:01 -0400, Diego . <darkspirit5000(a)gmail.com> wrote: > I will try to explain some reasons > > 1 DPI system avoid duplicate code and complex share and sync code. > 2 It is a universal solution. It can be used for file, cookies, etc. > 3 Each new open dillo have access to previous running DPIs. > 4 Isolates DPIs and dillos each in a process. > > I think DPI system could be better too. It is not a fully stabilised > API too. And there is no docs or SDK to write DPIs > > More in detail: > 1.a: > With built-in local file browsing each dillo running have the code for > it. The most of the time that code is not used an each dillo waste > that mem. > With DPIs it is only loaded when needed and unloaded if not. > In the file case the DPI is a high performance solution (threads) that > in dillo can be a waste of mem, but not in an external DPI (you can > write and use other file DPI focused for mem saving) A couple extra kilobytes for file browsing is not wasteful, IMHO. If space is that tight, like in an embedded device, it could easily be #define'd out and added as a ./configure option, like with cookies. As I understand it, most of the memory used by local file browsing is dynamically allocated, anyway; it's not like those DilloDirs stay in memory for all eternity. There's a LOT of duplicate code in DPI -- it's just *different* duplicate code. For example, each one has to implement signal handling, authentication, etc., not to mention the mess of interprocess communication. There's also the added overhead of each separate DPI process, and the DPI daemon itself. > 1.b: > With the cookies the DPI system avoid code in dillo to share write in > the cookies file. It makes easy to debug cookies (an other paralles > code) with varios dillos. This is the example everyone uses to point out DPI's "strengths". Well, I've looked at the cookies code, and I'm going to call bullshit. 1) The cookies file is only accessed twice: to read cookies when the browser opens, and to write them when it closes. It doesn't need to be open at any other time. 2) As I understand the code, if multiple Dillo instances are running, all but the first won't have cookies anyway. 3) Here's the real kicker: *you don't need the cookies file*. Here's the code to prove it: http://dillo-win32.sourceforge.net/files/23-dillo-r1803.cookies.diff This is a long patch, but basically it removes the cookies DPI; integrates the code into the browser (fairly straightforward, because src/cookies.c already duplicates large chunks of the DPI verbatim -- what's this about redundant code, again?); and changes it to not read/write cookies from/to disk. That last part is trivial: just initialize the cookies file pointer to NULL, check for a file pointer before any read/write operations, and don't abort if there is no file pointer in a_Cookies_init. Dillo holds cookies in memory while running anyway, so again, *it doesn't need a cookies file* except for persistence between sessions. By the way, holding cookies in memory has several advantages. For one thing, it's a better balance between functionality and privacy, because you can access cookie-dependent sites without leaving traces on your disk. For another, if you have multiple Dillo instances running, the "redundancy" (read: isolation) can be a good thing. I often have two separate instances running, one for each of my Gmail accounts. Speaking of which, I've also moved HTTPS in-browser. Rather than re-implementing the HTTP engine as the DPI seems to do, I simply added transparent SSL support to dSock, my Winsock/BSD sockets portability wrapper. It required some nastiness to support the HTTP CONNECT command for proxying, since that has to be sent in plain text, but otherwise it needed only minimal patching; once you tell dSock to go secure, it will automatically call the SSL-enabled read/write functions for you. Here's the patch for that: http://dillo-win32.sourceforge.net/files/22-dillo-r1803.https.3.diff > 2: > With DPI system you dont need to do one thing for protocols, other for > downloads, other for cookies, etc. Each thing is a diferent problem, > but is handled in a similar way. src/capi.c, src/cookies.c, and various other source files beg to differ; those two in particular are very poor examples, since they're called from separate source files, under completely different circumstances, in completely different ways. In other words, you do one thing for protocols, ... I vaguely recall that my built-in downloader took only one function call to start, as opposed to at least three for the DPI (it cleans itself up automatically). It also has no external dependency on wget, or any interprocess communication for that matter. > 3: > All different process dillos (dillos running in different process) > have the same access to data an code of DPIs. Is it easy to share DPIs > processed data and functions of DPIs. > What dillo run a external program or what dillo process have the data > never mind if it is done with a DPI. What part of the DPI code do you consider "easy"? Interprocess communication is messy enough as it is, let alone the way DPI implements it. > 4: > If a process crash the other DPIs and the other dillo process continue > running. If it is a DPI it is re-run and the work continues (there is > a bug in the code: sometimes a defunct DPI can block a dillo) If a process is properly coded, it should never crash in the first place. I'm just saying. > About DPI system faults: > - Documentation > - Changing API and protocol > - Do not work on windows > - Try to simplify protocol, API and code > > There is a lot to talk to do better DPI system. Maybe you and me can > try to have DPI running in windows. I've considered porting DPI. The problem is, interprocess communication is completely different on Windows, and the best case scenario is that porting it would require a complete API overhaul. (Though I understand the API changes in every release anyway, so I suppose that isn't much of a problem.) A much more practical solution, as far as I'm concerned, is simply to build that functionality into the browser: - It's simpler, since there's on interprocess communication required. - It's more portable, for the same reason. - It's easier to distribute, since you only need one executable. I'm especially insistent on the last point. With all dependencies statically linked, I've got my port down to a single executable, and I hope to keep it that way. Up until the last release, you could fit the entire browser on a floppy disk -- and it's only bigger now because of OpenSSL, not because of anything in Dillo itself. (I've looked at the embedded libraries like yaSSL, which are much smaller, but I can't find a reliable download link.) Anyway, that's my two cents. ~Benjamin

April 7, 2011

Question about local file browsing

by darkspirit5000＠gmail.com

I will try to explain some reasons 1 DPI system avoid duplicate code and complex share and sync code. 2 It is a universal solution. It can be used for file, cookies, etc. 3 Each new open dillo have access to previous running DPIs. 4 Isolates DPIs and dillos each in a process. I think DPI system could be better too. It is not a fully stabilised API too. And there is no docs or SDK to write DPIs More in detail: 1.a: With built-in local file browsing each dillo running have the code for it. The most of the time that code is not used an each dillo waste that mem. With DPIs it is only loaded when needed and unloaded if not. In the file case the DPI is a high performance solution (threads) that in dillo can be a waste of mem, but not in an external DPI (you can write and use other file DPI focused for mem saving) 1.b: With the cookies the DPI system avoid code in dillo to share write in the cookies file. It makes easy to debug cookies (an other paralles code) with varios dillos. 2: With DPI system you dont need to do one thing for protocols, other for downloads, other for cookies, etc. Each thing is a diferent problem, but is handled in a similar way. 3: All different process dillos (dillos running in different process) have the same access to data an code of DPIs. Is it easy to share DPIs processed data and functions of DPIs. What dillo run a external program or what dillo process have the data never mind if it is done with a DPI. 4: If a process crash the other DPIs and the other dillo process continue running. If it is a DPI it is re-run and the work continues (there is a bug in the code: sometimes a defunct DPI can block a dillo) About DPI system faults: - Documentation - Changing API and protocol - Do not work on windows - Try to simplify protocol, API and code There is a lot to talk to do better DPI system. Maybe you and me can try to have DPI running in windows. Diego. 2011/4/7, Benjamin Johnson <obeythepenguin(a)gmail.com>: > I'm sure this has been asked before, but why on earth is something so > basic as local file browsing implemented through the (ludicrously > complicated, IMHO) DPI system rather than built in to the program? > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 7, 2011

Question about local file browsing

by obeythepenguin＠gmail.com

I'm sure this has been asked before, but why on earth is something so basic as local file browsing implemented through the (ludicrously complicated, IMHO) DPI system rather than built in to the program? ~Benjamin

April 7, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

Jeremy Henty wrote: > Jeremy Henty wrote: > > > > corvid wrote: > > > > > Probably reads the 0.1 as 0 and does the same bad thing we usually > > > get when we have 0 and don't have a URL argument sending us > > > somewhere else... > > > > So the bug is that Html_tag_open_meta() does not check that it has > > found a URL before doing the redirect? Does the attached patch look > > sensible? (The patch is a little messy, but all it does is wrap the > > redirect code in a "if (*content) { ... }".) > > Bump. > > Is this patch OK? OK, seeing as the patch is so simple and no-one has objected I have crossed my fingers and pushed it. Regards, Jeremy Henty

March 31, 2011

Re: Dillo-dev Digest, Vol 67, Issue 20

by jcid＠dillo.org

On Tue, Mar 29, 2011 at 01:21:48AM +1100, Purgatori Sakkara wrote: > > I hope that I am not sending this to the wrong place or anything, but I > just wanted to express my sincere gratitude to all the people working on > this, the great browser around :) Thanks a lot for your words! @devs: you may also read: http://gopherproxy.org/sdf.org/0/users/mrgnash/phlog/15-03-2011.txt (by the same poster) -- Cheers Jorge.-

March 28, 2011

Re: Dillo-dev Digest, Vol 67, Issue 20

by mrgnash＠sdf.lonestar.org

I hope that I am not sending this to the wrong place or anything, but I just wanted to express my sincere gratitude to all the people working on this, the great browser around :)

March 28, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Sun, Mar 27, 2011 at 03:56:27PM +0100, Jeremy Henty wrote: > Johannes Hofmann wrote: > > > Just for the record, normally it's better to make general changes > > and bugfixes to the main branch and merge them into development > > branches. > > "main" being FLTK 2.0 and "development" being FLTK 1.3, is that right? right > > Who is responsible for merging changes into development? So far I > have been thinking only about the 2.0 branch and treating 1.3 as > someone else's problem. Is that fair or should I be checking that my > changes merge into the 1.3 bramnch too? No, that's fine. Merging into development branches should be done by the developer who feels responsible for that branch. Cheers, Johannes

March 27, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Johannes Hofmann wrote: > Just for the record, normally it's better to make general changes > and bugfixes to the main branch and merge them into development > branches. "main" being FLTK 2.0 and "development" being FLTK 1.3, is that right? Who is responsible for merging changes into development? So far I have been thinking only about the 2.0 branch and treating 1.3 as someone else's problem. Is that fair or should I be checking that my changes merge into the 1.3 bramnch too? Regards, Jeremy Henty

March 27, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Sun, Mar 27, 2011 at 10:30:10AM +0100, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > On Sat, Mar 26, 2011 at 09:30:37AM +0000, Jeremy Henty wrote: > > > > > > So how do we fix 2.0? With my latest patch? Or should we port > > > yours from 1.3 to 2.0? > > > > From a quick review they're the same. > > The one you posted surely applies cleanly to 2.0. > > Just commit it. > > OK, it's done. Just for the record, normally it's better to make general changes and bugfixes to the main branch and merge them into development branches. But for simple stuff like this it doesn't really matter. Cheers, Johannes

March 27, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

Jeremy Henty wrote: > > corvid wrote: > > > Probably reads the 0.1 as 0 and does the same bad thing we usually > > get when we have 0 and don't have a URL argument sending us > > somewhere else... > > So the bug is that Html_tag_open_meta() does not check that it has > found a URL before doing the redirect? Does the attached patch look > sensible? (The patch is a little messy, but all it does is wrap the > redirect code in a "if (*content) { ... }".) Bump. Is this patch OK? Regards, Jeremy Henty > # HG changeset patch > # Parent f3e1b0b004c5748988a344d68b80807495ef55d2 > html.cc: Html_tag_open_meta(): check that the URL exists before redirecting. > > > diff -r f3e1b0b004c5 -r 1fb8f2b486fa src/html.cc > --- a/src/html.cc Sat Jan 08 17:56:56 2011 +0000 > +++ b/src/html.cc Mon Mar 21 07:49:47 2011 +0000 > @@ -2868,42 +2868,45 @@ > } > /* Skip to anything after "URL=" */ > while (*content && *(content++) != '=') ; > - /* Handle the case of a quoted URL */ > - if (*content == '"' || *content == '\'') { > - if ((p = strchr(content + 1, *content))) > - mr_url = dStrndup(content + 1, p - content - 1); > - else > - mr_url = dStrdup(content + 1); > - } else { > - mr_url = dStrdup(content); > + if (*content) { > + > + /* Handle the case of a quoted URL */ > + if (*content == '"' || *content == '\'') { > + if ((p = strchr(content + 1, *content))) > + mr_url = dStrndup(content + 1, p - content - 1); > + else > + mr_url = dStrdup(content + 1); > + } else { > + mr_url = dStrdup(content); > + } > + > + if (delay == 0) { > + /* zero-delay redirection */ > + html->stop_parser = true; > + DilloUrl *new_url = a_Url_new(mr_url, URL_STR(html->base_url)); > + if (a_Capi_dpi_verify_request(html->bw, new_url)) > + a_UIcmd_redirection0((void*)html->bw, new_url); > + a_Url_free(new_url); > + } else { > + /* Send a custom HTML message. > + * TODO: This is a hairy hack, > + * It'd be much better to build a widget. */ > + Dstr *ds_msg = dStr_sized_new(256); > + dStr_sprintf(ds_msg, meta_template, mr_url, delay_str); > + { > + int o_InFlags = html->InFlags; > + int o_TagSoup = html->TagSoup; > + html->InFlags = IN_BODY; > + html->TagSoup = false; > + Html_write_raw(html, ds_msg->str, ds_msg->len, 0); > + html->TagSoup = o_TagSoup; > + html->InFlags = o_InFlags; > + } > + dStr_free(ds_msg, 1); > + } > + dFree(mr_url); > } > > - if (delay == 0) { > - /* zero-delay redirection */ > - html->stop_parser = true; > - DilloUrl *new_url = a_Url_new(mr_url, URL_STR(html->base_url)); > - if (a_Capi_dpi_verify_request(html->bw, new_url)) > - a_UIcmd_redirection0((void*)html->bw, new_url); > - a_Url_free(new_url); > - } else { > - /* Send a custom HTML message. > - * TODO: This is a hairy hack, > - * It'd be much better to build a widget. */ > - Dstr *ds_msg = dStr_sized_new(256); > - dStr_sprintf(ds_msg, meta_template, mr_url, delay_str); > - { > - int o_InFlags = html->InFlags; > - int o_TagSoup = html->TagSoup; > - html->InFlags = IN_BODY; > - html->TagSoup = false; > - Html_write_raw(html, ds_msg->str, ds_msg->len, 0); > - html->TagSoup = o_TagSoup; > - html->InFlags = o_InFlags; > - } > - dStr_free(ds_msg, 1); > - } > - dFree(mr_url); > - > } else if (!dStrcasecmp(equiv, "content-type") && > (content = a_Html_get_attr(html, tag, tagsize, "content"))) { > _MSG("Html_tag_open_meta: content={%s}\n", content); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 27, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Sat, Mar 26, 2011 at 09:30:37AM +0000, Jeremy Henty wrote: > > > > So how do we fix 2.0? With my latest patch? Or should we port > > yours from 1.3 to 2.0? > > From a quick review they're the same. > The one you posted surely applies cleanly to 2.0. > Just commit it. OK, it's done. Regards, Jeremy Henty

March 27, 2011

[bug]: CSS image crash

by jcid＠dillo.org

On Sat, Mar 26, 2011 at 09:30:37AM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > On Fri, Mar 25, 2011 at 06:12:48PM +0000, Jeremy Henty wrote: > > > > > > Jorge Arellano Cid wrote: > > > > > > > Patch committed (just typos). > > > > > > Is it pushed? I just did a pull and got nothing newer than a > > > commit from corvid on Feb 11th. > > > > Yes, in the 1.3 branch. > > So how do we fix 2.0? With my latest patch? Or should we port yours > from 1.3 to 2.0? From a quick review they're the same. The one you posted surely applies cleanly to 2.0. Just commit it. -- Cheers Jorge.-

March 26, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > On Fri, Mar 25, 2011 at 06:12:48PM +0000, Jeremy Henty wrote: > > > > Jorge Arellano Cid wrote: > > > > > Patch committed (just typos). > > > > Is it pushed? I just did a pull and got nothing newer than a > > commit from corvid on Feb 11th. > > Yes, in the 1.3 branch. So how do we fix 2.0? With my latest patch? Or should we port yours from 1.3 to 2.0? Regards, Jeremy Henty

March 26, 2011

[bug]: CSS image crash

by jcid＠dillo.org

On Fri, Mar 25, 2011 at 06:12:48PM +0000, Jeremy Henty wrote: > > Jorge Arellano Cid wrote: > > > Patch committed (just typos). > > Is it pushed? I just did a pull and got nothing newer than a commit > from corvid on Feb 11th. Yes, in the 1.3 branch. -- Cheers Jorge.-

March 25, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > Patch committed (just typos). Is it pushed? I just did a pull and got nothing newer than a commit from corvid on Feb 11th. Regards, Jeremy Henty

March 25, 2011

[bug]: CSS image crash

by jcid＠dillo.org

On Wed, Mar 23, 2011 at 08:56:53PM +0100, Johannes Hofmann wrote: > On Tue, Mar 22, 2011 at 04:04:06PM +0000, Jeremy Henty wrote: > > > > OK, patch attached. Please comment. I just added checks for a NULL > > borderColor.top where necessary. I am still not sure if the > > drawBorder* functions are doing exactly the right thing but at the > > least the patch stops the crash and I don't think it makes the > > behaviour any worse. > > > > Please comment, > > To me the references to style->borderColor.top in drawBorder*() other > than drawBorderTop() look like a typo, but I might be wrong. > Jorge, can you please have a look? Patch committed (just typos). I took some time to review it because borders are not simple. There's pixel matching, the case of simulated "collapsing" mode with asymmetric tricks, etc. Funny how we all were looking at it at the same time. :-) Attached goes an example that shows the corrected flaws. -- Cheers Jorge.-

March 25, 2011

[bug]: CSS image crash

by jcid＠dillo.org

On Wed, Mar 23, 2011 at 08:56:53PM +0100, Johannes Hofmann wrote: > On Tue, Mar 22, 2011 at 04:04:06PM +0000, Jeremy Henty wrote: > > > > OK, patch attached. Please comment. I just added checks for a NULL > > borderColor.top where necessary. I am still not sure if the > > drawBorder* functions are doing exactly the right thing but at the > > least the patch stops the crash and I don't think it makes the > > behaviour any worse. > > > > Please comment, > > To me the references to style->borderColor.top in drawBorder*() other > than drawBorderTop() look like a typo, but I might be wrong. > Jorge, can you please have a look? I'm checking it now... -- Cheers Jorge.-

March 24, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Johannes Hofmann wrote: > ... I made a test case > (http://www.dillo.org/css_compat/tests/border-color.html) and it > looks wrong when compared e.g. with firefox, so I guess it's a typo. That is very convincing. I find that changing the drawBorderFoo() functions to use only the foo color fixes the crash *and* gives the same results as Firefox. <charlie_sheen>BI-WINNING!!!</charlie_sheen> I withdraw the previous patch and attach a new one. Thanks for the test case. Regards, Jeremy Henty

March 24, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Wed, Mar 23, 2011 at 10:10:35PM +0000, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > To me the references to style->borderColor.top in drawBorder*() > > other than drawBorderTop() look like a typo, > > I thought so too at first but it's less simple than I realised. The > challenge is rendering borders in fancy styles. Check out the > examples[1]. It is not obvious to me how to choose the right colors. > > The CSS spec does not help[2] - it leaves the choice of colors up to > the user agent. It gives informal descriptions of the border styles > but they really just say "it must look how it should obviously look". Yeah, I also remember something like that, but I made a test case (http://www.dillo.org/css_compat/tests/border-color.html) and it looks wrong when compared e.g. with firefox, so I guess it's a typo. Regards, Johannes

March 24, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Johannes Hofmann wrote: > To me the references to style->borderColor.top in drawBorder*() > other than drawBorderTop() look like a typo, I thought so too at first but it's less simple than I realised. The challenge is rendering borders in fancy styles. Check out the examples[1]. It is not obvious to me how to choose the right colors. The CSS spec does not help[2] - it leaves the choice of colors up to the user agent. It gives informal descriptions of the border styles but they really just say "it must look how it should obviously look". Regards, Jeremy Henty [1] http://www.dillo.org/css_compat/tests/border-style.html [2] http://www.w3.org/TR/CSS2/box.html - search for "8.5.3 Border style:"

March 23, 2011

[bug]: CSS image crash

by Johannes.Hofmann＠gmx.de

On Tue, Mar 22, 2011 at 04:04:06PM +0000, Jeremy Henty wrote: > > OK, patch attached. Please comment. I just added checks for a NULL > borderColor.top where necessary. I am still not sure if the > drawBorder* functions are doing exactly the right thing but at the > least the patch stops the crash and I don't think it makes the > behaviour any worse. > > Please comment, To me the references to style->borderColor.top in drawBorder*() other than drawBorderTop() look like a typo, but I might be wrong. Jorge, can you please have a look? Cheers, Johannes

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Wed, Mar 23, 2011 at 03:25:24PM +0000, Jeremy Henty wrote: > Jorge Arellano Cid wrote: > > > AFAIS, by now dillo_port1.3 branch is as usable (or better) as > > fltk2-based dillo. :-) > > Is there going to be another release of dillo-fltk2? Most probably yes. AFAIS there's not much of a point in making it _right now_, as FLTK2 will not be released. I believe a good time to make a dillo-fltk2 release is just after fltk-1.3 is released. That way we can inform users we'll be developing the fltk-1.3-based branch, and point them to the new repo. The big news is that once FLTK-1.3 is released, it will make its way into distros, making dillo accessible via package manager at some not-too-distant point in time. -- Cheers Jorge.-

March 23, 2011

Test case for a possible fltk1.3 bug

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > AFAIS, by now dillo_port1.3 branch is as usable (or better) as > fltk2-based dillo. :-) Is there going to be another release of dillo-fltk2? Regards, Jeremy Henty

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Tue, Mar 22, 2011 at 04:29:05PM -0300, Jorge Arellano Cid wrote: > On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > > Hi Jorge, > > > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > Please help me with this one. > > > > > > > > Attached goes a small program that shows what may be a bug in > > > > fltk-1.3: > > > > > > > > * resize the window back and forth and both "Group 1" and > > > > "Group 2" keep their heights. OK here. > > > > * With a small window, hide "Group 2" and resize to a big > > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > > > > My doubts are: > > > > > > > > Is this intended or a bug? > > > > If not a bug, how is the desired behaviour suppossed to be > > > > implemented? > > > > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > > the code clean. > > > > > > > > What do you think? > > > > > > Your test program shows even weirder behaviour with dwm here. > > > Initially the buttons are not visible and then scale in strange > > > ways. > > > I think this is because dwm is resizing the window as it is created. > > > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > > to get something running. > > > > Please check the attached modified version of your test program. > > Does the CustPack class solve your problem? > > It's quite similar to current CustGroup, the good news is that > resizing the hidden widgets to 0,0 avoids Fl_Group resizing them > later! Now we don't have to remove/re-add them to the group. > > This may be our workaround (not as hackish as current code). I > was thinking of fullscreen mode, and having to remove groups of > widgets to avoid the hidden resize. > > I'll forward the email to Matthias Melcher, because I still > can't believe the current resize behaviour is intended. Yesterday I wrote Matthias Melcher, and he told me he was going to review the issue. In the meanwhile (which can be long) I just committed a simple patch to make fullscreen work again (it uses the size(0,0) trick) AFAIS, by now dillo_port1.3 branch is as usable (or better) as fltk2-based dillo. :-) -- Cheers Jorge.-

March 23, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > Please help me with this one. > > > > > > Attached goes a small program that shows what may be a bug in > > > fltk-1.3: > > > > > > * resize the window back and forth and both "Group 1" and > > > "Group 2" keep their heights. OK here. > > > * With a small window, hide "Group 2" and resize to a big > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > My doubts are: > > > > > > Is this intended or a bug? > > > If not a bug, how is the desired behaviour suppossed to be > > > implemented? > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > the code clean. > > > > > > What do you think? > > > > Your test program shows even weirder behaviour with dwm here. > > Initially the buttons are not visible and then scale in strange > > ways. > > I think this is because dwm is resizing the window as it is created. > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > to get something running. > > Please check the attached modified version of your test program. > Does the CustPack class solve your problem? It's quite similar to current CustGroup, the good news is that resizing the hidden widgets to 0,0 avoids Fl_Group resizing them later! Now we don't have to remove/re-add them to the group. This may be our workaround (not as hackish as current code). I was thinking of fullscreen mode, and having to remove groups of widgets to avoid the hidden resize. I'll forward the email to Matthias Melcher, because I still can't believe the current resize behaviour is intended. -- Cheers Jorge.-

March 22, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

On Mon, Mar 21, 2011 at 09:23:37PM +0100, Johannes Hofmann wrote: > On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > > Hi Jorge, > > > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > Please help me with this one. > > > > > > Attached goes a small program that shows what may be a bug in > > > fltk-1.3: > > > > > > * resize the window back and forth and both "Group 1" and > > > "Group 2" keep their heights. OK here. > > > * With a small window, hide "Group 2" and resize to a big > > > window, then show "Group 2". It grew while hidden!? > > > > > > > > > My doubts are: > > > > > > Is this intended or a bug? > > > If not a bug, how is the desired behaviour suppossed to be > > > implemented? > > > > > > > > > I know an ugly way to workaround it (used with the findbar), > > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > > the code clean. > > > > > > What do you think? > > > > Your test program shows even weirder behaviour with dwm here. > > Initially the buttons are not visible and then scale in strange > > ways. > > I think this is because dwm is resizing the window as it is created. > > > > I suggest we don't use Fl_Pack and make our own solution. I will try > > to get something running. > > Please check the attached modified version of your test program. > Does the CustPack class solve your problem? Thanks for the code, I'll check it. I also had to resort to a superclass for horizontal groups in the UI (see rearrange()) BTW, I wrote to Michael Sweet (got no answer so far), because I can't believe something so simple as hidding a widget can be as convoluted as it is now. -- Cheers Jorge.-

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

OK, patch attached. Please comment. I just added checks for a NULL borderColor.top where necessary. I am still not sure if the drawBorder* functions are doing exactly the right thing but at the least the patch stops the crash and I don't think it makes the behaviour any worse. Please comment, Regards, Jeremy Henty

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Jeremy Henty wrote: > If you point dillo at http://www.youtube.com/user/zynaddsubfx and > scroll down then Dillo will crash before you get to the bottom. > [...] > > GDB shows that the drawing code is dereferencing a NULL FltkColor*: OK, StyleEngine::apply() in styleengine.cc sets border colors to NULL when the corresponding CSS property is transparent. Which seems OK. These are used by static functions drawBorder{Top,Left,Bottom,Right}() in dw/style.cc . These functions are clearly intended to handle NULL colors, eg. drawBorderTop() checks whether style->borderColor.top is NULL, and similarly for the others. The bug is that some of these functions may (depending on style->borderStyle) dereference other members of style->borderColor without checking whether they are NULL. In particular: *) drawBorderBottom() may reference style->borderColor.top *) drawBorderLeft() may reference style->borderColor.top So I guess the fix is to add extra guards to the code paths where other members of style->borderColor are referenced. I am puzzled by the lack of symmetry between these functions. Why do drawBorder{Bottom,Left}() sometimes use style->borderColor.top, yet drawBorder{Top,Right} only ever use their *own* color? (This is all specific to FLTK-2.0 .) Comments? Regards, Jeremy Henty

March 22, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > I asked Andreas to fix it again (I messed with it twice) and now > it's fixed. Thanks to him. Excellent! Many thanks to Andreas! Regards, Jeremy Henty

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

Roger wrote: > > On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > > > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and > >scroll down then Dillo will crash before you get to the bottom. I > >have attached a minimal test case that reproduces this (strangely, > >the empty SRC attribute on the img element is necessary). > > > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > > points=0xbeae1a48, npoints=4) > > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > > 464 setcolor(((FltkColor*)color)->colors[shading]); > > I see a segfault using fltk-1.3 as well here when viewing the above > URL. Interesting. What happens when you point the fltk-1.3 version at the test case I attached? I get an immediate crash with the fltk-2 version. > Although Dillo doesn't crash immediately when loading the page here, > seems to happen after scrolling all the way down the page and > shortly after starting to scroll upward. I think the crash happens only when the image with the offending style is actually displayed, which is why you have to scroll down the original page. It looks as though the bug is due to the style engine assigning a NULL color somewhere. Your backtrace shows the same thing as mine - FltkViewBase::drawPolygon() is called with a NULL color argument. This suggests that fixing the style engine will fix the crash for both versions. Who understands the style engine? Regards, Jeremy Henty

March 22, 2011

[bug]: CSS image crash

by rogerx.oss＠gmail.com

> On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and >scroll down then Dillo will crash before you get to the bottom. I >have attached a minimal test case that reproduces this (strangely, the >empty SRC attribute on the img element is necessary). > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > points=0xbeae1a48, npoints=4) > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > 464 setcolor(((FltkColor*)color)->colors[shading]); > >Regards, > >Jeremy Henty For what it's worth, here's my GDB session. --- Begin Snip --- Nav_open_url: new url='http://www.youtube.com/user/zynaddsubfx' a_Nav_expect_done: repush! Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-core-vfll8nFx1.css Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-the-rest-vflgCq-F2.css Html_tag_open_link(): addCssUrl http://s.ytimg.com/yt/cssbin/www-channel_new-vflebJ8FK.css no values for shorthand property 'border-color' no values for shorthand property 'border-color' no values for shorthand property 'border-color' DNS error: HOST_NOT_FOUND Dns_server [1]: i2.ytimg.com is (nil) [Thread 0xb7c2bb70 (LWP 5397) exited] Program received signal SIGSEGV, Segmentation fault. _______________________________________________________________________________ eax:441D7F20 ebx:00000004 ecx:00000000 edx:00000000 eflags:00010202 esi:0810D268 edi:BFFFDA00 esp:BFFFD930 ebp:BFFFD978 eip:080987F9 cs:0073 ds:007B es:007B fs:0000 gs:0033 ss:007B o d I t s z a p c [007B:BFFFD930]---------------------------------------------------------[stack] BFFFD960 : 60 4A 38 B7 60 59 2F 08 - E8 D9 FF BF 78 44 2F 08 `J8.`Y/.....xD/. BFFFD950 : 51 00 01 01 04 00 00 00 - 98 D9 FF BF 78 4D 2F 08 Q...........xM/. BFFFD940 : 40 AF 10 08 00 03 00 00 - C4 3B 14 08 50 D9 FF BF @........;..P... BFFFD930 : 94 E9 FF BF 60 57 10 08 - 58 D9 FF BF AF 4E D4 46 ....`W..X....N.F [007B:0810D268]---------------------------------------------------------[ data] 0810D268 : 28 2E 0C 08 E0 2E 0C 08 - 70 09 10 08 50 E8 15 44 (.......p...P..D 0810D278 : 00 00 00 00 00 00 00 00 - 75 00 00 00 FE 04 00 00 ........u....... [0073:080987F9]---------------------------------------------------------[ code] => 0x80987f9 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+57>: mov 0xc(%edx,%ecx,4),%edx 0x80987fd <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+61>: mov (%eax),%ebx 0x80987ff <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+63>: mov %edx,0x4(%esp) 0x8098803 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+67>: mov %eax,(%esp) 0x8098806 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+70>: call *0x3c(%ebx) 0x8098809 <dw::fltk::FltkViewBase::drawPolygon(dw::core::style::Color*, dw::core::style::Color::Shading, bool, bool, int (*) [2], int)+73>: cmpb $0x0,-0x25(%ebp) ------------------------------------------------------------------------------ 0x080987f9 in fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:61 61 inline void fl_color(Fl_Color c) {fl_graphics_driver->color(c); } // select indexed color gdb> bt #0 0x080987f9 in fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:61 #1 fl_color (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at /usr/include/fltk-1.1/FL/fl_draw.H:63 #2 dw::fltk::FltkViewBase::drawPolygon (this=0x810d268, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=0x1, convex=0x1, points=0xbfffda00, npoints=0x4) at fltkviewbase.cc:497 #3 0x080a4587 in drawBorderBottom (view=0x810d268, area=0xbfffda6c, x=0x7, y=0x456, width=0x2e, height=0x9, style=0x82f4478, inverse=0x0) at style.cc:559 #4 dw::core::style::drawBorder (view=0x810d268, area=0xbfffda6c, x=0x7, y=0x456, width=0x2e, height=0x9, style=0x82f4478, inverse=0x0) at style.cc:840 #5 0x080a7518 in dw::core::Widget::drawWidgetBox (this=0x82f42c0, view=0x810d268, area=0xbfffdb6c, inverse=0x0) at widget.cc:385 #6 0x0808efca in dw::Textblock::draw (this=0x82f42c0, view=0x810d268, area=0xbfffdb6c) at textblock.cc:1534 #7 0x0808d7f6 in dw::Textblock::drawLine (this=0x82f4120, line=0x82fb260, view=0x810d268, area=0xbfffdc0c) at textblock.cc:1416 #8 0x0808f09c in dw::Textblock::draw (this=0x82f4120, view=0x810d268, area=0xbfffdc0c) at textblock.cc:1543 #9 0x08089fab in dw::Table::draw (this=0xb7330d20, view=0x810d268, area=0xbfffdcbc) at table.cc:256 #10 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730b618, line=0xb7331260, view=0x810d268, area=0xbfffdd5c) at textblock.cc:1416 #11 0x0808f09c in dw::Textblock::draw (this=0xb730b618, view=0x810d268, area=0xbfffdd5c) at textblock.cc:1543 #12 0x08089fab in dw::Table::draw (this=0xb7330960, view=0x810d268, area=0xbfffde0c) at table.cc:256 #13 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730b848, line=0xb73d9db8, view=0x810d268, area=0xbfffdf0c) at textblock.cc:1416 #14 0x0808f09c in dw::Textblock::draw (this=0xb730b848, view=0x810d268, area=0xbfffdf0c) at textblock.cc:1543 #15 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730bbd8, line=0xb734db58, view=0x810d268, area=0xbfffe00c) at textblock.cc:1416 #16 0x0808f09c in dw::Textblock::draw (this=0xb730bbd8, view=0x810d268, area=0xbfffe00c) at textblock.cc:1543 #17 0x0808d7f6 in dw::Textblock::drawLine (this=0xb730ba30, line=0xb73e60c8, view=0x810d268, area=0xbfffe10c) at textblock.cc:1416 #18 0x0808f09c in dw::Textblock::draw (this=0xb730ba30, view=0x810d268, area=0xbfffe10c) at textblock.cc:1543 #19 0x0808d7f6 in dw::Textblock::drawLine (this=0x82fa700, line=0x82faa3c, view=0x810d268, area=0xbfffe20c) at textblock.cc:1416 #20 0x0808f09c in dw::Textblock::draw (this=0x82fa700, view=0x810d268, area=0xbfffe20c) at textblock.cc:1543 --- End Snip --- -- Roger http://rogerx.freeshell.org/

March 22, 2011

[bug]: CSS image crash

by rogerx.oss＠gmail.com

> On Mon, Mar 21, 2011 at 10:30:33PM +0000, Jeremy Henty wrote: > >If you point dillo at http://www.youtube.com/user/zynaddsubfx and >scroll down then Dillo will crash before you get to the bottom. I >have attached a minimal test case that reproduces this (strangely, the >empty SRC attribute on the img element is necessary). > >GDB shows that the drawing code is dereferencing a NULL FltkColor*: > > #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, > color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, > points=0xbeae1a48, npoints=4) > at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 > 464 setcolor(((FltkColor*)color)->colors[shading]); > >Regards, I see a segfault using fltk-1.3 as well here when viewing the above URL. Although Dillo doesn't crash immediately when loading the page here, seems to happen after scrolling all the way down the page and shortly after starting to scroll upward. -- Roger http://rogerx.freeshell.org/

March 22, 2011

[bug]: CSS image crash

by onepoint＠starurchin.org

If you point dillo at http://www.youtube.com/user/zynaddsubfx and scroll down then Dillo will crash before you get to the bottom. I have attached a minimal test case that reproduces this (strangely, the empty SRC attribute on the img element is necessary). GDB shows that the drawing code is dereferencing a NULL FltkColor*: #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, points=0xbeae1a48, npoints=4) at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 464 setcolor(((FltkColor*)color)->colors[shading]); Regards, Jeremy Henty

March 21, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > Please help me with this one. > > > > Attached goes a small program that shows what may be a bug in > > fltk-1.3: > > > > * resize the window back and forth and both "Group 1" and > > "Group 2" keep their heights. OK here. > > * With a small window, hide "Group 2" and resize to a big > > window, then show "Group 2". It grew while hidden!? > > > > > > My doubts are: > > > > Is this intended or a bug? > > If not a bug, how is the desired behaviour suppossed to be > > implemented? > > > > > > I know an ugly way to workaround it (used with the findbar), > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > the code clean. > > > > What do you think? > > Your test program shows even weirder behaviour with dwm here. > Initially the buttons are not visible and then scale in strange > ways. > I think this is because dwm is resizing the window as it is created. > > I suggest we don't use Fl_Pack and make our own solution. I will try > to get something running. Please check the attached modified version of your test program. Does the CustPack class solve your problem? Cheers, Johannes

March 21, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please help me with this one. > > Attached goes a small program that shows what may be a bug in > fltk-1.3: > > * resize the window back and forth and both "Group 1" and > "Group 2" keep their heights. OK here. > * With a small window, hide "Group 2" and resize to a big > window, then show "Group 2". It grew while hidden!? > > > My doubts are: > > Is this intended or a bug? > If not a bug, how is the desired behaviour suppossed to be > implemented? > > > I know an ugly way to workaround it (used with the findbar), > but, if it's a bug, I'd prefer to have it fixed, and to keep > the code clean. > > What do you think? Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created. I suggest we don't use Fl_Pack and make our own solution. I will try to get something running. Cheers, Johannes

March 21, 2011

Main Dillo HG repository

by jcid＠dillo.org

On Sat, Mar 19, 2011 at 07:44:26PM +0100, Johannes Hofmann wrote: > On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > > > Has this been fixed? I have not been pulling from it because I didn't > > want the FLTK-1.3 code to land on me. > > No not yet. > BTW, you can always check with "hg incoming" what you would > get on a pull. I asked Andreas to fix it again (I messed with it twice) and now it's fixed. Thanks to him. -- Cheers Jorge.-

March 21, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > I got the attached bit of HTML from a broken RSS feed and it > > causes Dillo to thrash, endlessly calling Nav_open_url(). [...] > > To me, it looks like the refresh is responsible. Yes, you're right. (I don't know how I convinced myself otherwise - I was probably editing one copy of the file and testing another - <facepalm/>.) > Probably reads the 0.1 as 0 and does the same bad thing we usually > get when we have 0 and don't have a URL argument sending us > somewhere else... So the bug is that Html_tag_open_meta() does not check that it has found a URL before doing the redirect? Does the attached patch look sensible? (The patch is a little messy, but all it does is wrap the redirect code in a "if (*content) { ... }".) Regards, Jeremy Henty

March 21, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Johannes Hofmann wrote: > On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > > > Has this been fixed? I have not been pulling from it because I > > didn't want the FLTK-1.3 code to land on me. > > No not yet. BTW, you can always check with "hg incoming" what you > would get on a pull. OK, thanks for the tip! I'll keep checking. Jeremy

March 21, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by corvid＠lavabit.com

Jeremy wrote: > I got the attached bit of HTML from a broken RSS feed and it causes > Dillo to thrash, endlessly calling Nav_open_url(). It is the > 'HTTP-EQUIV="Expires"' header that is responsible. Any ideas how to > fix this? I am afraid this bit of the code makes my head spin so some > guidance would be a big help. To me, it looks like the refresh is responsible. Probably reads the 0.1 as 0 and does the same bad thing we usually get when we have 0 and don't have a URL argument sending us somewhere else...

March 19, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

I got the attached bit of HTML from a broken RSS feed and it causes Dillo to thrash, endlessly calling Nav_open_url(). It is the 'HTTP-EQUIV="Expires"' header that is responsible. Any ideas how to fix this? I am afraid this bit of the code makes my head spin so some guidance would be a big help. Regards, Jeremy Henty

March 19, 2011

Main Dillo HG repository

by Johannes.Hofmann＠gmx.de

On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > Has this been fixed? I have not been pulling from it because I didn't > want the FLTK-1.3 code to land on me. No not yet. BTW, you can always check with "hg incoming" what you would get on a pull. Cheers, Johannes

March 19, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Has this been fixed? I have not been pulling from it because I didn't want the FLTK-1.3 code to land on me. Regards, Jeremy Henty

March 19, 2011