- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]BUG#569

by David McKee

On Sat, 19 Jun 2004, Jorge Arellano Cid wrote: > What do you guys think of this? > > 569 > Impact: feature fault > At: run time > Type: misbehaviour > Comments: In Dillo, BACK button sends me to other previous html file, > not to the previous position in the same file. [...] > Since the beginning, Dillo's behaviour is as described above. > We have received almost no complaints, so it doesn't seem that > bad in practice. Would it be worth to change it? This has always been a minor annoyance...if the long page you're browsing has been structured with a convienent set a headings, the navigation sub-menu solves the problem fairly well, but I would like to see this behavior changed. If the page author has not been so kind, or if the page consists of a single giant table, you then have to scroll madly in search of you place... Presumably the back (and forward) button is implelemted with a stack of URLs. Stacking a tuple of (url, location) or somesuch would change the behavior to conform with other major browsers. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

June 21, 2004

Re: [Dillo-dev]Dillo & linuxmail.org

by Lars Segerlund

Thanks, I couldn't get it to go together, ( I was able to login, but this is probably due to an old coockie ). Now I know where to look .. time to fool around :-) .. / regards, Lars Segerlund. On Wed, 16 Jun 2004 12:05:07 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > Hi Lars, > > > On Wed, 16 Jun 2004, Lars Segerlund wrote: > > > > > I just checked out the latest dillo and I can alsost get my > > linuxmail.org account to run in it. > > > > Does anybody have any idea about what might be the problem ? > > The site relies heavily on Javascript. > > Looking at the source for the login page, it expects javascript > functions to MD5-encode the password before form submittion. > > It may be possible to bypass the problem by giving the MD5 > encoded password (+ the mangling it uses) so dillo can finally > get the FORM accepted by the server. > > It also looks as they give you a permanent cookie that can > avoid the login process to some extent. So allow them for that > domain. > > In a nutshell: the problem is mandatory javascript; it may be > solved with some clever hacks though. > > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 21, 2004

Re: [Dillo-dev]BUG#569

by Johannes Hofmann

Hi, actually I would like to have it changed. Then BACK would always send you back one click, whether within the same page or not. Often one doesn't really know whether one is still in the same page or not. Regards, Johannes Hofmann On Sat, Jun 19, 2004 at 01:01:20PM -0400, Jorge Arellano Cid wrote: > > Hi there, > > What do you guys think of this? > > 569 > Impact: feature fault > At: run time > Type: misbehaviour > Comments: In Dillo, BACK button sends me to other previous html file, > not to the previous position in the same file. It is a problem. > I tested this BACK BUTTON function in Mozilla and IE. They worked. Please > solve > this glitch. I really need this function. > HTReproduce: In a long html file, click a tag that sends you to the > another > part in the same html file. Then click BACK BUTTON in the menu > bar. You would be in the previous other html file, not in the > previous position in the same file. It is a fault behavior. > WorkedBy: polsci* hitel* net > Submitter: polsci* hitel* net > > Since the beginning, Dillo's behaviour is as described above. > We have received almost no complaints, so it doesn't seem that > bad in practice. Would it be worth to change it? > > > Cheers > Jorge.- > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

June 19, 2004

[Dillo-dev]BUG#569

by Jorge Arellano Cid

Hi there, What do you guys think of this? 569 Impact: feature fault At: run time Type: misbehaviour Comments: In Dillo, BACK button sends me to other previous html file, not to the previous position in the same file. It is a problem. I tested this BACK BUTTON function in Mozilla and IE. They worked. Please solve this glitch. I really need this function. HTReproduce: In a long html file, click a tag that sends you to the another part in the same html file. Then click BACK BUTTON in the menu bar. You would be in the previous other html file, not in the previous position in the same file. It is a fault behavior. WorkedBy: polsci* hitel* net Submitter: polsci* hitel* net Since the beginning, Dillo's behaviour is as described above. We have received almost no complaints, so it doesn't seem that bad in practice. Would it be worth to change it? Cheers Jorge.-

June 19, 2004

[Dillo-dev]BUG#570

by Jorge Arellano Cid

Hi Sebastian, Please give a look at BUG#570: 570 Impact: soft error At: run time Type: render bug Comments: Inconsistent render. First load or reload renders different than cached load (back/forward) HTReproduce: open dillo, nav to http://slskboard.savagenews.com/index.php (notice the first forum name i.e.) press back press forward (different cell width) WorkedBy: nobody Submitter: unknown it is very interesting and perhaps related to the rendering problem of our home page with dialups (resizing of alt-sized cells to actual image size). Cheers Jorge.-

June 19, 2004

Re: [Dillo-dev]thread-safe X at fresco

by Jorge Arellano Cid

On Fri, 18 Jun 2004, robert w hall wrote: > The thread-safe versions of XFree3.3.3.1 have disappeared from > linuxsavvy, (and my own attempts too recompile my own have produced > useable, but not wholly error-free results)... > > But I note that vintage.fresco.org still has two earlier thread-safe > Xlibs, 3.1.2 and 3.2, linked statically. I have REENTRANT 3.3.2 libs that work for me. If you want I can pack them for you to try... Cheers Jorge.-

June 19, 2004

[Dillo-dev]thread-safe X at fresco

by robert w hall

The thread-safe versions of XFree3.3.3.1 have disappeared from linuxsavvy, (and my own attempts too recompile my own have produced useable, but not wholly error-free results)... But I note that vintage.fresco.org still has two earlier thread-safe Xlibs, 3.1.2 and 3.2, linked statically. Anyone used these? dillo glib gtk appear only to use libX11, libXext, (which is all the earlier fresco 3.1.2 package provides). Bob Going bravely backwards from kernel 2.6.7! -- robert w hall

June 18, 2004

Re: [Dillo-dev]Problems with the activation of the URL entry

by Jorge Arellano Cid

On Thu, 17 Jun 2004, Jorge Arellano Cid wrote: > > Sebastian, > > On Tue, 15 Jun 2004, Jorge Arellano Cid wrote: > >>> When a_Interface_entry_open_url is called in this case, >>> gtk_editable_get_chars returns an empty string, it seems that the >>> "real" copying of the selection in Interface_entry_paste_selected is >>> somehow delayed. As workarounds, I see two possible solutions: >>> >>> 1. Also queueing our code in an idle function. The attached patch >>> demonstrates this successfully, although it has to be cleaned up >>> (in some cases, the active idle function has to be removed again). >>> >>> 2. Calling a_Interface_entry_open_url directly with the contents of >>> the selection. (But how do I get the latter?) >> >> The safe way to get 2) is to call a_Nav_push from the callback, >> and not to worry about a_Interface_... functions. That way, the >> selection is handled as a link. >> >> The only glitch is that the entry is not inmediately changed, >> but the stop button will serve as feedback (it shows activity). > > Oh, later I realized that this is not enough to solve the > problem, because there's a race condition if the selection is not > retrieved by catching the "selection_received" signal. > > Now I have some code that does this and will commit after some > polishing. Done. > PS: Is there anyone using a 2.6.x linux kernel? I tried it > yesterday and viewing directory listings with dillo was painfully > slow. So I developed a patch for this, but I'm surprised noone > complained! and Done. Now the copy&paste into the "clear URL" button works by catching the "selection_received" signal. It was very hard to find out how its done because the GTK+ docs are incomplete, the GDK ones recommend using Xlibs directly (or the GTK API), and the example code in the GTK+ has the wrong parameters. The GDK sources shed some light. With regard to 2.6.x linux, it was a matter of adding some buffering, a stream transfer instead of FD was enough. Cheers Jorge.-

June 18, 2004

Re: [Dillo-dev]Problems with the activation of the URL entry

by Jorge Arellano Cid

Sebastian, On Tue, 15 Jun 2004, Jorge Arellano Cid wrote: >> When a_Interface_entry_open_url is called in this case, >> gtk_editable_get_chars returns an empty string, it seems that the >> "real" copying of the selection in Interface_entry_paste_selected is >> somehow delayed. As workarounds, I see two possible solutions: >> >> 1. Also queueing our code in an idle function. The attached patch >> demonstrates this successfully, although it has to be cleaned up >> (in some cases, the active idle function has to be removed again). >> >> 2. Calling a_Interface_entry_open_url directly with the contents of >> the selection. (But how do I get the latter?) > > The safe way to get 2) is to call a_Nav_push from the callback, > and not to worry about a_Interface_... functions. That way, the > selection is handled as a link. > > The only glitch is that the entry is not inmediately changed, > but the stop button will serve as feedback (it shows activity). Oh, later I realized that this is not enough to solve the problem, because there's a race condition if the selection is not retrieved by catching the "selection_received" signal. Now I have some code that does this and will commit after some polishing. Cheers Jorge.- PS: Is there anyone using a 2.6.x linux kernel? I tried it yesterday and viewing directory listings with dillo was painfully slow. So I developed a patch for this, but I'm surprised noone complained!

June 17, 2004

Re: [Dillo-dev]More on the UTF-8 issue

by Todd Slater

On Wed, Jun 16, 2004 at 12:46:17PM -0700, sam+dillo(a)chaosring.org wrote: <snip> > As an aside, I think Dillo currently has excellent CSS support (namely, > none whatsoever). The thinking behing CSS is that a webpage > should be perfectly readable on a browser with no CSS support; the > content (if not the presentation) of a CSS webpage is perfectly > accessible from a non-CSS browser. > > I come from the "CSS shouldn't be done at all, or should be done > perfectly" camp. Considering the number of hacks web designers > have come up to make CSS visible to this browser yet invisible to > that browser [2], the last thing a webmaster wants is yet another > buggy CSS implementation. I couldn't agree more, and it's one of the reasons I use Dillo--to view pages according to their HTML structure. It's when you look at css-heavy pages that you appreciate webmasters that use the visibility feature of css to hide the navigation jumps to css-aware browsers; they become very user-friendly to non-css aware browsers. I suppose lynx would give the same effect :) Todd

June 16, 2004