Thread: [Vimprobable-users] Vimprobable2 on Debian Testing
Vimprobable is a lean web browser optimised for full keyboard control
Brought to you by:
hanness
Menu
▾
▴
vimprobable-users
|
From: Thorsten K. <tho...@gm...> - 2014-02-07 21:35:25
|
Hello, I hope that's the right place for my question... I'm using Vimprobable2 (git) on Debian Testing (ratpoison wm). I've been using it on Arch Linux before without any problems. But since I migrated to Debian, Vimprobable won't follow links in an new Tab (:tabopen still working fine). BTW, I didn't change the config, all dependencies (libsoup, libwebkit, libgtk) are installed. Any help (hint) will be appreciated, since I like using that browser very much. Thanks in advance! |
|
From: Hannes S. <ha...@yl...> - 2014-02-08 12:31:08
|
Hi Thorsten! On Fri, 7 Feb 2014 22:35:13 +0100, Thorsten Köhne <tho...@gm...> wrote: > I hope that's the right place for my question... It certainly is! > I'm using Vimprobable2 (git) on Debian Testing (ratpoison wm). I've > been using it on Arch Linux before without any problems. But since I > migrated to Debian, Vimprobable won't follow links in an new Tab > (:tabopen still working fine). So what you're saying is F or , don't work for you? What happens when you activate them? Are the links hinted at all? Can you activate them by entering the appropriate number or string? What happens after trying to fire the link? Any output on the terminal? Hannes |
|
From: Thorsten K. <tho...@gm...> - 2014-02-08 17:17:24
|
On Sat, Feb 08, 2014 at 01:00:37PM +0100, Hannes Schüller wrote: > Hi Thorsten! > Hi Hannes! > On Fri, 7 Feb 2014 22:35:13 +0100, Thorsten Köhne > <tho...@gm...> wrote: > > I hope that's the right place for my question... > > It certainly is! > > > I'm using Vimprobable2 (git) on Debian Testing (ratpoison wm). I've > > been using it on Arch Linux before without any problems. But since I > > migrated to Debian, Vimprobable won't follow links in an new Tab > > (:tabopen still working fine). > > So what you're saying is F or , don't work for you? What happens when > you activate them? Are the links hinted at all? Can you activate them > by entering the appropriate number or string? What happens after trying > to fire the link? Any output on the terminal? > Well, after pressing F all links are highlighted and until hitting Return everything runs as expected. But after that, nothing (visible, at least for me) happens. And no output on the terminal. Ahh, I guess I forgot one certainly important information: Opening a link in a new tab by mouse is working.... > Hannes > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users |
|
From: Serge E. H. <se...@ha...> - 2014-02-08 17:29:10
|
Quoting Hannes Schüller (ha...@yl...): > Hi Thorsten! > > On Fri, 7 Feb 2014 22:35:13 +0100, Thorsten Köhne > <tho...@gm...> wrote: > > I hope that's the right place for my question... > > It certainly is! > > > I'm using Vimprobable2 (git) on Debian Testing (ratpoison wm). I've > > been using it on Arch Linux before without any problems. But since I > > migrated to Debian, Vimprobable won't follow links in an new Tab > > (:tabopen still working fine). > > So what you're saying is F or , don't work for you? What happens when > you activate them? Are the links hinted at all? Can you activate them > by entering the appropriate number or string? What happens after trying > to fire the link? Any output on the terminal? Come to think of it, same thing for me. 1. F does make the hints show up, then hitting 2 (for instance) just does nothing 2. right-clicking and choosing 'open in new window' does work. 3. nothing shows up in terminal if I started vimprobable there. (Source for mine is at https://launchpad.net/~serge-hallyn/+archive/vimprobable/+sourcepub/3761573/+listing-archive-extra ) Most of the time I'm just following ixquick links, which start in a new window anyway, with 'f', which is why I occasionally get annoyed but not enough to look into it yet :) thanks, -serge |
|
From: Hannes S. <ha...@yl...> - 2014-02-08 17:39:30
|
On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> wrote: > Most of the time I'm just following ixquick links, which start in a > new window anyway, with 'f', which is why I occasionally get annoyed > but not enough to look into it yet :) This is really strange. 'F' works fine for me on Ixquick and I can't reproduce the behaviour of 'f' opening links in a new window either - with or without Javascript. Thorsten, can you confirm Serge's issues with 'f' as well? Hannes |
|
From: Thorsten K. <tho...@gm...> - 2014-02-08 17:45:56
|
On Sat, Feb 08, 2014 at 06:39:36PM +0100, Hannes Schüller wrote: > On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> > wrote: > > Most of the time I'm just following ixquick links, which start in a > > new window anyway, with 'f', which is why I occasionally get annoyed > > but not enough to look into it yet :) > > This is really strange. 'F' works fine for me on Ixquick and I can't > reproduce the behaviour of 'f' opening links in a new window either - > with or without Javascript. Thorsten, can you confirm Serge's issues > with 'f' as well? Sorry, I can't. 'f' opens the link in the existing window... > > Hannes > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users |
|
From: Serge E. H. <se...@ha...> - 2014-02-10 15:19:51
|
Quoting Hannes Schüller (ha...@yl...): > On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> > wrote: > > Most of the time I'm just following ixquick links, which start in a > > new window anyway, with 'f', which is why I occasionally get annoyed > > but not enough to look into it yet :) > > This is really strange. 'F' works fine for me on Ixquick and I can't > reproduce the behaviour of 'f' opening links in a new window either - Sorry, I didn't mean to imply that 'f' opening results in a new window is a bug. I have that as a setting :) I was just saying that because I have that by default the 'F' not working hasn't really bothered me enough to report it. > with or without Javascript. Thorsten, can you confirm Serge's issues > with 'f' as well? > > Hannes > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Vimprobable-users mailing list > Vim...@li... > https://lists.sourceforge.net/lists/listinfo/vimprobable-users |
|
From: Thorsten K. <tho...@gm...> - 2014-02-10 19:29:42
|
On Mon, Feb 10, 2014 at 04:19:43PM +0100, Serge E. Hallyn wrote: > Quoting Hannes Schüller (ha...@yl...): > > On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> > > wrote: > > > Most of the time I'm just following ixquick links, which start in a > > > new window anyway, with 'f', which is why I occasionally get annoyed > > > but not enough to look into it yet :) > > > > This is really strange. 'F' works fine for me on Ixquick and I can't > > reproduce the behaviour of 'f' opening links in a new window either - > > Sorry, I didn't mean to imply that 'f' opening results in a new window > is a bug. I have that as a setting :) I was just saying that because > I have that by default the 'F' not working hasn't really bothered me > enough to report it. > Just tried your build. Still got the same problem, even with vimb (vimprobable-fork). |
|
From: Serge E. H. <se...@ha...> - 2014-02-10 19:36:58
|
Quoting Thorsten Köhne (tho...@gm...): > On Mon, Feb 10, 2014 at 04:19:43PM +0100, Serge E. Hallyn wrote: > > Quoting Hannes Schüller (ha...@yl...): > > > On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> > > > wrote: > > > > Most of the time I'm just following ixquick links, which start in a > > > > new window anyway, with 'f', which is why I occasionally get annoyed > > > > but not enough to look into it yet :) > > > > > > This is really strange. 'F' works fine for me on Ixquick and I can't > > > reproduce the behaviour of 'f' opening links in a new window either - > > > > Sorry, I didn't mean to imply that 'f' opening results in a new window > > is a bug. I have that as a setting :) I was just saying that because > > I have that by default the 'F' not working hasn't really bothered me > > enough to report it. > > > > Just tried your build. Still got the same problem, even with vimb > (vimprobable-fork). I'm getting lost - if you mean F still doesn't open a new window, then yes, that was the point of my original email. 'F' is not workign for me, right-clicking and selecting 'Open in a new window' does. -serge |
|
From: Thorsten K. <tho...@gm...> - 2014-02-10 20:13:40
|
On Mon, Feb 10, 2014 at 08:36:50PM +0100, Serge E. Hallyn wrote: > Quoting Thorsten Köhne (tho...@gm...): > > On Mon, Feb 10, 2014 at 04:19:43PM +0100, Serge E. Hallyn wrote: > > > Quoting Hannes Schüller (ha...@yl...): > > > > On Sat, 8 Feb 2014 18:10:23 +0100, "Serge E. Hallyn" <se...@ha...> > > > > wrote: > > > > > Most of the time I'm just following ixquick links, which start in a > > > > > new window anyway, with 'f', which is why I occasionally get annoyed > > > > > but not enough to look into it yet :) > > > > > > > > This is really strange. 'F' works fine for me on Ixquick and I can't > > > > reproduce the behaviour of 'f' opening links in a new window either - > > > > > > Sorry, I didn't mean to imply that 'f' opening results in a new window > > > is a bug. I have that as a setting :) I was just saying that because > > > I have that by default the 'F' not working hasn't really bothered me > > > enough to report it. > > > > > > > Just tried your build. Still got the same problem, even with vimb > > (vimprobable-fork). > > I'm getting lost - if you mean F still doesn't open a new window, > then yes, that was the point of my original email. 'F' is not > workign for me, right-clicking and selecting 'Open in a new window' > does. > > -serge Yep, that's exactly what I mean. f opens the link in the existing window, F still doesn't do anything (visible...) |
|
From: Hannes S. <ha...@yl...> - 2014-02-10 20:17:03
|
Hi, no amount of testing enables me to reproduce this issue. Given that it seems to occur in other browsers built against the same libraries as well, I would assume that it's an issue in one of said libs rather than one of the browser. Though please speak up if anyone reading this can confirm this issue, too! Hannes |
|
From: Serge E. H. <se...@ha...> - 2014-02-10 20:30:39
|
Quoting Hannes Schüller (ha...@yl...): > Hi, > > no amount of testing enables me to reproduce this issue. Given that it > seems to occur in other browsers built against the same libraries as > well, I would assume that it's an issue in one of said libs rather than > one of the browser. Though please speak up if anyone reading this can > confirm this issue, too! Agreed. Thorsten, which version of webkit are you using? I appear to be on libwebkit-dev 2.3.4-1ubuntu2. |
|
From: Thorsten K. <tho...@gm...> - 2014-02-10 20:51:12
|
On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > Quoting Hannes Schüller (ha...@yl...): > > Hi, > > > > no amount of testing enables me to reproduce this issue. Given that it > > seems to occur in other browsers built against the same libraries as > > well, I would assume that it's an issue in one of said libs rather than > > one of the browser. Though please speak up if anyone reading this can > > confirm this issue, too! > > Agreed. Thorsten, which version of webkit are you using? I appear to > be on libwebkit-dev 2.3.4-1ubuntu2. > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). |
|
From: Serge E. H. <se...@ha...> - 2014-02-11 21:45:47
|
Quoting Thorsten Köhne (tho...@gm...): > On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > > Quoting Hannes Schüller (ha...@yl...): > > > Hi, > > > > > > no amount of testing enables me to reproduce this issue. Given that it > > > seems to occur in other browsers built against the same libraries as > > > well, I would assume that it's an issue in one of said libs rather than > > > one of the browser. Though please speak up if anyone reading this can > > > confirm this issue, too! > > > > Agreed. Thorsten, which version of webkit are you using? I appear to > > be on libwebkit-dev 2.3.4-1ubuntu2. > > > > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does > with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). I briefly tried to dig deeper last night, but it appears to come down to a bug in whatever is interpreting the js (or perhaps in the rather magic _clickElement()). -serge |
|
From: Thorsten K. <tho...@gm...> - 2014-02-11 23:07:37
|
On Tue, Feb 11, 2014 at 10:45:39PM +0100, Serge E. Hallyn wrote: > Quoting Thorsten Köhne (tho...@gm...): > > On Mon, Feb 10, 2014 at 09:30:32PM +0100, Serge E. Hallyn wrote: > > > Quoting Hannes Schüller (ha...@yl...): > > > > Hi, > > > > > > > > no amount of testing enables me to reproduce this issue. Given that it > > > > seems to occur in other browsers built against the same libraries as > > > > well, I would assume that it's an issue in one of said libs rather than > > > > one of the browser. Though please speak up if anyone reading this can > > > > confirm this issue, too! > > > > > > Agreed. Thorsten, which version of webkit are you using? I appear to > > > be on libwebkit-dev 2.3.4-1ubuntu2. > > > > > > > I'm on 2.2.4-1. ArchLinux uses exactly the same version. And so it does > > with libsoup-dev (2.44.2-1) and gcc (4.8.2-2). > > I briefly tried to dig deeper last night, but it appears to come down > to a bug in whatever is interpreting the js (or perhaps in the rather > magic _clickElement()). > > -serge > Well that's far beyond of my coding abilities :-) I decided to go the easy way, back on Arch now... But anyway, thanks to both of you for your help! Thorsten |
|
From: Hannes S. <ha...@yl...> - 2014-02-25 17:42:06
Attachments:
F.patch
|
Hi, since this troubling effect turned up on IRC again, I'd like to try and dig a little deeper still. Of course, the issue is still that I can't reproduce the behaviour myself. To identify a possible cause, I made a small patch (attached). It would be great if anyone who experienced the issue of the non-working F in the past could try it out. Warning: This is not supposed to be a serious patch for production environments! It will break other things, like links controlled primarily through Javascript. This is only for testing purposes! Hannes |
|
From: Serge E. H. <se...@ha...> - 2014-02-25 17:53:57
|
Quoting Hannes Schüller (ha...@yl...):
> Hi,
>
> since this troubling effect turned up on IRC again, I'd like to try and
> dig a little deeper still. Of course, the issue is still that I can't
> reproduce the behaviour myself. To identify a possible cause, I made a
> small patch (attached). It would be great if anyone who experienced the
> issue of the non-working F in the past could try it out.
>
> Warning: This is not supposed to be a serious patch for production
> environments! It will break other things, like links controlled
> primarily through Javascript. This is only for testing purposes!
>
> Hannes
> diff --git a/hinting.js b/hinting.js
> index 4997cae..58e682a 100644
> --- a/hinting.js
> +++ b/hinting.js
> @@ -386,11 +386,12 @@ function Hints() {
> var oldTarget = elem.target;
>
> /* set target to open in new window */
> - elem.target = "_blank";
> + /*elem.target = "_blank";
> _clickElement(elem);
> elem.target = oldTarget;
>
> - return "done;";
> + return "done;";*/
> + return "tabopen;" + elem.href;
> }
>
> /* fire moudedown and click event on given element */
Yup, with this change F works.
|
|
From: Jason R. <jas...@gm...> - 2014-02-25 19:54:32
|
On 25/02/14 at 06:41pm, Hannes Schüller wrote: >Hi, > >since this troubling effect turned up on IRC again, I'd like to try and >dig a little deeper still. Of course, the issue is still that I can't >reproduce the behaviour myself. To identify a possible cause, I made a >small patch (attached). It would be great if anyone who experienced the >issue of the non-working F in the past could try it out. > Thanks Hannes, This fixes it for webkitgtk2 2.2.5. Cheers, /J -- http://jasonwryan.com/ [GnuPG Key: B1BD4E40] |
|
From: Daniel C. <dan...@gm...> - 2014-03-02 20:30:29
|
Hi Hannes! Hannes Schüller <ha...@yl...> wrote: > Hi, > > since this troubling effect turned up on IRC again, I'd like to try and > dig a little deeper still. Of course, the issue is still that I can't > reproduce the behaviour myself. To identify a possible cause, I made a > small patch (attached). It would be great if anyone who experienced the > issue of the non-working F in the past could try it out. I started to inspect the issue on webkitgtk 2.2.5. To get into the issue I created a little local page with some links, with target attribute set to "_blank", "foo" and links without target attribute. To eliminate false negatives I remove the code that set or removes the target attribute in the hinting.js. So it does not matter if the hinting is started by 'f' or 'F', both should dispatch the click event on the hinted element. If the link contains a 'target' attribute, the click event fails or does not open the link. This is independent from the target attribute value, as long as the attributes value is not empty (target="" works for me, but target="foo" not). This seems to be the problem, because we set the target="_blank" to force webkit to open the link into a new window. I tried to replace the target attribute setting in hinting.js and to achieve the behaviour on an other way, but nothing worked. Setting the CTRL-Key flag on the event to simulate Ctrl-Mouse-Button-1 does not work, set the mouse button to 1 (Middle-Mouse-Button) does not open the link into new window. I'm out of ideas how we can fire the click event to open the link into a new window. Or how we can click the element in a way that the 'notify_event_cb' is triggered. Daniel |
|
From: Hannes S. <ha...@yl...> - 2014-03-03 18:15:25
|
Hi! On Sun, 2 Mar 2014 21:30:37 +0100, Daniel Carl <dan...@gm...> wrote: > Hannes Schüller <ha...@yl...> wrote: > > since this troubling effect turned up on IRC again, I'd like to try > > and dig a little deeper still. Of course, the issue is still that I > > can't reproduce the behaviour myself. To identify a possible cause, > > I made a small patch (attached). It would be great if anyone who > > experienced the issue of the non-working F in the past could try it > > out. > > I started to inspect the issue on webkitgtk 2.2.5. > [...] > I'm out of ideas how we can fire the click event to open the link > into a new window. Or how we can click the element in a way that the > 'notify_event_cb' is triggered. Thanks, Daniel, for this detailed test campaign! What could work, in principle, and the reason why I tried this incomplete mini-patch, would be reverting part of the link firing logic to what we used back before you rewrote this part. Not touching the main part, of course, as that all works great. Just the following: Extend _openNewWindow (hinting.js) to determine what kind of hinted element it is. - If there is some onclick event or similar, generate the mouse click as right now. The target attribute would not do anything anyway in this case, so F behaves like f. - If it's a regular link, return "tabopen;URL". The logic to handle this is still in the script function in main.c, so it would work. I acknowledge and appreciate that this would be much less elegant than the current implementation as it relies on specific, positive tests instead of generic, timeless solutions, but if we consider all possible options (hinting modes), it should work. Do you see any issues? Hannes |
|
From: Daniel C. <dan...@gm...> - 2014-03-03 21:55:32
|
Hannes Schüller <ha...@yl...> wrote: > Thanks, Daniel, for this detailed test campaign! What could work, in > principle, and the reason why I tried this incomplete mini-patch, would > be reverting part of the link firing logic to what we used back before > you rewrote this part. Not touching the main part, of course, as that > all works great. Just the following: > > Extend _openNewWindow (hinting.js) to determine what kind of hinted > element it is. > - If there is some onclick event or similar, generate the mouse click > as right now. The target attribute would not do anything anyway in > this case, so F behaves like f. > - If it's a regular link, return "tabopen;URL". The logic to handle > this is still in the script function in main.c, so it would work. > > I acknowledge and appreciate that this would be much less elegant than > the current implementation as it relies on specific, positive tests > instead of generic, timeless solutions, but if we consider all possible > options (hinting modes), it should work. > > Do you see any issues? Unfortunately, yes! 1. In case the is some onclick attribute set on the element, and the user used 'F' to open it, this would still be opened into the current window (if it opens a page). I think there are a lot of examples in the wild where the onclick does some tracking and than loads the requested page. Also the ixquick links have the onclick attribute set and call in fact window.open() deep in the JavaScript logic. 2. Onclick event handler can be defined outside of the element itself, and this is a common practice (http://api.jquery.com/bind/). I don't understand JavaScript as much, but I'm not sure if will see the bound event handlers of an element. For some cases where the event handler is set like following we can check 'e.onclick', but 'e.hasAttribute("onclick")' will return false. var Button = { click: function(){ alert("clicked"); } }; var e = document.createElement("div"); e.innerHTML = "Click me"; e.onclick = Button.click; e.hasAttribute('onclick')) // returns false ...several minutes later.. I got it, I hope. If the WebkitSetting "javascript-can-open-windows-automatically" is enabled, our current logic works. Maybe we can set this, depending on webkit version, or make it configurable for the user. http://webkitgtk.org/reference/webkit2gtk/unstable/WebKitSettings.html#WebKitSettings--javascript-can-open-windows-automatically |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X