- Dillo-dev - lists.mailman3.com

HTML parser bug

by tim.nieradzik＠gmx.de

There is a bug in the HTML parser: Tags within quotes are interpreted: <input type="text" name="test" value="<p>asdf</p>" /> I think it is line 3754f (src/html.cc) which evokes the unwanted behaviour. I'd fix this bug by introducing two variables: The first one states whether we're currently inside of a quote and the second one stores its type (single or double quote). As long as the current character does not equal the type, all characters in between the starting and ending quote will be ignored. Of course we should be also able to deal with escaped quotes allowing constructs similar to the following one: <input type="text" name="test" value="<p>\"asdf\"</p>" /> --Tim

Dec. 5, 2009

dpid not starting automatically

by tim.nieradzik＠gmx.de

I am starting Dillo right away from the source code. Thus, it is not installed in any of the directories listed in $PATH. Dillo gives me the following errors as it does not seem to be able to find the dpid binary: Dpi_check_dpid_ids: Connection refused Dpi_start_dpid (child): No such file or directory Dpi_start_dpid: can't start dpid What do you think of adding some code that tries to execute the local dpid binary first (dpid/dpid) before looking into the system paths? --Tim

Dec. 5, 2009

Misbehaving dw-demos

by Johannes.Hofmann＠gmx.de

Hi Tim, On Sat, Dec 05, 2009 at 07:51:35PM +0100, Tim Nieradzik wrote: > The dw-demos stopped working for me with revision 2b0ed71ccec6. The > changeset results in only printing the first character of each word > followed by a line break. As discussed off-list already, this happens because the new letter-spacing member of FontAttrs is not initialized properly in the test programs. I will fix that. Normally a constructor exists to avoid exactly this kind of bugs. However we need to be careful to avoid unnecessary initializations when the members get copied over right after initialization - or maybe this wouldn't even matter performance wise... I need to play with this a little. Thanks for the fault report, Johannes

Dec. 5, 2009

Misbehaving dw-demos

by tim.nieradzik＠gmx.de

The dw-demos stopped working for me with revision 2b0ed71ccec6. The changeset results in only printing the first character of each word followed by a line break. --Tim

Dec. 5, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 12:28:12AM +0000, corvid wrote: > furaisanjin wrote: > > 2. When URL is given on address bar, cursor stays on address bar after > > the page rendering finishes. This isn't side effect. This may be > > matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. > > (My local public library's site, if used in firefox, likes to reset > form fields with javascript when a page finishes loading, and it's > irritating.) What do all think about attached patch. It switches the focus when the user hits return. So the focus switch does not happen at some random time when the page has loaded which might be irritating. Cheers, Johannes

Dec. 2, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Wed, Dec 02, 2009 at 09:33:45PM +0900, furaisanjin wrote: > 2009/12/2 corvid <corvid(a)lavabit.com>: > > furaisanjin wrote: > >> 2. When URL is given on address bar, cursor stays on address bar after > >> the page rendering finishes. This isn't side effect. This may be > >> matter of taste but I don't like this behavior. > > > > We'll need to be careful if changing focus in this case, since > > the user may be in the middle of typing something somewhere. > > I agree but current dillo behavior isn't good either. If I type > something on address bar before a page rendering finishes, typed > characters are appended after URL when URL is pushed on address bar. I > think only typed characters should remain there when the page > rendering finishes. Yes, that's annoying, but I think it's a separate issue. Regards, Johannes

Dec. 2, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/2 corvid <corvid(a)lavabit.com>: > furaisanjin wrote: >> 2. When URL is given on address bar, cursor stays on address bar after >> the page rendering finishes. This isn't side effect. This may be >> matter of taste but I don't like this behavior. > > We'll need to be careful if changing focus in this case, since > the user may be in the middle of typing something somewhere. I agree but current dillo behavior isn't good either. If I type something on address bar before a page rendering finishes, typed characters are appended after URL when URL is pushed on address bar. I think only typed characters should remain there when the page rendering finishes. Regards, furaisanjin

Dec. 2, 2009

take_focus on a new tab

by corvid＠lavabit.com

furaisanjin wrote: > 2. When URL is given on address bar, cursor stays on address bar after > the page rendering finishes. This isn't side effect. This may be > matter of taste but I don't like this behavior. We'll need to be careful if changing focus in this case, since the user may be in the middle of typing something somewhere. (My local public library's site, if used in firefox, likes to reset form fields with javascript when a page finishes loading, and it's irritating.)

Dec. 2, 2009

take_focus on a new tab

by furaisanjin＠gmail.com

2009/12/2 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Can you please describe the situation where it happens? There are 2 cases. 1. When dillo starts, cursor stays on address bar and this is the side effect of the updated codes. 2. When URL is given on address bar, cursor stays on address bar after the page rendering finishes. This isn't side effect. This may be matter of taste but I don't like this behavior. Regards, furaisanjin

Dec. 2, 2009

take_focus on a new tab

by Johannes.Hofmann＠gmx.de

On Sat, Nov 28, 2009 at 01:06:21PM +0900, furaisanjin wrote: > 2009/11/28 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > > I committed a slightly different patch to also cover the case when > > middle_click_opens_new_tab=NO > > > > Please test, > > I tested but I found still there were cases where cursor stayed on > address bar. Could you consider this patch? Can you please describe the situation where it happens? I'm a bit reluctant to sprinkle focus handling code all over the place. Regards, Johannes

Dec. 1, 2009