From hannes at yllr.net Sat Jul 3 08:23:03 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 3 Jul 2010 10:23:03 +0200 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus Message-ID: <20100703082300.GA16341@laptop2.lan.localhost> Hello everyone, this issue has been reported to me quite some time ago, but I haven't been able to reproduce it. Another user now reported the same thing on the IRC channel. After lots and lots of trying, I managed to reproduce it, but only with a freshly compiled version which should be exactly the same as my 'regular' one, so I'm still not sure what's causing it. First, the symptoms as described by the users: http://bbs.archlinux.org/viewtopic.php?id=97265 http://wwwcip.cs.fau.de/~lu03pevi/vimprobable.txt It is important to note that this only happens if Javascript is turned on. As I said, I've not been able to reliably reproduce it, but I've seen it happen. Hans-Peter suggested this: http://gitorious.org/vimprobable/vimprobable/commit/d1ddb77551a2a74f621b8377756d5cfaedad6e48 Problem is, although this does make the reporting of the browser's mode consistent with its internal state again, it's not really the desired solution. It resets the browser to normal mode and takes away focus from the input field when the window loses focus. What I'd like to achieve instead is to have the input field still being active when the browser gets focused again and INSERT mode should still be active (not just in the status line, but internally). In the one experimental version in which I can reproduce the bug, I've been able to solve the issue by removing the line *gtk_widget_grab_focus(GTK_WIDGET(webview)); from the beginning of the set() function (should be around line 1135, depending on your version). So, after these long-winded explanations, my questions to you: - Who can reproduce the bug? Under what circumstances? - Does the proposed change fix the issue? - Can anyone imagine any negative side effects of removing that line from the code? Hannes From hannes at yllr.net Sat Jul 3 08:31:59 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 3 Jul 2010 10:31:59 +0200 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus In-Reply-To: <20100703082300.GA16341@laptop2.lan.localhost> References: <20100703082300.GA16341@laptop2.lan.localhost> Message-ID: <20100703083157.GB16341@laptop2.lan.localhost> Oh, yes, and if you try it out and post, please note your version of libwebkit. So far, it seems the issue was introduced in the 1.2 version of the library. Hannes From hannes at yllr.net Sat Jul 3 10:32:27 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 3 Jul 2010 12:32:27 +0200 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus In-Reply-To: <20100703082300.GA16341@laptop2.lan.localhost> References: <20100703082300.GA16341@laptop2.lan.localhost> Message-ID: <20100703103225.GC16341@laptop2.lan.localhost> Ignore the last workaround proposal - unwanted side-effects. This new approach attempts to prevent any mode change from happening when the browser window doesn't have focus. This, I think, makes sense anyway, because why change an internal state if the user is working on another window anyway? You can find the experimental patch at http://www.vimprobable.org/focus.patch . This includes some debugging output, so please run from a terminal. Please test and see it it fixes the problem. Even if you didn't have the problem before, please test it to see if there are any side-effects. Info to include: - problem occured before? - problem solved? - libwebkit version? - running the browser embedded or standalone? Please, folks, I really need some more feedback on this one before I can push it into the official repository without a bad feeling in my gut. Hannes From skottish97215 at gmail.com Sun Jul 4 00:13:28 2010 From: skottish97215 at gmail.com (Skottish) Date: Sat, 3 Jul 2010 17:13:28 -0700 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus In-Reply-To: <20100703103225.GC16341@laptop2.lan.localhost> References: <20100703082300.GA16341@laptop2.lan.localhost> <20100703103225.GC16341@laptop2.lan.localhost> Message-ID: This is definitely way better. My early tests are showing that I can in fact leave to do something else and return properly. This very, very cool. This should answer questions one and two. Running libwebkit 1.2.1 in standalone mode. 2010/7/3 Hannes Sch?ller > Ignore the last workaround proposal - unwanted side-effects. This new > approach attempts to prevent any mode change from happening when the > browser window doesn't have focus. This, I think, makes sense anyway, > because why change an internal state if the user is working on another > window anyway? > > You can find the experimental patch at > http://www.vimprobable.org/focus.patch . This includes some debugging > output, so please run from a terminal. Please test and see it it fixes > the problem. Even if you didn't have the problem before, please test it > to see if there are any side-effects. > > Info to include: > - problem occured before? > - problem solved? > - libwebkit version? > - running the browser embedded or standalone? > > Please, folks, I really need some more feedback on this one before I can > push it into the official repository without a bad feeling in my gut. > > Hannes > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skottish97215 at gmail.com Sun Jul 4 21:22:46 2010 From: skottish97215 at gmail.com (Skottish) Date: Sun, 4 Jul 2010 14:22:46 -0700 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus In-Reply-To: References: <20100703082300.GA16341@laptop2.lan.localhost> <20100703103225.GC16341@laptop2.lan.localhost> Message-ID: I've been running with the changes for hours now and have tested vimprobable2 within tabbed, and I haven't seen any side effects or otherwise differences in performance or functionality. I'm hoping that some users that are using earlier versions of libwebkit can confirm that no bugs have been introduced by the patch. I'd love to see this pushed into the codebase seeing that it clearly fixes the issue. On Sat, Jul 3, 2010 at 5:13 PM, Skottish wrote: > This is definitely way better. My early tests are showing that I can in > fact leave to do something else and return properly. This very, very cool. > This should answer questions one and two. > > Running libwebkit 1.2.1 in standalone mode. > > 2010/7/3 Hannes Sch?ller > > Ignore the last workaround proposal - unwanted side-effects. This new >> approach attempts to prevent any mode change from happening when the >> browser window doesn't have focus. This, I think, makes sense anyway, >> because why change an internal state if the user is working on another >> window anyway? >> >> You can find the experimental patch at >> http://www.vimprobable.org/focus.patch . This includes some debugging >> output, so please run from a terminal. Please test and see it it fixes >> the problem. Even if you didn't have the problem before, please test it >> to see if there are any side-effects. >> >> Info to include: >> - problem occured before? >> - problem solved? >> - libwebkit version? >> - running the browser embedded or standalone? >> >> Please, folks, I really need some more feedback on this one before I can >> push it into the official repository without a bad feeling in my gut. >> >> Hannes >> _______________________________________________ >> Vimprobable-users mailing list >> Vimprobable-users at vimprobable.org >> http://vimprobable.org/mailman/listinfo/vimprobable-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannes at yllr.net Mon Jul 5 18:13:53 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Mon, 5 Jul 2010 20:13:53 +0200 Subject: [Vimprobable-users] INSERT mode lost when browser loses focus In-Reply-To: References: <20100703082300.GA16341@laptop2.lan.localhost> <20100703103225.GC16341@laptop2.lan.localhost> Message-ID: <20100705201353.5273e2f5@workstation> After this confirmation and some from the nice people on IRC, this patch is now in the official branch. Skottish wrote: > I've been running with the changes for hours now and have tested > vimprobable2 within tabbed, and I haven't seen any side effects or > otherwise differences in performance or functionality. I'm hoping > that some users that are using earlier versions of libwebkit can > confirm that no bugs have been introduced by the patch. I'd love to > see this pushed into the codebase seeing that it clearly fixes the > issue. > > On Sat, Jul 3, 2010 at 5:13 PM, Skottish > wrote: > > > This is definitely way better. My early tests are showing that I > > can in fact leave to do something else and return properly. This > > very, very cool. This should answer questions one and two. > > > > Running libwebkit 1.2.1 in standalone mode. > > > > 2010/7/3 Hannes Sch?ller > > > > Ignore the last workaround proposal - unwanted side-effects. This > > new > >> approach attempts to prevent any mode change from happening when > >> the browser window doesn't have focus. This, I think, makes sense > >> anyway, because why change an internal state if the user is > >> working on another window anyway? > >> > >> You can find the experimental patch at > >> http://www.vimprobable.org/focus.patch . This includes some > >> debugging output, so please run from a terminal. Please test and > >> see it it fixes the problem. Even if you didn't have the problem > >> before, please test it to see if there are any side-effects. > >> > >> Info to include: > >> - problem occured before? > >> - problem solved? > >> - libwebkit version? > >> - running the browser embedded or standalone? > >> > >> Please, folks, I really need some more feedback on this one before > >> I can push it into the official repository without a bad feeling > >> in my gut. > >> > >> Hannes > >> _______________________________________________ > >> Vimprobable-users mailing list > >> Vimprobable-users at vimprobable.org > >> http://vimprobable.org/mailman/listinfo/vimprobable-users > >> > > > > From thomas at xteddy.org Mon Jul 5 18:47:23 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 19:47:23 +0100 Subject: [Vimprobable-users] [PATCH 0/3] :set scrollbars [true|false] Message-ID: <20100705184720.GA11135@shuttle.home> This patch series allows toggling scrollbars at runtime (still off by default at compile-time, per DISABLE_SCROLLBAR of course). Hopefully each patch is self-explanatory enough, but if not, shout up. I'd be interested to know if there's any of you out there who've wanted something like this. I find this feature rather useful, and am not sure why. :) -- Thomas Adam Thomas Adam (3): Add scrollbars entry to browsersettings. Implement ":set scrollbars true|false" Add scrollbar entry to vimprobablrc manpage. config.h | 1 + main.c | 30 +++++++++++++++++++++++++++--- vimprobablerc.1 | 3 +++ 3 files changed, 31 insertions(+), 3 deletions(-) From thomas at xteddy.org Mon Jul 5 18:48:01 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 19:48:01 +0100 Subject: [Vimprobable-users] [PATCH 1/3] Add scrollbars entry to browsersettings. Message-ID: <20100705184757.GA11180@shuttle.home> Add a new :set option for allowing showing/hiding of scrollbars. --- config.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/config.h b/config.h index d9f6854..31aa381 100644 --- a/config.h +++ b/config.h @@ -256,4 +256,5 @@ static Setting browsersettings[] = { { "sslcolor", sslcolor, "", FALSE, FALSE, TRUE, TRUE }, { "qmark", NULL, "", FALSE, FALSE, FALSE, FALSE }, { "proxy", NULL, "", FALSE, TRUE, FALSE, FALSE }, + { "scrollbars", NULL, "", FALSE, TRUE, FALSE, FALSE }, }; 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jul 5 18:48:53 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 19:48:53 +0100 Subject: [Vimprobable-users] [PATCH 2/3] Implement ":set scrollbars true|false" Message-ID: <20100705184848.GA11213@shuttle.home> Teach Vimprobable the ability to toggle scrollbars at runtime. --- main.c | 30 +++++++++++++++++++++++++++--- 1 files changed, 27 insertions(+), 3 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..fa5ad41 100644 --- a/main.c +++ b/main.c @@ -78,6 +78,7 @@ gboolean parse_colour(char *color); gboolean read_rcfile(void); void save_command_history(char *line); void toggle_proxy(gboolean onoff); +void toggle_scrollbars(gboolean onoff); void make_keyslist(void); gboolean process_keypress(GdkEventKey *event); @@ -89,7 +90,10 @@ GtkWidget * fill_eventbox(const char * completion_line); /* variables */ static GtkWindow *window; +static GtkWidget *viewport; static GtkBox *box; +static GtkScrollbar *scroll_h; +static GtkScrollbar *scroll_v; static GtkAdjustment *adjust_h; static GtkAdjustment *adjust_v; static GtkWidget *inputbox; @@ -1750,6 +1754,11 @@ process_set_line(char *line) { if (strlen(my_pair.what) == 5 && strncmp("proxy", my_pair.what, 5) == 0) { toggle_proxy(boolval); } + + /* Toggle scrollbars. */ + if (strlen(my_pair.what) == 10 && strncmp("scrollbars", my_pair.what, 10) == 0) + toggle_scrollbars(boolval); + /* reload page? */ if (browsersettings[i].reload) webkit_web_view_reload(webview); @@ -1880,6 +1889,21 @@ toggle_proxy(gboolean onoff) { } void +toggle_scrollbars(gboolean onoff) { + if (onoff == TRUE) { + adjust_h = gtk_scrolled_window_get_hadjustment(GTK_SCROLLED_WINDOW(viewport)); + adjust_v = gtk_scrolled_window_get_vadjustment(GTK_SCROLLED_WINDOW(viewport)); + } + else { + adjust_v = gtk_range_get_adjustment(GTK_RANGE(scroll_v)); + adjust_h = gtk_range_get_adjustment(GTK_RANGE(scroll_h)); + } + gtk_widget_set_scroll_adjustments (GTK_WIDGET(webview), adjust_h, adjust_v); + + return; +} + +void update_url(const char *uri) { gboolean ssl = g_str_has_prefix(uri, "https://"); GdkColor color; @@ -1963,8 +1987,8 @@ setup_modkeys() { void setup_gui() { - GtkScrollbar *scroll_h = GTK_SCROLLBAR(gtk_hscrollbar_new(NULL)); - GtkScrollbar *scroll_v = GTK_SCROLLBAR(gtk_vscrollbar_new(NULL)); + scroll_h = GTK_SCROLLBAR(gtk_hscrollbar_new(NULL)); + scroll_v = GTK_SCROLLBAR(gtk_vscrollbar_new(NULL)); adjust_h = gtk_range_get_adjustment(GTK_RANGE(scroll_h)); adjust_v = gtk_range_get_adjustment(GTK_RANGE(scroll_v)); if (embed) { @@ -1995,7 +2019,7 @@ setup_gui() { gtk_window_set_geometry_hints(window, NULL, &hints, GDK_HINT_MIN_SIZE); #ifdef DISABLE_SCROLLBAR - GtkWidget *viewport = gtk_scrolled_window_new(NULL, NULL); + viewport = gtk_scrolled_window_new(NULL, NULL); gtk_scrolled_window_set_policy(GTK_SCROLLED_WINDOW(viewport), GTK_POLICY_NEVER, GTK_POLICY_NEVER); #else /* Ensure we still see scrollbars. */ 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jul 5 18:49:35 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 19:49:35 +0100 Subject: [Vimprobable-users] [PATCH 3/3] Add scrollbar entry to vimprobablrc manpage. Message-ID: <20100705184927.GA11264@shuttle.home> Document that ":set scrollbars [true|false]" exists. --- vimprobablerc.1 | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/vimprobablerc.1 b/vimprobablerc.1 index 0ae0333..a369975 100644 --- a/vimprobablerc.1 +++ b/vimprobablerc.1 @@ -110,6 +110,9 @@ Enable or disenable print backgrounds .IP sansfont=default-sans-font-family Replace the default sans-serif font family +.IP scrollbars=[true|false] +Enable or disable scrollbars. + .IP seriffont=default-serif-font-family Replace the default serif font family 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jul 5 19:55:55 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 20:55:55 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Tidy up echo() and input() when setting widget properties Message-ID: <20100705195550.GA14675@shuttle.home> Both these functions set the same properties on the same widget. Factor this out into set_widget_font_and_color(). --- main.c | 58 +++++++++++++++++++++++++++++----------------------------- 1 files changed, 29 insertions(+), 29 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..c894a87 100644 --- a/main.c +++ b/main.c @@ -68,6 +68,8 @@ static void ascii_bar(int total, int state, char *string); static gchar *jsapi_ref_to_string(JSContextRef context, JSValueRef ref); static void jsapi_evaluate_script(const gchar *script, gchar **value, gchar **message); static void download_progress(WebKitDownload *d, GParamSpec *pspec); +static void set_widget_font_and_color(GtkWidget *widget, const char *font_str, + const char *bg_color_str, const char *fg_color_str); static gboolean history(void); static gboolean mappings(const Arg *arg); @@ -449,6 +451,28 @@ webview_keypress_cb(WebKitWebView *webview, GdkEventKey *event) { } void +set_widget_font_and_color(GtkWidget *widget, const char *font_str, const char *bg_color_str, + const char *fg_color_str) { + GdkColor fg_color; + GdkColor bg_color; + PangoFontDescription *font; + + font = pango_font_description_from_string(font_str); + gtk_widget_modify_font(widget, font); + pango_font_description_free(font); + + if (fg_color_str) + gdk_color_parse(fg_color_str, &fg_color); + if (bg_color_str) + gdk_color_parse(bg_color_str, &bg_color); + + gtk_widget_modify_text(widget, GTK_STATE_NORMAL, fg_color_str ? &fg_color : NULL); + gtk_widget_modify_base(widget, GTK_STATE_NORMAL, bg_color_str ? &bg_color : NULL); + + return; +} + +void webview_hoverlink_cb(WebKitWebView *webview, char *title, char *link, gpointer data) { const char *uri = webkit_web_view_get_uri(webview); @@ -905,16 +929,10 @@ echo(const Arg *arg) { if (index < Info || index > Error) return TRUE; - font = pango_font_description_from_string(urlboxfont[index]); - gtk_widget_modify_font(inputbox, font); - pango_font_description_free(font); - if (urlboxcolor[index]) - gdk_color_parse(urlboxcolor[index], &color); - gtk_widget_modify_text(inputbox, GTK_STATE_NORMAL, urlboxcolor[index] ? &color : NULL); - if (urlboxbgcolor[index]) - gdk_color_parse(urlboxbgcolor[index], &color); - gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &color : NULL); + + set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); gtk_entry_set_text(GTK_ENTRY(inputbox), !arg->s ? "" : arg->s); + return TRUE; } @@ -923,33 +941,15 @@ input(const Arg *arg) { int pos = 0; count = 0; const char *url; + int index = Info; update_state(); /* Set the colour and font back to the default, so that we don't still * maintain a red colour from a warning from an end of search indicator, * etc. - * - * XXX - unify this with echo() at some point. */ - { - GdkColor ibox_fg_color; - GdkColor ibox_bg_color; - PangoFontDescription *font; - int index = Info; - - font = pango_font_description_from_string(urlboxfont[index]); - gtk_widget_modify_font(inputbox, font); - pango_font_description_free(font); - - if (urlboxcolor[index]) - gdk_color_parse(urlboxcolor[index], &ibox_fg_color); - if (urlboxbgcolor[index]) - gdk_color_parse(urlboxbgcolor[index], &ibox_bg_color); - - gtk_widget_modify_text(inputbox, GTK_STATE_NORMAL, urlboxcolor[index] ? &ibox_fg_color : NULL); - gtk_widget_modify_base(inputbox, GTK_STATE_NORMAL, urlboxbgcolor[index] ? &ibox_bg_color : NULL); - } + set_widget_font_and_color(inputbox, urlboxfont[index], urlboxbgcolor[index], urlboxcolor[index]); /* to avoid things like :open URL :open URL2 or :open :open URL */ gtk_entry_set_text(GTK_ENTRY(inputbox), ""); 1.6.6.196.g1f735 From thomas at xteddy.org Mon Jul 5 20:07:07 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 5 Jul 2010 21:07:07 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fix minor typo in vimprobablerc manpage. Message-ID: <20100705200704.GA15409@shuttle.home> s/disenable/disable/ --- vimprobablerc.1 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/vimprobablerc.1 b/vimprobablerc.1 index 0ae0333..2e7e7b2 100644 --- a/vimprobablerc.1 +++ b/vimprobablerc.1 @@ -105,7 +105,7 @@ Replace the default monospace font family Whether to read and use the http_proxy environment variable .IP backgrounds=[true|false] -Enable or disenable print backgrounds +Enable or disable print backgrounds .IP sansfont=default-sans-font-family Replace the default sans-serif font family 1.6.6.196.g1f735 From hpdeifel at gmx.de Tue Jul 6 12:46:26 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Tue, 6 Jul 2010 14:46:26 +0200 Subject: [Vimprobable-users] [PATCH] prevent segfault on exit In-Reply-To: <1278420386-5172-1-git-send-email-hpdeifel@gmx.de> References: <1278420386-5172-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1278420386-5172-2-git-send-email-hpdeifel@gmx.de> --- main.c | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..e8c1a2e 100644 --- a/main.c +++ b/main.c @@ -1108,12 +1108,14 @@ quit(const Arg *arg) { FILE *f; const char *filename; const char *uri = webkit_web_view_get_uri(webview); - /* write last URL into status file for recreation with "u" */ - filename = g_strdup_printf(CLOSED_URL_FILENAME); - f = fopen(filename, "w"); - if (f != NULL) { - fprintf(f, "%s", uri); - fclose(f); + if (uri != NULL) { + /* write last URL into status file for recreation with "u" */ + filename = g_strdup_printf(CLOSED_URL_FILENAME); + f = fopen(filename, "w"); + if (f != NULL) { + fprintf(f, "%s", uri); + fclose(f); + } } gtk_main_quit(); return TRUE; -- 1.7.1 From hpdeifel at gmx.de Tue Jul 6 12:46:25 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Tue, 6 Jul 2010 14:46:25 +0200 Subject: [Vimprobable-users] [PATCH] Segfault on exit Message-ID: <1278420386-5172-1-git-send-email-hpdeifel@gmx.de> Hi, vimprobable segfaults on exit if no valid url has been loaded. E.g. do the following: ------------------------------------------------------------------------ $ ./vimprobable2 does.not.exist (type d) zsh: segmentation fault ./vimprobable2 does.not.exist ------------------------------------------------------------------------ The problem is that webkit_web_view_get_uri() returns NULL in this case and there is no check for this in the quit() function. Regards, HP Hans-Peter Deifel (1): prevent segfault on exit main.c | 14 ++++++++------ 1 files changed, 8 insertions(+), 6 deletions(-) From hpdeifel at gmx.de Wed Jul 7 15:33:33 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Wed, 7 Jul 2010 17:33:33 +0200 Subject: [Vimprobable-users] [PATCH 0/2] Problems with incremental search Message-ID: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> Hi, I found some problems with incremental search: 1. Typing a capital letter skips one match. 2. Pressing and releasing modifier-keys skips one match. 3. Typing too fast can skip matches. 4. Pressing return also jumps to the next match. The cause for 1, 2 and 3 is that webkit_web_view_search_text() is called on every key-release-event if the first character of the text in the inputbox is '/' or '?'. In case 1, gtk sends two key release events for the capital letter. One for the letter and one for the shift key. In case 2, it's simply the release-event of that modifier-key that is handled, even though the text didn't change. Case 3 is a little more subtle. If I type too fast, I press the next key before I have released the previous one. That means that gtk will insert the first key and the second and than send the key-release-events of both keys. So on both events, both keys have already been inserted and thus webkit_web_view_search_text() is called twice with the same text. Case 4 is a different issue. Return sends the "activate" signal and in the handler for this signal search() is called, which calls webkit_web_view_search_text(). That behaviour makes sense for non incremental search but with incremental search the current match is already highlighted, so we don't need another search(). I made patches that fix the problems for me, but they are not problem-free and I honestly don't know how to solve it in a cleaner way. See also the comment in inputbox_changed_cb(). Please comment on the patches. Regards, HP Hans-Peter Deifel (2): don't jump to next match when pressing return in incremental search Update incremental search only when the search string changes main.c | 38 ++++++++++++++++++++++++++++++++------ 1 files changed, 32 insertions(+), 6 deletions(-) From hpdeifel at gmx.de Wed Jul 7 15:33:35 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Wed, 7 Jul 2010 17:33:35 +0200 Subject: [Vimprobable-users] [PATCH 2/2] Update incremental search only when the search string changes In-Reply-To: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> References: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1278516815-5089-3-git-send-email-hpdeifel@gmx.de> --- main.c | 33 +++++++++++++++++++++++++++------ 1 files changed, 27 insertions(+), 6 deletions(-) diff --git a/main.c b/main.c index 87770e8..444c9b7 100644 --- a/main.c +++ b/main.c @@ -18,6 +18,9 @@ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); static gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event); static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event); +#ifdef ENABLE_INCREMENTAL_SEARCH +static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data); +#endif static WebKitWebView* inspector_inspect_web_view_cb(gpointer inspector, WebKitWebView* web_view); static gboolean notify_event_cb(GtkWidget *widget, GdkEvent *event, gpointer user_data); static gboolean webview_console_cb(WebKitWebView *webview, char *message, int line, char *source, gpointer user_data); @@ -589,24 +592,39 @@ notify_event_cb(GtkWidget *widget, GdkEvent *event, gpointer user_data) { static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; guint16 length = gtk_entry_get_text_length(entry); -#ifdef ENABLE_INCREMENTAL_SEARCH - char *text = (char*)gtk_entry_get_text(entry); - gboolean forward = FALSE; -#endif + if (!length) { a.i = HideCompletion; complete(&a); a.i = ModeNormal; return set(&a); } + return FALSE; +} + #ifdef ENABLE_INCREMENTAL_SEARCH - else if (length > 1 && ((forward = text[0] == '/') || text[0] == '?')) { +static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { + char *text = (char*)gtk_entry_get_text(GTK_ENTRY(entry)); + guint16 length = gtk_entry_get_text_length(GTK_ENTRY(entry)); + gboolean forward = FALSE; + + /* Update incremental search if the user changes the search text. + * + * Note: gtk_widget_is_focus() is a poor way to check if the change comes + * from the user. But if the entry is focused and the text is set + * through gtk_entry_set_text() in some asyncrounous operation, + * I would consider that a bug. + */ + + if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && ((forward = text[0] == '/') || text[0] == '?')) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); + return TRUE; } -#endif + return FALSE; } +#endif /* funcs here */ @@ -2107,6 +2125,9 @@ setup_signals() { "signal::activate", (GCallback)inputbox_activate_cb, NULL, "signal::key-press-event", (GCallback)inputbox_keypress_cb, NULL, "signal::key-release-event", (GCallback)inputbox_keyrelease_cb, NULL, +#ifdef ENABLE_INCREMENTAL_SEARCH + "signal::changed", (GCallback)inputbox_changed_cb, NULL, +#endif NULL); /* inspector */ g_signal_connect((GObject*)inspector, -- 1.7.1 From hpdeifel at gmx.de Wed Jul 7 15:33:34 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Wed, 7 Jul 2010 17:33:34 +0200 Subject: [Vimprobable-users] [PATCH 1/2] don't jump to next match when pressing return in incremental search In-Reply-To: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> References: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> Message-ID: <1278516815-5089-2-git-send-email-hpdeifel@gmx.de> --- main.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..87770e8 100644 --- a/main.c +++ b/main.c @@ -517,9 +517,14 @@ inputbox_activate_cb(GtkEntry *entry, gpointer user_data) { webkit_web_view_set_highlight_text_matches(webview, TRUE); #endif count = 0; +#ifndef ENABLE_INCREMENTAL_SEARCH a.s =& text[1]; a.i = searchoptions | (forward ? DirectionForward : DirectionBackwards); search(&a); +#else + search_direction = forward; + search_handle = g_strdup(&text[1]); +#endif } else return; if (!echo_active) -- 1.7.1 From nealhogan at gmail.com Thu Jul 8 14:13:28 2010 From: nealhogan at gmail.com (Neal Hogan) Date: Thu, 8 Jul 2010 09:13:28 -0500 Subject: [Vimprobable-users] Insert in HINT-mode (vimprob2 v. 0.8.7.2) Message-ID: Hello, I've recently uprgaded to the 0.8.7.2 version (from 0.8.7.0) and insert via HINT-mode no longer works (when JavaScript is not enabled). This occurs running both standalone and embedded in tabbed. I noticed in the archives that there was an issue concerning insert after the browser loses focus. This is not the same issue, but I wonder if it is a concequence of the browser-focus-issue fix. To be clear, HINT mode works. I'm just unable to insert in that mode. However, PASS THROUGH mode (ctrl+z) allows insertion. I only bring up this issue because the vimprob homepage suggests that HINT mode may be enough to allow insertion when JavaScript isn't enabled. Thanks, -Neal OS: OpenBSD -current montagueneal sudo find / -name 'libwebkit*' Password: /usr/local/lib/libwebkit-1.0.a /usr/local/lib/libwebkit-1.0.la /usr/local/lib/libwebkit-1.0.so.2.1 From hannes at yllr.net Thu Jul 8 18:35:28 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Thu, 8 Jul 2010 20:35:28 +0200 Subject: [Vimprobable-users] Insert in HINT-mode (vimprob2 v. 0.8.7.2) In-Reply-To: References: Message-ID: <20100708183527.GA19152@laptop2.lan.localhost> Hi! On Thu, Jul 08, 2010 at 09:13:28AM -0500, Neal Hogan wrote: > I've recently uprgaded to the 0.8.7.2 version (from 0.8.7.0) and > insert via HINT-mode no longer works (when JavaScript is not enabled). > This occurs running both standalone and embedded in tabbed. I noticed > in the archives that there was an issue concerning insert after the > browser loses focus. This is not the same issue, but I wonder if it is > a concequence of the browser-focus-issue fix. To be clear, HINT mode > works. I'm just unable to insert in that mode. You mean if you hit 'f' and enter the number of an input field, INSERT mode isn't automatically activated? What happens? Is the cursor inserted into the field, but there is just no mode change? Or nothing at all happens? > /usr/local/lib/libwebkit-1.0.a > /usr/local/lib/libwebkit-1.0.la > /usr/local/lib/libwebkit-1.0.so.2.1 We tested with libwebkit-1.2 (which caused the focus issue) and libwebkit-1.1, but not with your version. Should this be related, I can only reiterate: This is exactly the reason why I asked (practically begged) people to test the patch before pushing it into the main branch. Hannes -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From nealhogan at gmail.com Thu Jul 8 20:06:33 2010 From: nealhogan at gmail.com (Neal Hogan) Date: Thu, 8 Jul 2010 15:06:33 -0500 Subject: [Vimprobable-users] Insert in HINT-mode (vimprob2 v. 0.8.7.2) In-Reply-To: <20100708183527.GA19152@laptop2.lan.localhost> References: <20100708183527.GA19152@laptop2.lan.localhost> Message-ID: 2010/7/8 Hannes Sch?ller : > Hi! > On Thu, Jul 08, 2010 at 09:13:28AM -0500, Neal Hogan wrote: >> I've recently uprgaded to the 0.8.7.2 version (from 0.8.7.0) and >> insert via HINT-mode no longer works (when JavaScript is not enabled). >> This occurs running both standalone and embedded in tabbed. I noticed >> in the archives that there was an issue concerning insert after the >> browser loses focus. This is not the same issue, but I wonder if it is >> a concequence of the browser-focus-issue fix. To be clear, HINT mode >> works. I'm just unable to insert in that mode. > > You mean if you hit 'f' and enter the number of an input field, INSERT > mode isn't automatically activated? What happens? Is the cursor inserted > into the field, but there is just no mode change? Or nothing at all > happens? The cursor remains (blinking), but nothing occurs. That is, nothing inputs. FYI - I've never seen the INSERT mode indication at the bottom-left of the term when hitting 'f'. It just worked. > >> /usr/local/lib/libwebkit-1.0.a >> /usr/local/lib/libwebkit-1.0.la >> /usr/local/lib/libwebkit-1.0.so.2.1 > > We tested with libwebkit-1.2 (which caused the focus issue) and > libwebkit-1.1, but not with your version. Should this be related, I can > only reiterate: This is exactly the reason why I asked (practically > begged) people to test the patch before pushing it into the main branch. > Ya . . . sorry about that. I just joined the list today. In the end it's not a huge deal because PASS THROUGH mode works, but I don't know if that is what you want. Thanks for you time and work . . . especially the ability to view some movies now! From thomas at xteddy.org Fri Jul 9 05:29:39 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 9 Jul 2010 06:29:39 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Add -g -ggdb to Makefile by default. Message-ID: <20100709052936.GA18079@shuttle.home> It makes sense to enable debug by default, and keeping the symbols around. This is also ensured by removing the call to strip to remove all symbols. --- Makefile | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 2c3a814..0ea13bb 100644 --- a/Makefile +++ b/Makefile @@ -12,7 +12,7 @@ CLEAN = $(TARGET) $(OBJ) $(DEPS) hintingmode.h INSTALL = $(BINDIR)/$(TARGET) $(addprefix $(MANDIR)/man1/,$(MAN)) CFLAGS += `pkg-config --cflags $(LIBS)` -LDFLAGS += `pkg-config --libs $(LIBS)` +LDFLAGS += `pkg-config --libs $(LIBS)` -g -ggdb PREFIX ?= /usr/local BINDIR ?= $(PREFIX)/bin @@ -51,7 +51,6 @@ uninstall: $(DESTDIR)/$(BINDIR)/%: ./% -[ -e '$(@D)' ] || mkdir -p '$(@D)' && chmod $(DMOD) '$(@D)' cp -f '$<' '$@' - -strip -s '$@' chmod $(EXECMOD) '$@' # pattern rule to install manpages 1.6.6.196.g1f735 From hannes at yllr.net Fri Jul 9 14:05:43 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Fri, 9 Jul 2010 16:05:43 +0200 Subject: [Vimprobable-users] Insert in HINT-mode (vimprob2 v. 0.8.7.2) In-Reply-To: References: <20100708183527.GA19152@laptop2.lan.localhost> Message-ID: <20100709140543.GA4853@laptop2.lan.localhost> On Thu, Jul 08, 2010 at 03:06:33PM -0500, Neal Hogan wrote: > 2010/7/8 Hannes Sch?ller : > > On Thu, Jul 08, 2010 at 09:13:28AM -0500, Neal Hogan wrote: > >> I've recently uprgaded to the 0.8.7.2 version (from 0.8.7.0) and > >> insert via HINT-mode no longer works (when JavaScript is not enabled). > >> This occurs running both standalone and embedded in tabbed. I noticed > >> in the archives that there was an issue concerning insert after the > >> browser loses focus. This is not the same issue, but I wonder if it is > >> a concequence of the browser-focus-issue fix. To be clear, HINT mode > >> works. I'm just unable to insert in that mode. > > > > You mean if you hit 'f' and enter the number of an input field, INSERT > > mode isn't automatically activated? What happens? Is the cursor inserted > > into the field, but there is just no mode change? Or nothing at all > > happens? > > The cursor remains (blinking), but nothing occurs. That is, nothing > inputs. FYI - I've never seen the INSERT mode indication at the > bottom-left of the term when hitting 'f'. It just worked. Strange... though it indicates there are deeper issues with your libwebkit version. Anyone else who can reproduce this? > >> /usr/local/lib/libwebkit-1.0.a > >> /usr/local/lib/libwebkit-1.0.la > >> /usr/local/lib/libwebkit-1.0.so.2.1 So which versions are these exactly? Mine is called libwebkit-1.0, version 1.2.1, for example. Very confusing naming scheme. Hannes From hannes at yllr.net Fri Jul 9 14:06:32 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Fri, 9 Jul 2010 16:06:32 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Add -g -ggdb to Makefile by default. In-Reply-To: <20100709052936.GA18079@shuttle.home> References: <20100709052936.GA18079@shuttle.home> Message-ID: <20100709140631.GB4853@laptop2.lan.localhost> On Fri, Jul 09, 2010 at 06:29:39AM +0100, Thomas Adam wrote: > It makes sense to enable debug by default, and keeping the symbols around. > This is also ensured by removing the call to strip to remove all symbols. I don't know if this is a sensible decision. Any other opinions? Hannes From thomas at xteddy.org Fri Jul 9 14:09:52 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 9 Jul 2010 15:09:52 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Add -g -ggdb to Makefile by default. In-Reply-To: <20100709140631.GB4853@laptop2.lan.localhost> References: <20100709052936.GA18079@shuttle.home> <20100709140631.GB4853@laptop2.lan.localhost> Message-ID: Hi -- 2010/7/9 Hannes Sch?ller : > On Fri, Jul 09, 2010 at 06:29:39AM +0100, Thomas Adam wrote: >> It makes sense to enable debug by default, and keeping the symbols around. >> This is also ensured by removing the call to strip to remove all symbols. > > I don't know if this is a sensible decision. Any other opinions? Well, it's sensible only in that: * It doesn't add anything to the size of the binary that isn't acceptable (65K) * Any coredumps from Vimprobable should ensure that GDB can do something with the symbols -- c.f. problems hard to reproduce. * Stripping binaries in this day and age to save space seems a little odd to me -- especially given Vimprobable's binary's size. :) That's my justification for it -- as I appreciate the commit message wasn't quite clear. :) -- Thomas Adam From wmdiem at gmail.com Sat Jul 10 15:45:49 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 15:45:49 +0000 Subject: [Vimprobable-users] crash on form entry Message-ID: vimprobable2 crashes when entering my username (look at my email address) at any google site, unless I enter it _very_ slowly (in the area of one key per second). Actually I've noticed that entering it slowly works at gmail but not googleanalytics (analytics sign in always crashes when I hit the d no matter how long I count between keystrokes). Further the password field is no problem at gmail, but at google analytics it is just odd, some (most) keys get swallowed, some are interpreted as though I wasn't in insert mode (e.g., o) a handful get passed through, and actually when I tried to test the individual letters, by going through the alphabet, it crashed. Also, unrelated but making this worse, cookies don't seem to be shared between instances, so if I have gmail open, and go to googleanalytics in another window I have to sign in again. Entirely unrelated to either of the above, I'm not sure if it is an issue with mysetup or whether it is a general problem but flash is wierd: If there is flash on the page, and I scroll down so it is no longer visible, I get a big grey box the size of the flash object over the page (I've noticed this with some of the other minimal webkit browsers. It is easily reproduced at youtube, start the video and scroll down to the comments so the player is entirely offscreen. Anyway, I really like vimprobable, it is quite well done in my opinion. Thanks for providing it. If I have some spare time I might have to crack open the source and play around, see whether I can track any of these down. Thanks, Will From hannes at yllr.net Sat Jul 10 15:59:55 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 10 Jul 2010 17:59:55 +0200 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: Message-ID: <20100710155955.GA12619@laptop2.lan.localhost> Hello William! On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: > Also, unrelated but making this worse, cookies don't seem to be shared > between instances, so if I have gmail open, and go to googleanalytics > in another window I have to sign in again. This is not a bug. As for the rest, could you please let us know: - Vimprobable version - libwebkit version - exact description of when you're in which mode - whether Javascript is activated - how you jump into the input fields - and so on Hannes From wmdiem at gmail.com Sat Jul 10 16:10:26 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 16:10:26 +0000 Subject: [Vimprobable-users] crash on form entry In-Reply-To: <20100710155955.GA12619@laptop2.lan.localhost> References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: >> Also, unrelated but making this worse, cookies don't seem to be shared >> between instances, so if I have gmail open, and go to googleanalytics >> in another window I have to sign in again. > > This is not a bug. I was afraid of that. > - Vimprobable version $ vimprobable2 -v Vimprobable2/0.8.7.2 > - libwebkit version $ dpkg -l | grep libwebk ii libwebkit-1.0-2 1.2.1-2 Web content engine library for Gtk+ ii libwebkit-1.0-common 1.2.1-2 Web content engine library for Gtk+ - data files ii libwebkit-dev 1.2.1-2 Web content engine library for Gtk+ - Development files > - exact description of when you're in which mode When I navigate to gmail.com it automatically focuses the username field, and switches to insert. As to analytics, it really is just odd. I'll try and get back to you. > - whether Javascript is activated I assume js is active: I haven't deactivated it, and things that use js seem to work (i.e., google's autosuggestions). > - how you jump into the input fields I got into the fields by opening the page (I like this feature btw), per above. Thanks, Will 2010/7/10 Hannes Sch?ller : > Hello William! > > On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: >> Also, unrelated but making this worse, cookies don't seem to be shared >> between instances, so if I have gmail open, and go to googleanalytics >> in another window I have to sign in again. > > This is not a bug. > > As for the rest, could you please let us know: > - Vimprobable version > - libwebkit version > - exact description of when you're in which mode > - whether Javascript is activated > - how you jump into the input fields > - and so on > > Hannes > > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > From wmdiem at gmail.com Sat Jul 10 16:55:00 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 16:55:00 +0000 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: okay, here is what happens at googleanalytics signin page. One I get to it, the email field is focused, the browser is in insert mode (I assume it doesn't actually say). I type wmd and it crashes. If I go back and tab to password: (first off I should not that the command bar area is red, this may be because I consistently try to acitivate link hinting on the previous page (via 'f') before the page is finished loading: BTW, this is another bug I suppose I should report while I'm at it, link hinting doesn't work untill the page has finished loading. a-c -> accepted as input into the field d -> crashes e -> accepted f -> activates link hinting g -> takes me to the top of the page now I'm starting to see a pattern: bound keys are being interpreted rather than passed through h -> takes me back to the vimprobable page i ->accepted j -> swallowed k -> seems to move the page up l ->swallowed m -> passed to the form n ->swallowed I think the pattern is well enough established, it isn't really in input mode. Problem is if I hit 'i' to put it explicitely in input mode, the i goes to the form filed. Clicking the field results in the same behavior. So it looks like i'm in a pseudo-insert mode, everything gets passed through unless it is bound. This also seems to be happening in the email field. What is really odd is that on gmail's signin form, it behaves and passes everything through *as long as I enter them very slowly*. If the first character is a 'd' it still closes though. *perplexed* Will On 10/07/2010, William Diem wrote: >>> Also, unrelated but making this worse, cookies don't seem to be shared >>> between instances, so if I have gmail open, and go to googleanalytics >>> in another window I have to sign in again. >> >> This is not a bug. > > I was afraid of that. > >> - Vimprobable version > $ vimprobable2 -v > Vimprobable2/0.8.7.2 > >> - libwebkit version > $ dpkg -l | grep libwebk > ii libwebkit-1.0-2 1.2.1-2 > Web content engine library for Gtk+ > ii libwebkit-1.0-common 1.2.1-2 > Web content engine library for Gtk+ - data files > ii libwebkit-dev 1.2.1-2 > Web content engine library for Gtk+ - Development files > >> - exact description of when you're in which mode > When I navigate to gmail.com it automatically focuses the username > field, and switches to insert. > As to analytics, it really is just odd. I'll try and get back to you. > >> - whether Javascript is activated > I assume js is active: I haven't deactivated it, and things that use > js seem to work (i.e., google's autosuggestions). > >> - how you jump into the input fields > I got into the fields by opening the page (I like this feature btw), per > above. > > > Thanks, > Will > > 2010/7/10 Hannes Sch?ller : >> Hello William! >> >> On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: >>> Also, unrelated but making this worse, cookies don't seem to be shared >>> between instances, so if I have gmail open, and go to googleanalytics >>> in another window I have to sign in again. >> >> This is not a bug. >> >> As for the rest, could you please let us know: >> - Vimprobable version >> - libwebkit version >> - exact description of when you're in which mode >> - whether Javascript is activated >> - how you jump into the input fields >> - and so on >> >> Hannes >> >> _______________________________________________ >> Vimprobable-users mailing list >> Vimprobable-users at vimprobable.org >> http://vimprobable.org/mailman/listinfo/vimprobable-users >> > From wmdiem at gmail.com Sat Jul 10 17:05:32 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 17:05:32 +0000 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: Okay I've formed an hypothesis of what's happening: google's sign in page isn't bahaving like a normal form. Rather it is trying to emulate a form with js, so it is listening for keypresses. Thus if you explicitely leave insert mode (esc) keys still show up in the form. I suppose this is a crude way to detect if someone is trying to automate the login processes. Although it does introduce an interesting problem that can be seen in other places, what happens when a page tries to listen for keys that vimprobable has already bound? Also, 'i' is bound. Why does it get passed through rather than put me in insert mode? Please note, I haven't actually looked at the js to substantiate that this is what's happening, but the sympoms seem to fit. Best, Will On 10/07/2010, William Diem wrote: > okay, here is what happens at googleanalytics signin page. > One I get to it, the email field is focused, the browser is in insert > mode (I assume it doesn't actually say). > I type wmd and it crashes. > If I go back and tab to password: > (first off I should not that the command bar area is red, this may be > because I consistently try to acitivate link hinting on the previous > page (via 'f') before the page is finished loading: BTW, this is > another bug I suppose I should report while I'm at it, link hinting > doesn't work untill the page has finished loading. > a-c -> accepted as input into the field > d -> crashes > e -> accepted > f -> activates link hinting > g -> takes me to the top of the page > > now I'm starting to see a pattern: bound keys are being interpreted > rather than passed through > > h -> takes me back to the vimprobable page > i ->accepted > j -> swallowed > k -> seems to move the page up > l ->swallowed > m -> passed to the form > n ->swallowed > > I think the pattern is well enough established, it isn't really in input > mode. > Problem is if I hit 'i' to put it explicitely in input mode, the i > goes to the form filed. > Clicking the field results in the same behavior. > So it looks like i'm in a pseudo-insert mode, everything gets passed > through unless it is bound. This also seems to be happening in the > email field. > > What is really odd is that on gmail's signin form, it behaves and > passes everything through *as long as I enter them very slowly*. If > the first character is a 'd' it still closes though. > > *perplexed* > > Will > > > On 10/07/2010, William Diem wrote: >>>> Also, unrelated but making this worse, cookies don't seem to be shared >>>> between instances, so if I have gmail open, and go to googleanalytics >>>> in another window I have to sign in again. >>> >>> This is not a bug. >> >> I was afraid of that. >> >>> - Vimprobable version >> $ vimprobable2 -v >> Vimprobable2/0.8.7.2 >> >>> - libwebkit version >> $ dpkg -l | grep libwebk >> ii libwebkit-1.0-2 1.2.1-2 >> Web content engine library for Gtk+ >> ii libwebkit-1.0-common 1.2.1-2 >> Web content engine library for Gtk+ - data files >> ii libwebkit-dev 1.2.1-2 >> Web content engine library for Gtk+ - Development files >> >>> - exact description of when you're in which mode >> When I navigate to gmail.com it automatically focuses the username >> field, and switches to insert. >> As to analytics, it really is just odd. I'll try and get back to you. >> >>> - whether Javascript is activated >> I assume js is active: I haven't deactivated it, and things that use >> js seem to work (i.e., google's autosuggestions). >> >>> - how you jump into the input fields >> I got into the fields by opening the page (I like this feature btw), per >> above. >> >> >> Thanks, >> Will >> >> 2010/7/10 Hannes Sch?ller : >>> Hello William! >>> >>> On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: >>>> Also, unrelated but making this worse, cookies don't seem to be shared >>>> between instances, so if I have gmail open, and go to googleanalytics >>>> in another window I have to sign in again. >>> >>> This is not a bug. >>> >>> As for the rest, could you please let us know: >>> - Vimprobable version >>> - libwebkit version >>> - exact description of when you're in which mode >>> - whether Javascript is activated >>> - how you jump into the input fields >>> - and so on >>> >>> Hannes >>> >>> _______________________________________________ >>> Vimprobable-users mailing list >>> Vimprobable-users at vimprobable.org >>> http://vimprobable.org/mailman/listinfo/vimprobable-users >>> >> > From wmdiem at gmail.com Sat Jul 10 17:31:43 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 17:31:43 +0000 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: It looks like the magic is in this beast: https://ssl.google-analytics.com/ga.js Best, wmd On 10/07/2010, William Diem wrote: > Okay I've formed an hypothesis of what's happening: google's sign in > page isn't bahaving like a normal form. Rather it is trying to emulate > a form with js, so it is listening for keypresses. Thus if you > explicitely leave insert mode (esc) keys still show up in the form. > > I suppose this is a crude way to detect if someone is trying to > automate the login processes. > > Although it does introduce an interesting problem that can be seen in > other places, what happens when a page tries to listen for keys that > vimprobable has already bound? > > Also, 'i' is bound. Why does it get passed through rather than put me > in insert mode? > > Please note, I haven't actually looked at the js to substantiate that > this is what's happening, but the sympoms seem to fit. > > Best, > Will > > On 10/07/2010, William Diem wrote: >> okay, here is what happens at googleanalytics signin page. >> One I get to it, the email field is focused, the browser is in insert >> mode (I assume it doesn't actually say). >> I type wmd and it crashes. >> If I go back and tab to password: >> (first off I should not that the command bar area is red, this may be >> because I consistently try to acitivate link hinting on the previous >> page (via 'f') before the page is finished loading: BTW, this is >> another bug I suppose I should report while I'm at it, link hinting >> doesn't work untill the page has finished loading. >> a-c -> accepted as input into the field >> d -> crashes >> e -> accepted >> f -> activates link hinting >> g -> takes me to the top of the page >> >> now I'm starting to see a pattern: bound keys are being interpreted >> rather than passed through >> >> h -> takes me back to the vimprobable page >> i ->accepted >> j -> swallowed >> k -> seems to move the page up >> l ->swallowed >> m -> passed to the form >> n ->swallowed >> >> I think the pattern is well enough established, it isn't really in input >> mode. >> Problem is if I hit 'i' to put it explicitely in input mode, the i >> goes to the form filed. >> Clicking the field results in the same behavior. >> So it looks like i'm in a pseudo-insert mode, everything gets passed >> through unless it is bound. This also seems to be happening in the >> email field. >> >> What is really odd is that on gmail's signin form, it behaves and >> passes everything through *as long as I enter them very slowly*. If >> the first character is a 'd' it still closes though. >> >> *perplexed* >> >> Will >> >> >> On 10/07/2010, William Diem wrote: >>>>> Also, unrelated but making this worse, cookies don't seem to be shared >>>>> between instances, so if I have gmail open, and go to googleanalytics >>>>> in another window I have to sign in again. >>>> >>>> This is not a bug. >>> >>> I was afraid of that. >>> >>>> - Vimprobable version >>> $ vimprobable2 -v >>> Vimprobable2/0.8.7.2 >>> >>>> - libwebkit version >>> $ dpkg -l | grep libwebk >>> ii libwebkit-1.0-2 1.2.1-2 >>> Web content engine library for Gtk+ >>> ii libwebkit-1.0-common 1.2.1-2 >>> Web content engine library for Gtk+ - data files >>> ii libwebkit-dev 1.2.1-2 >>> Web content engine library for Gtk+ - Development files >>> >>>> - exact description of when you're in which mode >>> When I navigate to gmail.com it automatically focuses the username >>> field, and switches to insert. >>> As to analytics, it really is just odd. I'll try and get back to you. >>> >>>> - whether Javascript is activated >>> I assume js is active: I haven't deactivated it, and things that use >>> js seem to work (i.e., google's autosuggestions). >>> >>>> - how you jump into the input fields >>> I got into the fields by opening the page (I like this feature btw), per >>> above. >>> >>> >>> Thanks, >>> Will >>> >>> 2010/7/10 Hannes Sch?ller : >>>> Hello William! >>>> >>>> On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: >>>>> Also, unrelated but making this worse, cookies don't seem to be shared >>>>> between instances, so if I have gmail open, and go to googleanalytics >>>>> in another window I have to sign in again. >>>> >>>> This is not a bug. >>>> >>>> As for the rest, could you please let us know: >>>> - Vimprobable version >>>> - libwebkit version >>>> - exact description of when you're in which mode >>>> - whether Javascript is activated >>>> - how you jump into the input fields >>>> - and so on >>>> >>>> Hannes >>>> >>>> _______________________________________________ >>>> Vimprobable-users mailing list >>>> Vimprobable-users at vimprobable.org >>>> http://vimprobable.org/mailman/listinfo/vimprobable-users >>>> >>> >> > From thomas at xteddy.org Sat Jul 10 19:03:06 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 10 Jul 2010 20:03:06 +0100 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: Message-ID: <20100710190303.GA3076@shuttle.home> On Sat, Jul 10, 2010 at 03:45:49PM +0000, William Diem wrote: > vimprobable2 crashes when entering my username (look at my email > address) at any google site, unless I enter it _very_ slowly (in the > area of one key per second). Actually I've noticed that entering it > slowly works at gmail but not googleanalytics (analytics sign in > always crashes when I hit the d no matter how long I count between Are you sure this isn't a symptom of you NOT setting PASSTHROUGH mode? See ^Z when an input field is focused. I am somewhat dubious of the term "crash" here, since if your username and/or password contained the letter "d", and the browser was in command-mode or you hadn't set PASSTHROUGH mode on the input field, then yes, the browser would close. If, OTOH, Vimprobable really is creashing, do you get a corefile and hence a backtrace from it? > keystrokes). Further the password field is no problem at gmail, but at > google analytics it is just odd, some (most) keys get swallowed, some > are interpreted as though I wasn't in insert mode (e.g., o) a handful > get passed through, and actually when I tried to test the individual > letters, by going through the alphabet, it crashed. See above. > Also, unrelated but making this worse, cookies don't seem to be shared > between instances, so if I have gmail open, and go to googleanalytics > in another window I have to sign in again. Correct -- there's no way of "fixing" this. > Entirely unrelated to either of the above, I'm not sure if it is an > issue with mysetup or whether it is a general problem but flash is > wierd: If there is flash on the page, and I scroll down so it is no > longer visible, I get a big grey box the size of the flash object over > the page (I've noticed this with some of the other minimal webkit > browsers. It is easily reproduced at youtube, start the video and > scroll down to the comments so the player is entirely offscreen. I thought I saw this reported upstream at webkit.org -- you can always check. -- Thomas Adam -- "Deep in my heart I wish I was wrong. But deep in my heart I know I am not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.) From hannes at yllr.net Sat Jul 10 19:12:34 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 10 Jul 2010 21:12:34 +0200 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: <20100710191234.GC12619@laptop2.lan.localhost> Thomas has already replied to some of this, so I'll make it short. > One I get to it, the email field is focused, the browser is in insert > mode (I assume it doesn't actually say). If it doesn't say anything, you are in command mode. Hence... > a-c -> accepted as input into the field > d -> crashes > e -> accepted > f -> activates link hinting > g -> takes me to the top of the page ...the regular keybindings are active. a-c aren't handled by Vimprobable, so they're passed to Webkit which inserts them into the field. 'd' closes the browser (this is not a crash). And so on. > Problem is if I hit 'i' to put it explicitely in input mode, the i > goes to the form filed. 'i' doesn't activate INSERT mode. If you want to explicitely make sure keystrokes are sent to Webkit, use PASSTHROUGH mode (Ctrl+z). The behaviour you describe is completely consistent with regular command mode. Bound keys are interpreted, other keys are passed through. In case you've got a receptor field active on the page, non-bound keys will be inserted. All that is normal. Hannes From hannes at yllr.net Sat Jul 10 19:15:15 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sat, 10 Jul 2010 21:15:15 +0200 Subject: [Vimprobable-users] crash on form entry In-Reply-To: References: <20100710155955.GA12619@laptop2.lan.localhost> Message-ID: <20100710191514.GD12619@laptop2.lan.localhost> On Sat, Jul 10, 2010 at 05:05:32PM +0000, William Diem wrote: > Okay I've formed an hypothesis of what's happening: google's sign in > page isn't bahaving like a normal form. Rather it is trying to emulate > a form with js, so it is listening for keypresses. You mean it's using onkeyup or onkeydown Javascript events? > Thus if you explicitely leave insert mode (esc) keys still show up in > the form. As I said in the other mail, this is normal behaviour for non-bound keys. > Although it does introduce an interesting problem that can be seen in > other places, what happens when a page tries to listen for keys that > vimprobable has already bound? You use PASSTHROUGH mode. > Also, 'i' is bound. Why does it get passed through rather than put me > in insert mode? Because your assumption is incorrect. 'i' isn't bound to anything in the default configuration. Hannes From wmdiem at gmail.com Sat Jul 10 19:30:06 2010 From: wmdiem at gmail.com (William Diem) Date: Sat, 10 Jul 2010 19:30:06 +0000 Subject: [Vimprobable-users] crash on form entry In-Reply-To: <20100710191514.GD12619@laptop2.lan.localhost> References: <20100710155955.GA12619@laptop2.lan.localhost> <20100710191514.GD12619@laptop2.lan.localhost> Message-ID: > Are you sure this isn't a symptom of you NOT setting PASSTHROUGH mode? ?See > ^Z when an input field is focused. ?I am somewhat dubious of the term > "crash" here, since if your username and/or password contained the letter > "d", and the browser was in command-mode or you hadn't set PASSTHROUGH mode > on the input field, then yes, the browser would close. Yeah, you were right. I'll RTFM next time. Thanks for your patience. Will 2010/7/10 Hannes Sch?ller : > On Sat, Jul 10, 2010 at 05:05:32PM +0000, William Diem wrote: >> Okay I've formed an hypothesis of what's happening: google's sign in >> page isn't bahaving like a normal form. Rather it is trying to emulate >> a form with js, so it is listening for keypresses. > > You mean it's using onkeyup or onkeydown Javascript events? > >> Thus if you explicitely leave insert mode (esc) keys still show up in >> the form. > > As I said in the other mail, this is normal behaviour for non-bound > keys. > >> Although it does introduce an interesting problem that can be seen in >> other places, what happens when a page tries to listen for keys that >> vimprobable has already bound? > > You use PASSTHROUGH mode. > >> Also, 'i' is bound. Why does it get passed through rather than put me >> in insert mode? > > Because your assumption is incorrect. 'i' isn't bound to anything in the > default configuration. > > Hannes > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > From thomas.adam22 at gmail.com Sat Jul 10 20:17:22 2010 From: thomas.adam22 at gmail.com (Thomas Adam) Date: Sat, 10 Jul 2010 21:17:22 +0100 Subject: [Vimprobable-users] [PATCH 0/2] Problems with incremental search In-Reply-To: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> References: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> Message-ID: <20100710201720.GA2026@debian> Hi -- On Wed, Jul 07, 2010 at 05:33:33PM +0200, Hans-Peter Deifel wrote: > Hi, > > I found some problems with incremental search: > > 1. Typing a capital letter skips one match. > 2. Pressing and releasing modifier-keys skips one match. > 3. Typing too fast can skip matches. > 4. Pressing return also jumps to the next match. I've taken a look at both your patches, they're excellent, thanks. I've not had any problems using them, and neither have they given me any problems, so I think they're "safe" from breaking what would appear to be unrelated areas of Vimprobable. :) The only thing I would say is that I am finding more and more #ifdefs becoming visually annoying in the code -- I appreciate why they're used, we could get away with reducing the amount, and only keeping the following #ifdef: +#ifdef ENABLE_INCREMENTAL_SEARCH + "signal::changed", (GCallback)inputbox_changed_cb, NULL, +#endif But at this point it's only cosmetic and would go against the trend set elsewhere for #ifdef's use. -- Thomas Adam -- "It was the cruelest game I've ever played and it's played inside my head." -- "Hush The Warmth", Gorky's Zygotic Mynci. From thomas at xteddy.org Sat Jul 10 21:26:53 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sat, 10 Jul 2010 22:26:53 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Check for HTTP_PROXY as well as http_proxy Message-ID: <20100710212650.GA8753@debian> When looking for a proxy to toggle with, check not only http_proxy, but HTTP_PROXY. Although considered old now, the HTTP_PROXY environment variable can still be defined to specify a proxy. But only check for HTTP_PROXY if http_proxy returns NULL. --- main.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..a7f1044 100644 --- a/main.c +++ b/main.c @@ -1861,6 +1861,13 @@ toggle_proxy(gboolean onoff) { echo(&a); } else { filename = (char *)g_getenv("http_proxy"); + + /* Fallthrough to checking HTTP_PROXY as well, since this can also be + * defined. + */ + if (filename == NULL) + filename = (char *)g_getenv("HTTP_PROXY"); + if (filename != NULL && 0 < (len = strlen(filename))) { if (strstr(filename, "://") == NULL) { /* prepend http:// */ -- 1.7.1 From norenberg at o2.pl Sun Jul 11 00:13:33 2010 From: norenberg at o2.pl (=?UTF-8?Q?norenberg?=) Date: Sun, 11 Jul 2010 02:13:33 +0200 Subject: [Vimprobable-users] =?utf-8?q?=5BPATCH=5D_Scrolling?= Message-ID: <47bfce57.582886f8.4c390cad.8640@o2.pl> Hi, While browsing long pages Vimprobable make me unable to reach the very top or bottom of the page i.e. the first or the last % (well, i could only achive that by moving form Top or Bot and then use gg or G) This little patch should make it better. ----- And as it is my first mail here I'd like to say hello and thank you all for the greatest browser I've had pleasure to use! ----- diff --git a/main.c b/main.c index 1d47494..f5cdd0b 100644 --- a/main.c +++ b/main.c @@ -1206,7 +1206,6 @@ scroll(const Arg *arg) { float val = (int)(gtk_adjustment_get_value(adjust) / max * 100); int direction = (arg->i & (1 << 2)) ? 1 : -1; - if ((direction == 1 && val < 100) || (direction == -1 && val > 0)) { if (arg->i & ScrollMove) gtk_adjustment_set_value(adjust, gtk_adjustment_get_value(adjust) + direction * /* direction */ @@ -1217,8 +1216,11 @@ scroll(const Arg *arg) { else gtk_adjustment_set_value(adjust, ((direction == 1) ? gtk_adjustment_get_upper : gtk_adjustment_get_lower)(adjust)); + + if( (int)gtk_adjustment_get_value(adjust) > max) + gtk_adjustment_set_value(adjust, max); + update_state(); - } return TRUE; } From hannes at yllr.net Sun Jul 11 08:56:50 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sun, 11 Jul 2010 10:56:50 +0200 Subject: [Vimprobable-users] [PATCH] Scrolling In-Reply-To: <47bfce57.582886f8.4c390cad.8640@o2.pl> References: <47bfce57.582886f8.4c390cad.8640@o2.pl> Message-ID: <20100711085649.GA7400@laptop2.lan.localhost> On Sun, Jul 11, 2010 at 02:13:33AM +0200, norenberg wrote: > While browsing long pages Vimprobable make me unable to reach the very top or > bottom of the page i.e. the first or the last % (well, i could only achive > that by moving form Top or Bot and then use gg or G) I know this problem existed in very old version, but I thought I had fixed it already some months ago. Could you point out a site where it still occurs in the current version? Hannes From hpdeifel at gmx.de Sun Jul 11 09:27:23 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sun, 11 Jul 2010 11:27:23 +0200 Subject: [Vimprobable-users] [PATCH 2/2] Update incremental search only when the search string changes In-Reply-To: <1278516815-5089-3-git-send-email-hpdeifel@gmx.de> References: <1278516815-5089-1-git-send-email-hpdeifel@gmx.de> <1278516815-5089-3-git-send-email-hpdeifel@gmx.de> Message-ID: <20100711092723.GA3592@deepsilver> Here is the same thing with fewer #ifdefs, as Thomas suggessted in another mail. --- main.c | 31 ++++++++++++++++++++++++------- 1 files changed, 24 insertions(+), 7 deletions(-) diff --git a/main.c b/main.c index 87770e8..1dc2e83 100644 --- a/main.c +++ b/main.c @@ -18,6 +18,7 @@ static void inputbox_activate_cb(GtkEntry *entry, gpointer user_data); static gboolean inputbox_keypress_cb(GtkEntry *entry, GdkEventKey *event); static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event); +static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data); static WebKitWebView* inspector_inspect_web_view_cb(gpointer inspector, WebKitWebView* web_view); static gboolean notify_event_cb(GtkWidget *widget, GdkEvent *event, gpointer user_data); static gboolean webview_console_cb(WebKitWebView *webview, char *message, int line, char *source, gpointer user_data); @@ -589,22 +590,35 @@ notify_event_cb(GtkWidget *widget, GdkEvent *event, gpointer user_data) { static gboolean inputbox_keyrelease_cb(GtkEntry *entry, GdkEventKey *event) { Arg a; guint16 length = gtk_entry_get_text_length(entry); -#ifdef ENABLE_INCREMENTAL_SEARCH - char *text = (char*)gtk_entry_get_text(entry); - gboolean forward = FALSE; -#endif + if (!length) { a.i = HideCompletion; complete(&a); a.i = ModeNormal; return set(&a); } -#ifdef ENABLE_INCREMENTAL_SEARCH - else if (length > 1 && ((forward = text[0] == '/') || text[0] == '?')) { + return FALSE; +} + +static gboolean inputbox_changed_cb(GtkEditable *entry, gpointer user_data) { + char *text = (char*)gtk_entry_get_text(GTK_ENTRY(entry)); + guint16 length = gtk_entry_get_text_length(GTK_ENTRY(entry)); + gboolean forward = FALSE; + + /* Update incremental search if the user changes the search text. + * + * Note: gtk_widget_is_focus() is a poor way to check if the change comes + * from the user. But if the entry is focused and the text is set + * through gtk_entry_set_text() in some asyncrounous operation, + * I would consider that a bug. + */ + + if (gtk_widget_is_focus(GTK_WIDGET(entry)) && length > 1 && ((forward = text[0] == '/') || text[0] == '?')) { webkit_web_view_unmark_text_matches(webview); webkit_web_view_search_text(webview, &text[1], searchoptions & CaseSensitive, forward, searchoptions & Wrapping); + return TRUE; } -#endif + return FALSE; } @@ -2107,6 +2121,9 @@ setup_signals() { "signal::activate", (GCallback)inputbox_activate_cb, NULL, "signal::key-press-event", (GCallback)inputbox_keypress_cb, NULL, "signal::key-release-event", (GCallback)inputbox_keyrelease_cb, NULL, +#ifdef ENABLE_INCREMENTAL_SEARCH + "signal::changed", (GCallback)inputbox_changed_cb, NULL, +#endif NULL); /* inspector */ g_signal_connect((GObject*)inspector, -- From thomas at xteddy.org Sun Jul 11 11:30:48 2010 From: thomas at xteddy.org (Thomas Adam) Date: Sun, 11 Jul 2010 12:30:48 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Clear ascii_bar when download complete. Message-ID: <20100711113044.GA4578@shuttle.home> When a download in Vimprobable has completed, and ENABLE_WGET_PROGRESS_BAR is in use, the ascii_bar would still be displayed, because there was not an additional check for activeDownload not being NULL. This fixes that condition. --- main.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 34fdb1e..56e09cf 100644 --- a/main.c +++ b/main.c @@ -1939,7 +1939,8 @@ update_state() { } else { markup = (char*)g_markup_printf_escaped("%.0d%c %s", statusfont, count, current_modkey, scroll_state); } - } else if (webkit_web_view_get_load_status(webview) != WEBKIT_LOAD_FINISHED) { + } else if ((webkit_web_view_get_load_status(webview) != WEBKIT_LOAD_FINISHED) && + (activeDownload != NULL)) { ascii_bar(progressbartick, (int)(progress * progressbartick), (char*)progressbar); markup = (char*)g_markup_printf_escaped("%.0d%c %c%s%c %s", statusfont, count, current_modkey, progressborderleft, progressbar, progressborderright, scroll_state); 1.6.6.196.g1f735 From norenberg at o2.pl Mon Jul 12 21:17:18 2010 From: norenberg at o2.pl (=?UTF-8?Q?norenberg?=) Date: Mon, 12 Jul 2010 23:17:18 +0200 Subject: [Vimprobable-users] =?utf-8?q?=5BPATCH=5D_Scrolling?= In-Reply-To: <20100711085649.GA7400@laptop2.lan.localhost> References: <47bfce57.582886f8.4c390cad.8640@o2.pl> <20100711085649.GA7400@laptop2.lan.localhost> Message-ID: <76d19d76.50659231.4c3b865e.8da5b@o2.pl> > I know this problem existed in very old version, but I thought I had > fixed it already some months ago. Could you point out a site where it > still occurs in the current version? > > Hannes Well, I must have missed something... The problem was with 0.9.13.0 or so. Sorry for making mess. Anyway 0.9.13.0 wasn't so old, was it? No problem with 0.9.14.1 From hannes at yllr.net Tue Jul 13 07:56:17 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Tue, 13 Jul 2010 09:56:17 +0200 Subject: [Vimprobable-users] [PATCH] Scrolling In-Reply-To: <76d19d76.50659231.4c3b865e.8da5b@o2.pl> References: <47bfce57.582886f8.4c390cad.8640@o2.pl> <20100711085649.GA7400@laptop2.lan.localhost> <76d19d76.50659231.4c3b865e.8da5b@o2.pl> Message-ID: <20100713075616.GB25633@laptop2.lan.localhost> On Mon, Jul 12, 2010 at 11:17:18PM +0200, norenberg wrote: > > I know this problem existed in very old version, but I thought I had > > fixed it already some months ago. Could you point out a site where it > > still occurs in the current version? > > Well, I must have missed something... The problem was with 0.9.13.0 or so. > Sorry for making mess. Anyway 0.9.13.0 wasn't so old, was it? > > No problem with 0.9.14.1 Your report was correct, don't worry. It was there until 0.9.14.0 - there was a wrong cast in there. It was just that I didn't hear anything from you anymore, so I didn't announce the fix. Hannes From hannes at yllr.net Wed Jul 14 11:00:27 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Wed, 14 Jul 2010 13:00:27 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Clear ascii_bar when download complete. In-Reply-To: <20100711113044.GA4578@shuttle.home> References: <20100711113044.GA4578@shuttle.home> Message-ID: <20100714130027.6110ae21@workstation> Merged and pushed, thanks! Thomas Adam wrote: > When a download in Vimprobable has completed, and > ENABLE_WGET_PROGRESS_BAR is in use, the ascii_bar would still be > displayed, because there was not an additional check for > activeDownload not being NULL. This fixes that condition. > --- > main.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/main.c b/main.c > index 34fdb1e..56e09cf 100644 > --- a/main.c > +++ b/main.c > @@ -1939,7 +1939,8 @@ update_state() { > } else { > markup = (char*)g_markup_printf_escaped(" font=\"%s\">%.0d%c %s", statusfont, count, current_modkey, > scroll_state); } > - } else if (webkit_web_view_get_load_status(webview) != > WEBKIT_LOAD_FINISHED) { > + } else if ((webkit_web_view_get_load_status(webview) != > WEBKIT_LOAD_FINISHED) && > + (activeDownload != NULL)) { > ascii_bar(progressbartick, (int)(progress * > progressbartick), (char*)progressbar); markup = > (char*)g_markup_printf_escaped("%.0d%c %c%s%c > %s", statusfont, count, current_modkey, progressborderleft, > progressbar, progressborderright, scroll_state); > > 1.6.6.196.g1f735 > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users From thomas at xteddy.org Fri Jul 16 21:36:29 2010 From: thomas at xteddy.org (Thomas Adam) Date: Fri, 16 Jul 2010 22:36:29 +0100 Subject: [Vimprobable-users] [PATCH 1/1] Fix typos in manpages. Message-ID: <20100716213625.GA3131@debian> Correct typos in vimprobable2.1 and vimprobablerc.1 --- I doubt this really needs a special point-release of vimprobable as it's just documentation fixes, but I've had it lying around in my tree for a while now, and need to clear it to make way for other patches. :) vimprobable2.1 | 4 ++-- vimprobablerc.1 | 12 ++++++------ 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/vimprobable2.1 b/vimprobable2.1 index d3dffef..27de8a6 100644 --- a/vimprobable2.1 +++ b/vimprobable2.1 @@ -35,7 +35,7 @@ Scroll up Close current window .SH KEYBOARD BINDINGS -The default keyboard bindings are explaned in this sections. These keybindings +The default keyboard bindings are explained in this sections. These keybindings can be changed. .IP "Move through current page" @@ -225,7 +225,7 @@ file is required if you want to use cookies. .SH BUGS -There has not been any significant bughunting yet. +There has not been any significant bug-hunting yet. .SH AUTHORS Hannes Schueller and Matto Fransen .SH "SEE ALSO" diff --git a/vimprobablerc.1 b/vimprobablerc.1 index 85a9691..1ecd0cd 100644 --- a/vimprobablerc.1 +++ b/vimprobablerc.1 @@ -63,16 +63,16 @@ Set the URL of the homepage. Replace the default useragent-string. .IP scripts=[true|false] -Enable or disenable scripts. +Enable or disable scripts. .IP plugins=[true|false] -Enable or disenable plugins. +Enable or disable plugins. .IP images=[true|false] -Enable or disenable autoload of images. +Enable or disable autoload of images. .IP shrinkimages=[true|false] -Enable or disenable autoshrink of images. +Enable or disable autoshrink of images. .IP cursivefont=cursivefont-family Replace the default cursive font family @@ -90,7 +90,7 @@ Replace the default fontsize Replace the default monospace fontsize .IP caret=[true|false] -Enable or disenable caret browsing +Enable or disable caret browsing .IP fantasyfont=fantasy-font-family Replace the default fantasy font family @@ -165,7 +165,7 @@ All settings can be changed on the fly by entering above. .SH BUGS -There has not been any significant bughunting yet. +There has not been any significant bug-hunting yet. .SH AUTHORS Hannes Schueller and Matto Fransen .SH "SEE ALSO" 1.7.1 From hannes at yllr.net Sun Jul 18 10:18:59 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sun, 18 Jul 2010 12:18:59 +0200 Subject: [Vimprobable-users] Proper SSL support Message-ID: <20100718121859.02316865@workstation> Hello everyone, as you know, Vimprobable currently accepts and uses any SSL certificate presented to it. This makes it vulnerable to man-in-the-middle attacks. This is a problem it shares with basically any browser built on top of Webkit-GTK/libsoup. Accepting any certificate is the default setting of libsoup. libsoup's only option is to attach a CA bundle to the HTTP session and have all certificates checked against it. While it wouldn't be hard to code, the obvious problem there is that any SSL connection will be denied if the certificate can't be validated using this bundle. In practice, this means that nobody will ever be able to connect to a website using a self-signed certificate, for example. There is no API in libsoup to prompt the user with the problem and let him decide on a case-to-case basis. So I don't really believe simply setting a CA bundle, even if configurable by the user, is really an option. Another option would be to verify certificates ourselves before telling libsoup to actually do the actual SSL handshake. I.e. keep verification in libsoup turned off (as it is right now), but use some other means to retrieve the certificate and check it beforehand. One user suggested SSH style verification, i.e. prompting the user on new fingerprints and then, if a fingerprint has been accepted once, denying connection if a fingerprint has changed. Personally, I like this, because I don't really trust the whole CA system anyway and it's also much simpler. Problem is, whether we go with SSH style or CA style verification, we'll need some way of getting a server's certificate. Midori, for example, actually includes the OpenSSL library just for that. That's overkill for sure (not to mention that the OpenSSL API sucks very, very badly)! I'd like to hear some opinions concerning this issue. Do we simply wait for the libsoup developers to get their act together and provide an interactive client API? This could take years, feature requests / bug reports along those lines have been open for a long time there already. Doesn't seem to be a priority with them. Or do we find a workaround? If so, what are you proposing? Is there a 'lightweight' way to retrieve a certificate and examine its fingerprint? Hannes From hpdeifel at gmx.de Sun Jul 18 12:29:37 2010 From: hpdeifel at gmx.de (Hans-Peter Deifel) Date: Sun, 18 Jul 2010 14:29:37 +0200 Subject: [Vimprobable-users] [PATCH] Allow hints activation while the page is loading. Message-ID: <1279456177-18652-1-git-send-email-hpdeifel@gmx.de> Split the javascript code into two parts: One is loaded before the page and the other after it. --- Makefile | 6 +- hinting.js | 190 +++++++++++++++++++++++++++++++++++++++++++ input-focus.js | 29 +++++++ input_hinting_mode.js | 212 ------------------------------------------------- js-merge-helper.pl | 38 ++++++--- main.c | 6 +- 6 files changed, 251 insertions(+), 230 deletions(-) create mode 100644 hinting.js create mode 100644 input-focus.js delete mode 100644 input_hinting_mode.js diff --git a/Makefile b/Makefile index 2c3a814..f59fa28 100644 --- a/Makefile +++ b/Makefile @@ -7,7 +7,7 @@ MAN = vimprobable2.1 vimprobablerc.1 # Used libraries to get needed CFLAGS and LDFLAGS form pkg-config LIBS = gtk+-2.0 webkit-1.0 libsoup-2.4 # Files to removo by clean target -CLEAN = $(TARGET) $(OBJ) $(DEPS) hintingmode.h +CLEAN = $(TARGET) $(OBJ) $(DEPS) javascript.h # Files to install by install target or remove by uninstall target INSTALL = $(BINDIR)/$(TARGET) $(addprefix $(MANDIR)/man1/,$(MAN)) @@ -33,8 +33,8 @@ all: $(TARGET) -include $(DEPS) -main.o: hintingmode.h -hintingmode.h: input_hinting_mode.js +main.o: javascript.h +javascript.h: input-focus.js hinting.js perl ./js-merge-helper.pl $(TARGET): $(OBJ) diff --git a/hinting.js b/hinting.js new file mode 100644 index 0000000..c59237a --- /dev/null +++ b/hinting.js @@ -0,0 +1,190 @@ +/* + (c) 2009 by Leon Winter + (c) 2009 by Hannes Schueller + see LICENSE file +*/ + +function clearfocus() { + if(document.activeElement && document.activeElement.blur) + document.activeElement.blur(); +} + +function show_hints(inputText) { + if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { + var height = window.innerHeight; + var width = window.innerWidth; + var scrollX = document.defaultView.scrollX; + var scrollY = document.defaultView.scrollY; + /* prefixing html: will result in namespace error */ + var hinttags; + if (typeof(inputText) == "undefined" || inputText == "") { + hinttags = "//*[@onclick or @onmouseover or @onmousedown or @onmouseup or @oncommand or @class='lk' or @role='link' or @href] | //input[not(@type='hidden')] | //a | //area | //iframe | //textarea | //button | //select"; + } else { + /* only elements which match the text entered so far */ + hinttags = "//*[(@onclick or @onmouseover or @onmousedown or @onmouseup or @oncommand or @class='lk' or @role='link' or @href) and contains(., '" + inputText + "')] | //input[not(@type='hidden') and contains(., '" + inputText + "')] | //a[contains(., '" + inputText + "')] | //area[contains(., '" + inputText + "')] | //iframe[contains(@name, '" + inputText + "')] | //textarea[contains(., '" + inputText + "')] | //button[contains(@value, '" + inputText + "')] | //select[contains(., '" + inputText + "')]"; + } + + /* iterator type isn't suitable here, because: "DOMException NVALID_STATE_ERR: The document has been mutated since the result was returned." */ + var r = document.evaluate(hinttags, document, + function(p) { + return 'http://www.w3.org/1999/xhtml'; + }, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null); + div = document.createElement("div"); + /* due to the different XPath result type, we will need two counter variables */ + j = 0; + var i; + a = []; + colors = []; + backgrounds = []; + for (i = 0; i < r.snapshotLength; i++) + { + var elem = r.snapshotItem(i); + rect = elem.getBoundingClientRect(); + if (!rect || rect.top > height || rect.bottom < 0 || rect.left > width || rect.right < 0 || !(elem.getClientRects()[0])) + continue; + var computedStyle = document.defaultView.getComputedStyle(elem, null); + if (computedStyle.getPropertyValue("visibility") != "visible" || computedStyle.getPropertyValue("display") == "none") + continue; + var leftpos = Math.max((rect.left + scrollX), scrollX); + var toppos = Math.max((rect.top + scrollY), scrollY); + a.push(elem); + /* making this block DOM compliant */ + var hint = document.createElement("span"); + hint.setAttribute("class", "hinting_mode_hint"); + hint.setAttribute("id", "vimprobablehint" + j); + hint.style.position = "absolute"; + hint.style.left = leftpos + "px"; + hint.style.top = toppos + "px"; + hint.style.background = "red"; + hint.style.color = "#fff"; + hint.style.font = "bold 10px monospace"; + hint.style.zIndex = "99"; + var text = document.createTextNode(j); + hint.appendChild(text); + div.appendChild(hint); + /* remember site-defined colour of this element */ + colors[j] = elem.style.color; + backgrounds[j] = elem.style.background; + /* make the link black to ensure it's readable */ + elem.style.color = "#000"; + elem.style.background = "#ff0"; + j++; + } + i = 0; + while (typeof(a[i]) != "undefined") { + a[i].className += " hinting_mode_hint"; + i++; + } + document.getElementsByTagName("body")[0].appendChild(div); + clearfocus(); + h = null; + if (i == 1) { + /* just one hinted element - might as well follow it */ + return fire(1); + } + } +} +function fire(n) +{ + if (typeof(a[n - 1]) != "undefined") { + el = a[n - 1]; + tag = el.nodeName.toLowerCase(); + clear(); + if(tag == "iframe" || tag == "frame" || tag == "textarea" || tag == "input" && (el.type == "text" || el.type == "password" || el.type == "checkbox" || el.type == "radio")) { + el.focus(); + if (tag == "textarea" || tag == "input") + console.log('insertmode_on'); + } else { + if (el.onclick) { + var evObj = document.createEvent('MouseEvents'); + evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); + el.dispatchEvent(evObj); + } else if (el.href) { + if (el.href.match(/^javascript:/)) { + var evObj = document.createEvent('MouseEvents'); + evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); + el.dispatchEvent(evObj); + } else { + /* send signal to open link */ + return "open;" + el.href; + } + } else { + var evObj = document.createEvent('MouseEvents'); + evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); + el.dispatchEvent(evObj); + } + } + } +} +function cleanup() +{ + for(e in a) { + if (typeof(a[e].className) != "undefined") { + a[e].className = a[e].className.replace(/hinting_mode_hint/,''); + /* reset to site-defined colour */ + a[e].style.color = colors[e]; + a[e].style.background = backgrounds[e]; + } + } + div.parentNode.removeChild(div); + window.onkeyup = null; +} +function clear() +{ + cleanup(); + console.log("hintmode_off") +} + +function update_hints(n) +{ + if(h != null) + h.className = h.className.replace("_focus",""); + if (j - 1 < n * 10 && typeof(a[n - 1]) != "undefined") { + /* return signal to follow the link */ + return "fire;" + n; + } else + if (typeof(a[n - 1]) != "undefined") { + (h = a[n - 1]).className = a[n - 1].className.replace("hinting_mode_hint", "hinting_mode_hint_focus"); + h.style.background = "8f0"; + } +} + +function focus_input() +{ + if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { + /* prefixing html: will result in namespace error */ + var hinttags = "//input[@type='text'] | //input[@type='password'] | //textarea"; + var r = document.evaluate(hinttags, document, + function(p) { + return 'http://www.w3.org/1999/xhtml'; + }, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null); + var i; + var j = 0; + var first = null; + for (i = 0; i < r.snapshotLength; i++) { + var elem = r.snapshotItem(i); + if (i == 0) { + first = elem; + } + if (j == 1) { + elem.focus(); + var tag = elem.nodeName.toLowerCase(); + if (tag == "textarea" || tag == "input") + console.log('insertmode_on'); + break; + } else { + if (elem == document.activeElement) + j = 1; + } + } + if (j == 0) { + /* no appropriate field found focused - focus the first one */ + if (first !== null) { + first.focus(); + var tag = elem.nodeName.toLowerCase(); + if (tag == "textarea" || tag == "input") + console.log('insertmode_on'); + } + } + } +} diff --git a/input-focus.js b/input-focus.js new file mode 100644 index 0000000..0ef8817 --- /dev/null +++ b/input-focus.js @@ -0,0 +1,29 @@ +/* + (c) 2009 by Leon Winter + (c) 2009 by Hannes Schueller + see LICENSE file +*/ + +function v(e, y) { + t = e.nodeName.toLowerCase(); + if((t == 'input' && /^(text|password|checkbox|radio)$/.test(e.type)) + || /^(select|textarea)$/.test(t) + || e.contentEditable == 'true') + console.log('insertmode_'+(y=='focus'?'on':'off')); +} + +if(document.activeElement) + v(document.activeElement,'focus'); + +m=['focus','blur']; + +if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { + for(i in m) + document.getElementsByTagName('body')[0].addEventListener(m[i], function(x) { + v(x.target,x.type); + }, true); +} + +self.onunload = function() { + v(document.activeElement, ''); +}; diff --git a/input_hinting_mode.js b/input_hinting_mode.js deleted file mode 100644 index 6118cd4..0000000 --- a/input_hinting_mode.js +++ /dev/null @@ -1,212 +0,0 @@ -/* - (c) 2009 by Leon Winter - (c) 2009 by Hannes Schueller - see LICENSE file -*/ - -function clearfocus() { - if(document.activeElement && document.activeElement.blur) - document.activeElement.blur(); -} - -function v(e, y) { - t = e.nodeName.toLowerCase(); - if((t == 'input' && /^(text|password|checkbox|radio)$/.test(e.type)) - || /^(select|textarea)$/.test(t) - || e.contentEditable == 'true') - console.log('insertmode_'+(y=='focus'?'on':'off')); -} - -if(document.activeElement) - v(document.activeElement,'focus'); - -m=['focus','blur']; - -if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { - for(i in m) - document.getElementsByTagName('body')[0].addEventListener(m[i], function(x) { - v(x.target,x.type); - }, true); - - document.getElementsByTagName("body")[0].appendChild(document.createElement("style")); - document.styleSheets[0].addRule('.hinting_mode_hint', 'color: #000; background: #ff0;'); - document.styleSheets[0].addRule('.hinting_mode_hint_focus', 'color: #000; background: #8f0;'); -} - -self.onunload = function() { - v(document.activeElement, ''); -}; - -function show_hints(inputText) { - if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { - var height = window.innerHeight; - var width = window.innerWidth; - var scrollX = document.defaultView.scrollX; - var scrollY = document.defaultView.scrollY; - /* prefixing html: will result in namespace error */ - var hinttags; - if (typeof(inputText) == "undefined" || inputText == "") { - hinttags = "//*[@onclick or @onmouseover or @onmousedown or @onmouseup or @oncommand or @class='lk' or @role='link' or @href] | //input[not(@type='hidden')] | //a | //area | //iframe | //textarea | //button | //select"; - } else { - /* only elements which match the text entered so far */ - hinttags = "//*[(@onclick or @onmouseover or @onmousedown or @onmouseup or @oncommand or @class='lk' or @role='link' or @href) and contains(., '" + inputText + "')] | //input[not(@type='hidden') and contains(., '" + inputText + "')] | //a[contains(., '" + inputText + "')] | //area[contains(., '" + inputText + "')] | //iframe[contains(@name, '" + inputText + "')] | //textarea[contains(., '" + inputText + "')] | //button[contains(@value, '" + inputText + "')] | //select[contains(., '" + inputText + "')]"; - } - - /* iterator type isn't suitable here, because: "DOMException NVALID_STATE_ERR: The document has been mutated since the result was returned." */ - var r = document.evaluate(hinttags, document, - function(p) { - return 'http://www.w3.org/1999/xhtml'; - }, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null); - div = document.createElement("div"); - /* due to the different XPath result type, we will need two counter variables */ - j = 1; - var i; - a = []; - colors = []; - for (i = 0; i < r.snapshotLength; i++) - { - var elem = r.snapshotItem(i); - rect = elem.getBoundingClientRect(); - if (!rect || rect.top > height || rect.bottom < 0 || rect.left > width || rect.right < 0 || !(elem.getClientRects()[0])) - continue; - var computedStyle = document.defaultView.getComputedStyle(elem, null); - if (computedStyle.getPropertyValue("visibility") != "visible" || computedStyle.getPropertyValue("display") == "none") - continue; - var leftpos = Math.max((rect.left + scrollX), scrollX); - var toppos = Math.max((rect.top + scrollY), scrollY); - a.push(elem); - /* making this block DOM compliant */ - var hint = document.createElement("span"); - hint.setAttribute("class", "hinting_mode_hint"); - hint.setAttribute("id", "vimprobablehint" + j); - hint.style.position = "absolute"; - hint.style.left = leftpos + "px"; - hint.style.top = toppos + "px"; - hint.style.background = "red"; - hint.style.color = "#fff"; - hint.style.font = "bold 10px monospace"; - hint.style.zIndex = "99"; - var text = document.createTextNode(j); - hint.appendChild(text); - div.appendChild(hint); - /* remember site-defined colour of this element */ - colors[j] = elem.style.color; - /* make the link black to ensure it's readable */ - elem.style.color = "#000"; - j++; - } - i = 0; - while (typeof(a[i]) != "undefined") { - a[i].className += " hinting_mode_hint"; - i++; - } - document.getElementsByTagName("body")[0].appendChild(div); - clearfocus(); - h = null; - if (i == 1) { - /* just one hinted element - might as well follow it */ - return fire(1); - } - } -} -function fire(n) -{ - if (typeof(a[n - 1]) != "undefined") { - el = a[n - 1]; - tag = el.nodeName.toLowerCase(); - clear(); - if(tag == "iframe" || tag == "frame" || tag == "textarea" || tag == "input" && (el.type == "text" || el.type == "password" || el.type == "checkbox" || el.type == "radio")) { - el.focus(); - if (tag == "textarea" || tag == "input") - console.log('insertmode_on'); - } else { - if (el.onclick) { - var evObj = document.createEvent('MouseEvents'); - evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); - el.dispatchEvent(evObj); - } else if (el.href) { - if (el.href.match(/^javascript:/)) { - var evObj = document.createEvent('MouseEvents'); - evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); - el.dispatchEvent(evObj); - } else { - /* send signal to open link */ - return "open;" + el.href; - } - } else { - var evObj = document.createEvent('MouseEvents'); - evObj.initMouseEvent('click', true, true, window, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, null); - el.dispatchEvent(evObj); - } - } - } -} -function cleanup() -{ - for(e in a) { - if (typeof(a[e].className) != "undefined") { - a[e].className = a[e].className.replace(/hinting_mode_hint/,''); - /* reset to site-defined colour */ - a[e].style.color = colors[e]; - } - } - div.parentNode.removeChild(div); - window.onkeyup = null; -} -function clear() -{ - cleanup(); - console.log("hintmode_off") -} - -function update_hints(n) -{ - if(h != null) - h.className = h.className.replace("_focus",""); - if (j - 1 < n * 10 && typeof(a[n - 1]) != "undefined") { - /* return signal to follow the link */ - return "fire;" + n; - } else - if (typeof(a[n - 1]) != "undefined") - (h = a[n - 1]).className = a[n - 1].className.replace("hinting_mode_hint", "hinting_mode_hint_focus"); -} - -function focus_input() -{ - if (document.getElementsByTagName("body")[0] !== null && typeof(document.getElementsByTagName("body")[0]) == "object") { - /* prefixing html: will result in namespace error */ - var hinttags = "//input[@type='text'] | //input[@type='password'] | //textarea"; - var r = document.evaluate(hinttags, document, - function(p) { - return 'http://www.w3.org/1999/xhtml'; - }, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null); - var i; - var j = 0; - var first = null; - for (i = 0; i < r.snapshotLength; i++) { - var elem = r.snapshotItem(i); - if (i == 0) { - first = elem; - } - if (j == 1) { - elem.focus(); - var tag = elem.nodeName.toLowerCase(); - if (tag == "textarea" || tag == "input") - console.log('insertmode_on'); - break; - } else { - if (elem == document.activeElement) - j = 1; - } - } - if (j == 0) { - /* no appropriate field found focused - focus the first one */ - if (first !== null) { - first.focus(); - var tag = elem.nodeName.toLowerCase(); - if (tag == "textarea" || tag == "input") - console.log('insertmode_on'); - } - } - } -} diff --git a/js-merge-helper.pl b/js-merge-helper.pl index 7ea5663..050d871 100644 --- a/js-merge-helper.pl +++ b/js-merge-helper.pl @@ -1,21 +1,33 @@ #!/bin/env perl -w use strict; -my $js; -open(JSFILE, "input_hinting_mode.js") or die "Failed to open file: $!"; +sub escape_c_string { + shift; + s/\t|\r|\n/ /g; # convert spacings to whitespaces + s/[^\/]\/\*.*?\*\///g; # remove comments (careful: hinttags look like comment!) + s/ {2,}/ /g; # strip whitespaces + s/(^|\(|\)|;|,|:|\}|\{|=|\+|\-|\*|\&|\||\<|\>|!) +/$1/g; + s/ +($|\(|\)|;|,|:|\}|\{|=|\+|\-|\*|\&|\||\<|\>|!)/$1/g; + s/\\/\\\\/g; # escape backslashes + s/\"/\\\"/g; # escape quotes + return $_ +} + +open(JSFILE, "hinting.js") or die "Failed to open file: $!"; $_ = do { local $/; }; close(JSFILE); -s/\t|\r|\n/ /g; # convert spacings to whitespaces -s/[^\/]\/\*.*?\*\///g; # remove comments (careful: hinttags look like comment!) -s/ {2,}/ /g; # strip whitespaces -s/(^|\(|\)|;|,|:|\}|\{|=|\+|\-|\*|\&|\||\<|\>|!) +/$1/g; -s/ +($|\(|\)|;|,|:|\}|\{|=|\+|\-|\*|\&|\||\<|\>|!)/$1/g; -s/\\/\\\\/g; # escape backslashes -s/\"/\\\"/g; # escape quotes -$js = $_; +my $js_hints = escape_c_string($_); -open(HFILE, ">hintingmode.h") or die "Failed to open hintingmode.h: $!"; -print HFILE "#define JS_SETUP "; -printf HFILE "\"%s\"\n", $js; +open(JSFILE, "input-focus.js") or die "Failed to open file: $!"; +$_ = do { local $/; }; +close(JSFILE); +my $js_input = escape_c_string($_); + +open(HFILE, ">javascript.h") or die "Failed to open javascript.h: $!"; +print HFILE "#define JS_SETUP_HINTS "; +printf HFILE "\"%s\"\n", $js_hints; +print HFILE "#define JS_SETUP_INPUT_FOCUS "; +printf HFILE "\"%s\"\n", $js_input; close(HFILE); + exit; diff --git a/main.c b/main.c index 53931e6..a3cf8d5 100644 --- a/main.c +++ b/main.c @@ -9,7 +9,7 @@ #include "vimprobable.h" #include "utilities.h" #include "callbacks.h" -#include "hintingmode.h" +#include "javascript.h" /* remove numlock symbol from keymask */ #define CLEAN(mask) (mask & ~(GDK_MOD2_MASK) & ~(GDK_BUTTON1_MASK) & ~(GDK_BUTTON2_MASK) & ~(GDK_BUTTON3_MASK) & ~(GDK_BUTTON4_MASK) & ~(GDK_BUTTON5_MASK)) @@ -171,14 +171,16 @@ ascii_bar(int total, int state, char *string) { void webview_load_committed_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { + Arg a = { .i = Silent, .s = JS_SETUP_HINTS }; const char *uri = webkit_web_view_get_uri(webview); update_url(uri); + script(&a); } void webview_load_finished_cb(WebKitWebView *webview, WebKitWebFrame *frame, gpointer user_data) { - Arg a = { .i = Silent, .s = JS_SETUP }; + Arg a = { .i = Silent, .s = JS_SETUP_INPUT_FOCUS }; if (HISTORY_MAX_ENTRIES > 0) history(); -- 1.7.1 From hannes at yllr.net Sun Jul 18 18:11:02 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sun, 18 Jul 2010 20:11:02 +0200 Subject: [Vimprobable-users] [PATCH 1/1] Fix typos in manpages. In-Reply-To: <20100716213625.GA3131@debian> References: <20100716213625.GA3131@debian> Message-ID: <20100718181102.GC1920@laptop2.lan.localhost> On Fri, Jul 16, 2010 at 10:36:29PM +0100, Thomas Adam wrote: > Correct typos in vimprobable2.1 and vimprobablerc.1 Included into main branch, thanks! Hannes From hannes at yllr.net Sun Jul 18 19:26:45 2010 From: hannes at yllr.net (Hannes =?iso-8859-1?Q?Sch=FCller?=) Date: Sun, 18 Jul 2010 21:26:45 +0200 Subject: [Vimprobable-users] [PATCH] Allow hints activation while the page is loading. Message-ID: <20100718192644.GE1920@laptop2.lan.localhost> Sorry, this was supposed to go to the list, of course. ----- Forwarded message from Hannes Sch?ller ----- Date: Sun, 18 Jul 2010 20:53:14 +0200 From: Hannes Sch?ller To: Hans-Peter Deifel Subject: Re: [Vimprobable-users] [PATCH] Allow hints activation while the page is loading. User-Agent: Mutt/1.5.20 (2009-06-14) On Sun, Jul 18, 2010 at 02:29:37PM +0200, Hans-Peter Deifel wrote: > Split the javascript code into two parts: One is loaded before the page > and the other after it. Merged, but I'll take a couple of additional days till the next release to ensure the function renaming is complete. Hannes ----- End forwarded message ----- From thomas at xteddy.org Mon Jul 19 08:18:29 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 19 Jul 2010 09:18:29 +0100 Subject: [Vimprobable-users] Proper SSL support In-Reply-To: <20100718121859.02316865@workstation> References: <20100718121859.02316865@workstation> Message-ID: <20100719081828.GA5043@abacus.soton.smoothwall.net> On Sun, Jul 18, 2010 at 12:18:59PM +0200, Hannes Sch?ller wrote: > Hello everyone, Hi there. > Another option would be to verify certificates ourselves before telling > libsoup to actually do the actual SSL handshake. I.e. keep verification > in libsoup turned off (as it is right now), but use some other means to > retrieve the certificate and check it beforehand. I've done work with SSL before, and can tell you that OpenSSL in particular blows for this sort of thing because the API sucks, and isn't documented very well. GNUTLS is a much better option here -- validating X509 certificates isn't much a problem here. > One user suggested SSH style verification, i.e. prompting the user on > new fingerprints and then, if a fingerprint has been accepted once, > denying connection if a fingerprint has changed. Personally, I like > this, because I don't really trust the whole CA system anyway and it's > also much simpler. But then this is a smoke-screen against the entire reason why there's a CA cert in the first place. > Problem is, whether we go with SSH style or CA style verification, > we'll need some way of getting a server's certificate. Midori, for > example, actually includes the OpenSSL library just for that. That's > overkill for sure (not to mention that the OpenSSL API sucks very, very > badly)! Depending on GNUTLS is more lightweight, but regardless you'll be upping the dependencies slightly on Vimprobable -- don't let that discourage you though. I would say look at GNUTLS as a prototype -- I can help you here with that if you like. Keep libsoup's default of turning verification off as you have it now, and use GNUTLS to check the CA. We can still track this internally and come up with some modal GTKWindow to wrap this around if need be, it's not too difficult I don't suppose. -- Thomas Adam From stettberger at dokucode.de Mon Jul 19 15:19:08 2010 From: stettberger at dokucode.de (Christian Dietrich) Date: Mon, 19 Jul 2010 17:19:08 +0200 Subject: [Vimprobable-users] [PATCH] bugfix: remove off-by-one in descend Message-ID: <868w57lcsz.fsf@peer.zerties.org> There was a off-by one in descend, which crashed vimprobable at http://kvardek-du.kerno.org/2009/06/illustrating-sbcls-build-process.html --- main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 53931e6..8d46eea 100644 --- a/main.c +++ b/main.c @@ -936,7 +936,7 @@ descend(const Arg *arg) { the char before the slash, so +1 */ } len = p - source + 1; /* new length = end - start + 1 */ - new = malloc(len); + new = malloc(len + 1); memcpy(new, source, len); new[len] = '\0'; webkit_web_view_load_uri(webview, new); -- 1.7.1 -- Please From stettberger at dokucode.de Mon Jul 19 15:31:34 2010 From: stettberger at dokucode.de (Christian Dietrich) Date: Mon, 19 Jul 2010 17:31:34 +0200 Subject: [Vimprobable-users] [PATCH] bugfix: remove off by one in checking the history size Message-ID: <864ofvlc89.fsf@peer.zerties.org> It may not be important to have 1000 history entries instead of 1001, but we should respect the users configuration choices. --- main.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/main.c b/main.c index 8d46eea..23107a7 100644 --- a/main.c +++ b/main.c @@ -1474,7 +1474,7 @@ history() { strncat(new, buffer, 512); i++; } - if (i >= HISTORY_MAX_ENTRIES) { + if ((i + 1) >= HISTORY_MAX_ENTRIES) { break; } } -- 1.7.1 -- Sorry for the last broken mail, but i used C-c C-c instead of saying: please cc me, i'm not on the list From hannes at yllr.net Sat Jul 24 15:53:48 2010 From: hannes at yllr.net (Hannes =?UTF-8?B?U2Now7xsbGVy?=) Date: Sat, 24 Jul 2010 17:53:48 +0200 Subject: [Vimprobable-users] Proper SSL support In-Reply-To: <20100719081828.GA5043@abacus.soton.smoothwall.net> References: <20100718121859.02316865@workstation> <20100719081828.GA5043@abacus.soton.smoothwall.net> Message-ID: <20100724175348.13eaa92a@workstation> Thomas Adam wrote: > > One user suggested SSH style verification, i.e. prompting the user > > on new fingerprints and then, if a fingerprint has been accepted > > once, denying connection if a fingerprint has changed. Personally, > > I like this, because I don't really trust the whole CA system > > anyway and it's also much simpler. > > But then this is a smoke-screen against the entire reason why there's > a CA cert in the first place. In my opinion, there is little point in having CA certs anyway, because why would I trust those? What are they 'guaranteeing' me anyway? Right, effectively nothing. Though the discussion seems a bit futile, SSL doesn't seem to be a to a feature anyone on this list wants at all. At least I don't see anyone speaking up and saying so. Which is rather sad. Hannes From eiwe at reliantsecurity.com Sat Jul 24 16:14:01 2010 From: eiwe at reliantsecurity.com (Eiwe Lingefors) Date: Sat, 24 Jul 2010 12:14:01 -0400 (EDT) Subject: [Vimprobable-users] Proper SSL support In-Reply-To: <20100724175348.13eaa92a@workstation> References: <20100718121859.02316865@workstation> <20100719081828.GA5043@abacus.soton.smoothwall.net> <20100724175348.13eaa92a@workstation> Message-ID: On Sat, 24 Jul 2010, Hannes Sch?ller wrote: > Though the discussion seems a bit futile, SSL doesn't seem to be a to a > feature anyone on this list wants at all. At least I don't see anyone > speaking up and saying so. Which is rather sad. I have to chime in and say that SSL is definitely something I want. However, I have very little to add in the way of coding skill to contribute anything tangible. Every browser no matter how small should have SSL support. Say what you will about the credibibility of CAs, there's still value in having your browser session encrypted. Thanks, Eiwe -- Eiwe Lingefors Chief Security Architect From skottish97215 at gmail.com Sun Jul 25 00:03:15 2010 From: skottish97215 at gmail.com (Skottish) Date: Sat, 24 Jul 2010 17:03:15 -0700 Subject: [Vimprobable-users] Proper SSL support In-Reply-To: References: <20100718121859.02316865@workstation> <20100719081828.GA5043@abacus.soton.smoothwall.net> <20100724175348.13eaa92a@workstation> Message-ID: I agree that SSL is important. And, CA theoretically goes through the same scrutiny that anything else that's open does, so there seems to be some basis for trust. As always though, I don't have any practical C skills, so I don't say much. On Sat, Jul 24, 2010 at 9:14 AM, Eiwe Lingefors wrote: > On Sat, 24 Jul 2010, Hannes Sch?ller wrote: > > Though the discussion seems a bit futile, SSL doesn't seem to be a to a >> feature anyone on this list wants at all. At least I don't see anyone >> speaking up and saying so. Which is rather sad. >> > > I have to chime in and say that SSL is definitely something I want. > However, I have very little to add in the way of coding skill to > contribute anything tangible. > > Every browser no matter how small should have SSL support. Say what you > will about the credibibility of CAs, there's still value in having your > browser session encrypted. > > Thanks, > Eiwe > > -- > Eiwe Lingefors > Chief Security Architect > _______________________________________________ > Vimprobable-users mailing list > Vimprobable-users at vimprobable.org > http://vimprobable.org/mailman/listinfo/vimprobable-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at xteddy.org Mon Jul 26 11:18:23 2010 From: thomas at xteddy.org (Thomas Adam) Date: Mon, 26 Jul 2010 12:18:23 +0100 Subject: [Vimprobable-users] Proper SSL support In-Reply-To: <20100724175348.13eaa92a@workstation> References: <20100718121859.02316865@workstation> <20100719081828.GA5043@abacus.soton.smoothwall.net> <20100724175348.13eaa92a@workstation> Message-ID: <20100726111820.GD2960@abacus.soton.smoothwall.net> On Sat, Jul 24, 2010 at 05:53:48PM +0200, Hannes Sch?ller wrote: > Thomas Adam wrote: > > > One user suggested SSH style verification, i.e. prompting the user > > > on new fingerprints and then, if a fingerprint has been accepted > > > once, denying connection if a fingerprint has changed. Personally, > > > I like this, because I don't really trust the whole CA system > > > anyway and it's also much simpler. > > > > But then this is a smoke-screen against the entire reason why there's > > a CA cert in the first place. > > In my opinion, there is little point in having CA certs anyway, because > why would I trust those? What are they 'guaranteeing' me anyway? Right, > effectively nothing. It's the same with any authentication protocol -- Kerberos is much the same in this regard, and moot; you have to put your trust *inherently* in a third-party to handle your authentication. It's the same thing here with CAs, either self-signed or verified by another company. But it's not so much the social aspect of this which should go against *not* doing this, it ought to be a technical one: thankfully, that's solvable by writing code. :) > Though the discussion seems a bit futile, SSL doesn't seem to be a to a > feature anyone on this list wants at all. At least I don't see anyone > speaking up and saying so. Which is rather sad. That's not always how things work -- if we thought like that about things, nobody would do anything. Being pragmatic about something, regardless of whether someone will use it is often better. There is also the more wider-consideration here that a user's expectation nowadays is that SSL should Just Work transparently to them. I am inclined to agree with this, given the trend of how sites on the Internet are going; and if we just wait, people are going to get bitten by all sorts of nasties. Be pragmatic. :) I'm in the thick of other Vimprobable stuff at the moment anyway, so if there's no movement on this when I am done, I'll start on this with you. :) -- Thomas Adam