Re: [Vimprobable-users] RFC: Added support for buffers

[Morgan H. <mt...@gm...>]

On Fri, Feb 20, 2015 at 5:07 AM, Hannes Schüller <ha...@yl...> wrote:
> I mean situations where a user would inadvertently allow settings for a
> website he didn't intend. E.g. he would allow all cookies for a certain
> website and then call another site (which he doesn't want to have those
> privileges) in another buffer of the same window – *bam*, there are
> all those tracking cookies written to permanent storage! Similar things
> would apply to many settings.

Ok, understood. Yes it does open up some new potential for users to
make mistakes in that regard. Perhaps some of that behavior should be
configurable, e.g. which settings carry over to new buffers and which
use the defaults. As an aside, we may want to have some option of
showing some of these security/privacy related things in the status
url bar, or perhaps making the format of that bar entirely
configurable.

>> This is a good point, and something I hadn't really thought about as I
>> hadn't yet run into this problem yet with vimprobable (unlike with
>> chrome :). I put together a simple test html with a javascript
>> infinite loop which, as somewhat expected, entirely hangs the browser.
>> However, this problem also exists with the current master so I don't
>> see that it's really anything specific to buffers aside from the
>> annoyance of losing multiple open pages rather than just one.
>
> Well, I'd say that's a major difference. If one page misbehaves, I
> don't mind killing and losing it. Pulling down other pages with it is
> really annoying. But, well, it could be another one of those things
> where people would just have to learn how to use it right, i.e. when to
> open a new window and when to open a new buffer.

As I said I was going to previously, I did spend some time yesterday
and this morning looking into this. Unfortunately, it seems the
options are fairly limited. Multithreading the GTK portion of the app
like this is far from trivial as far as I can tell. The other option
is to use webkit2 which is supposed to be able to handle this
internally. This seems like the way we should go, but of course that's
not exactly trivial either, and some people may not want or even be
able to use webkit2 which requires gtk3. I'll spend some more time
looking into it and see how difficult/ugly it would be to support both
versions of webkit with some kind of thin wrapper layer. Let me know
if you have any thoughts or suggestions on that.

Regards,
Morgan