vimprobable-users — Mailing list for Vimprobable users

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

On Tue, Mar 15, 2016 at 01:57:00PM +0100, Marcos Cruz wrote:
> En/Je/On 2016-03-14 12:25, Serge E. Hallyn escribió / skribis / wrote :
> 
> > Hannes and Marcos, could you tell me the distro and webkit version you're
> > running?
> 
> Raspbian (equivalent to Debian 7.9, for Raspberry Pi)
> 
> libwebkitgtk-1.0-0 Version: 1.8.1-3.4+rpi1

Thanks.  So maybe until I have more time I should statically link with
2.4.8 which apparently works fine.  I'm on 2.4.9 (2.4.9-2ubuntu2).

Re: [Vimprobable-users] js crash

[Marcos C. <vim...@pr...>]

En/Je/On 2016-03-14 12:25, Serge E. Hallyn escribió / skribis / wrote :

> Hannes and Marcos, could you tell me the distro and webkit version you're
> running?

Raspbian (equivalent to Debian 7.9, for Raspberry Pi)

libwebkitgtk-1.0-0 Version: 1.8.1-3.4+rpi1

-- 
Marcos Cruz
http://programandala.net

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

Quoting Hannes Schüller (ha...@yl...):
> On Mon, 14 Mar 2016 12:25:16 -0500, "Serge E. Hallyn"
> <se...@ha...> wrote:
> > Quoting Hannes Schüller (ha...@yl...):
> > > On Sun, 13 Mar 2016 20:26:48 -0500, "Serge E. Hallyn"
> > > <se...@ha...> wrote:
> > > > Quoting Serge E. Hallyn (se...@ha...):
> > > > > Quoting Marcos Cruz (vim...@pr...):  
> > > > > > En/Je/On 2016-03-12 09:22, Hannes Schüller escribió /
> > > > > > skribis / wrote :  
> > > > > > > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn"
> > > > > > > wrote:  
> > > > > > > > as I said, http://imgur.com is my easiest reproducer;
> > > > > > > > just browse with javascript on and page down.  
> > > > > > > 
> > > > > > > Sorry, I can't reproduce it. I scrolled down until it had
> > > > > > > reloaded new images about ten times, but no instability –
> > > > > > > it's working fine here.
> > > > > > > 
> > > > > > > Anyone else experience the problem?  
> > > > > > 
> > > > > > It's working fine here. No problem scrolling down many
> > > > > > times.  
> > > > > 
> > > > > Fascinating - what on earth do I have going on then :)  I'll
> > > > > figure it out.  
> > > > 
> > > > Ok it's purely a webkitgtk bug.  I just reproduced it with surf.
> > > 
> > > Thanks for the followup :)
> > 
> > Hannes and Marcos, could you tell me the distro and webkit version
> > you're running?
> 
> I have Debian with libwebkitgtk-1.0-0 2.4.8-1

Hi,

did you pin that?  I'm seeing:

rmadison -u debian libwebkitgtk-1.0-0
libwebkitgtk-1.0-0 | 1.8.1-3.4      | oldstable       | amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc
libwebkitgtk-1.0-0 | 2.4.8-2        | stable-kfreebsd | kfreebsd-amd64, kfreebsd-i386
libwebkitgtk-1.0-0 | 2.4.9-1~deb8u1 | stable          | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
libwebkitgtk-1.0-0 | 2.4.9-3        | testing         | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x
libwebkitgtk-1.0-0 | 2.4.9-3        | unstable        | amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x

I should probably look at the debdiff from 2.4.8-1..2.4.9-3 (or -2), the bug must lie there.

Re: [Vimprobable-users] js crash

[Hannes S. <ha...@yl...>]

On Mon, 14 Mar 2016 12:25:16 -0500, "Serge E. Hallyn"
<se...@ha...> wrote:
> Quoting Hannes Schüller (ha...@yl...):
> > On Sun, 13 Mar 2016 20:26:48 -0500, "Serge E. Hallyn"
> > <se...@ha...> wrote:
> > > Quoting Serge E. Hallyn (se...@ha...):
> > > > Quoting Marcos Cruz (vim...@pr...):  
> > > > > En/Je/On 2016-03-12 09:22, Hannes Schüller escribió /
> > > > > skribis / wrote :  
> > > > > > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn"
> > > > > > wrote:  
> > > > > > > as I said, http://imgur.com is my easiest reproducer;
> > > > > > > just browse with javascript on and page down.  
> > > > > > 
> > > > > > Sorry, I can't reproduce it. I scrolled down until it had
> > > > > > reloaded new images about ten times, but no instability –
> > > > > > it's working fine here.
> > > > > > 
> > > > > > Anyone else experience the problem?  
> > > > > 
> > > > > It's working fine here. No problem scrolling down many
> > > > > times.  
> > > > 
> > > > Fascinating - what on earth do I have going on then :)  I'll
> > > > figure it out.  
> > > 
> > > Ok it's purely a webkitgtk bug.  I just reproduced it with surf.
> > 
> > Thanks for the followup :)
> 
> Hannes and Marcos, could you tell me the distro and webkit version
> you're running?

I have Debian with libwebkitgtk-1.0-0 2.4.8-1

Hannes

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

Quoting Hannes Schüller (ha...@yl...):
> On Sun, 13 Mar 2016 20:26:48 -0500, "Serge E. Hallyn"
> <se...@ha...> wrote:
> > Quoting Serge E. Hallyn (se...@ha...):
> > > Quoting Marcos Cruz (vim...@pr...):  
> > > > En/Je/On 2016-03-12 09:22, Hannes Schüller escribió / skribis /
> > > > wrote :  
> > > > > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn" wrote:  
> > > > > > as I said, http://imgur.com is my easiest reproducer;  just
> > > > > > browse with javascript on and page down.  
> > > > > 
> > > > > Sorry, I can't reproduce it. I scrolled down until it had
> > > > > reloaded new images about ten times, but no instability – it's
> > > > > working fine here.
> > > > > 
> > > > > Anyone else experience the problem?  
> > > > 
> > > > It's working fine here. No problem scrolling down many times.  
> > > 
> > > Fascinating - what on earth do I have going on then :)  I'll figure
> > > it out.  
> > 
> > Ok it's purely a webkitgtk bug.  I just reproduced it with surf.
> 
> Thanks for the followup :)

Hannes and Marcos, could you tell me the distro and webkit version you're
running?

Re: [Vimprobable-users] js crash

[Hannes S. <ha...@yl...>]

On Sun, 13 Mar 2016 20:26:48 -0500, "Serge E. Hallyn"
<se...@ha...> wrote:
> Quoting Serge E. Hallyn (se...@ha...):
> > Quoting Marcos Cruz (vim...@pr...):  
> > > En/Je/On 2016-03-12 09:22, Hannes Schüller escribió / skribis /
> > > wrote :  
> > > > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn" wrote:  
> > > > > as I said, http://imgur.com is my easiest reproducer;  just
> > > > > browse with javascript on and page down.  
> > > > 
> > > > Sorry, I can't reproduce it. I scrolled down until it had
> > > > reloaded new images about ten times, but no instability – it's
> > > > working fine here.
> > > > 
> > > > Anyone else experience the problem?  
> > > 
> > > It's working fine here. No problem scrolling down many times.  
> > 
> > Fascinating - what on earth do I have going on then :)  I'll figure
> > it out.  
> 
> Ok it's purely a webkitgtk bug.  I just reproduced it with surf.

Thanks for the followup :)

Hannes

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

Quoting Serge E. Hallyn (se...@ha...):
> Quoting Marcos Cruz (vim...@pr...):
> > En/Je/On 2016-03-12 09:22, Hannes Schüller escribió / skribis / wrote :
> > > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn" wrote:
> > > > as I said, http://imgur.com is my easiest reproducer;  just browse
> > > > with javascript on and page down.
> > > 
> > > Sorry, I can't reproduce it. I scrolled down until it had reloaded new
> > > images about ten times, but no instability – it's working fine here.
> > > 
> > > Anyone else experience the problem?
> > 
> > It's working fine here. No problem scrolling down many times.
> 
> Fascinating - what on earth do I have going on then :)  I'll figure
> it out.

Ok it's purely a webkitgtk bug.  I just reproduced it with surf.

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

Quoting Marcos Cruz (vim...@pr...):
> En/Je/On 2016-03-12 09:22, Hannes Schüller escribió / skribis / wrote :
> > On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn" wrote:
> > > as I said, http://imgur.com is my easiest reproducer;  just browse
> > > with javascript on and page down.
> > 
> > Sorry, I can't reproduce it. I scrolled down until it had reloaded new
> > images about ten times, but no instability – it's working fine here.
> > 
> > Anyone else experience the problem?
> 
> It's working fine here. No problem scrolling down many times.

Fascinating - what on earth do I have going on then :)  I'll figure
it out.

thanks,
-serge

Re: [Vimprobable-users] js crash

[Marcos C. <vim...@pr...>]

En/Je/On 2016-03-12 09:22, Hannes Schüller escribió / skribis / wrote :
> On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn" wrote:
> > as I said, http://imgur.com is my easiest reproducer;  just browse
> > with javascript on and page down.
> 
> Sorry, I can't reproduce it. I scrolled down until it had reloaded new
> images about ten times, but no instability – it's working fine here.
> 
> Anyone else experience the problem?

It's working fine here. No problem scrolling down many times.

-- 
Marcos Cruz
http://programandala.net

Re: [Vimprobable-users] js crash

[Hannes S. <ha...@yl...>]

On Fri, 11 Mar 2016 18:39:13 -0600, "Serge E. Hallyn"
<se...@ha...> wrote:
> On Fri, Mar 11, 2016 at 04:19:07PM +0100, Hannes Schüller wrote:
> > On Fri, 11 Mar 2016 02:26:24 -0600, "Serge E. Hallyn"
> > <se...@ha...> wrote:
> > > for several months now I've had regular crashes in vimprobable -
> > > most easily reproduced by turning js on and going to imgur, then
> > > paging down a bit.  Presumably ad reloading or something.  gdb
> > > unhelpfully gives me:
> > 
> > Could you provide an URL where this happens? Also, could you build
> > the browser with debugging symbols enabled (see Makefile) and then
> > provide a backtrace?
> 
> I went ahead and rebuilt, and got:
> 
> Thread 1 "vimprobable2" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff4cb6678 in JSC::JSCell::toPrimitive(JSC::ExecState*,
> JSC::PreferredPrimitiveType) const ()
> from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0 (gdb)
> where #0  0x00007ffff4cb6678 in
> JSC::JSCell::toPrimitive(JSC::ExecState*,
> JSC::PreferredPrimitiveType) const ()
> from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0 #1
> 0x00007ffff4d1bf0b in JSC::JSValue::toStringSlowCase(JSC::ExecState*)
> const () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
> #2  0x00007ffff4b87991 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0 #3
> 0x00007ffff4b88273 in ?? ()
> from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0 #4
> 0x00007fff90065409 in ?? () #5  0x0000000000000000 in ?? ()

Hm, still not particularly telling. Probably an indication that the
error is really inside a library rather than the browser itself.

> as I said, http://imgur.com is my easiest reproducer;  just browse
> with javascript on and page down.

Sorry, I can't reproduce it. I scrolled down until it had reloaded new
images about ten times, but no instability – it's working fine here.

Anyone else experience the problem?

Hannes

Re: [Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

On Fri, Mar 11, 2016 at 04:19:07PM +0100, Hannes Schüller wrote:
> Hi Serge!
> 
> On Fri, 11 Mar 2016 02:26:24 -0600, "Serge E. Hallyn"
> <se...@ha...> wrote:
> > for several months now I've had regular crashes in vimprobable - most
> > easily reproduced by turning js on and going to imgur, then paging
> > down a bit.  Presumably ad reloading or something.  gdb unhelpfully
> > gives me:
> 
> Could you provide an URL where this happens? Also, could you build the
> browser with debugging symbols enabled (see Makefile) and then provide a
> backtrace?

I went ahead and rebuilt, and got:

Thread 1 "vimprobable2" received signal SIGSEGV, Segmentation fault.
0x00007ffff4cb6678 in JSC::JSCell::toPrimitive(JSC::ExecState*, JSC::PreferredPrimitiveType) const ()
   from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
(gdb) where
#0  0x00007ffff4cb6678 in JSC::JSCell::toPrimitive(JSC::ExecState*, JSC::PreferredPrimitiveType) const ()
   from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#1  0x00007ffff4d1bf0b in JSC::JSValue::toStringSlowCase(JSC::ExecState*) const ()
   from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#2  0x00007ffff4b87991 in ?? () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#3  0x00007ffff4b88273 in ?? () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#4  0x00007fff90065409 in ?? ()
#5  0x0000000000000000 in ?? ()

as I said, http://imgur.com is my easiest reproducer;  just browse with
javascript on and page down.

Re: [Vimprobable-users] js crash

[Hannes S. <ha...@yl...>]

Hi Serge!

On Fri, 11 Mar 2016 02:26:24 -0600, "Serge E. Hallyn"
<se...@ha...> wrote:
> for several months now I've had regular crashes in vimprobable - most
> easily reproduced by turning js on and going to imgur, then paging
> down a bit.  Presumably ad reloading or something.  gdb unhelpfully
> gives me:

Could you provide an URL where this happens? Also, could you build the
browser with debugging symbols enabled (see Makefile) and then provide a
backtrace?

Hannes

[Vimprobable-users] js crash

[Serge E. H. <se...@ha...>]

Hi,

for several months now I've had regular crashes in vimprobable - most
easily reproduced by turning js on and going to imgur, then paging
down a bit.  Presumably ad reloading or something.  gdb unhelpfully
gives me:

(gdb) where
#0  0x00007f6dcfe6e6f0 in JSC::JSCell::getPrimitiveNumber(JSC::ExecState*, double&, JSC::JSValue&) const () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#1  0x00007f6dcfd44bdc in ?? () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
#2  0x00007f6d703ac3f0 in ?? ()
#3  0x00007f6d5deae5b0 in ?? ()
#4  0x00007f6dbd868000 in ?? ()
#5  0x00007f6d4c0756c8 in ?? ()
#6  0x00007fff79eb11d0 in ?? ()
#7  0x00007f6d5e32eff8 in ?? ()
#8  0x00007fff79eb11e0 in ?? ()
#9  0x00007fff79eb1160 in ?? ()
#10 0x00007f6dcfd29813 in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*, JSC::Register*) () from /usr/lib/x86_64-linux-gnu/libjavascriptcoregtk-1.0.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Just curious, does this say anything to anyone here?

thanks,
-serge

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Serge E. H. <se...@ha...>]

On Fri, Dec 11, 2015 at 03:40:14PM +0100, Hannes Schüller wrote:
> On Tue, 8 Dec 2015 22:45:43 -0600, "Serge E. Hallyn" <se...@ha...>
> wrote:
> > On Wed, Dec 09, 2015 at 05:17:23AM +0100, Hannes Schüller wrote:
> > > Matthew Carter <m...@ah...>:
> > > > "Serge E. Hallyn" <se...@ha...> writes:
> > > > 
> > > > > That does sound good.  Though when site A grabs content from
> > > > > site B, which site should we use?
> > > > >
> > > > 
> > > > I would say, whichever site is in the URL bar is the one I'd
> > > > expect to set the cookie file (so, site A).
> > > 
> > > Hm, that sounds pretty much like the existing "no third party
> > > cookies" setting...
> > 
> > Well no, the idea would be your config could set
> > 
> > set cookies_file *.launchpad.net cookies_lp
> > set cookies_file *.github.com cookies_gh
> > set cookies_file * cookies
> > 
> > and vimprobable2 would just do it.
> 
> Yes, of course, sorry. The original idea is fundamentally different, of
> course. I'm just thinking that Matthew's proposal for automatically
> handling one file per host name is similar to the existing function
> (although also not completely identical).
> 
> Hannes

Yup, I don't know if we'd want both, but I'm pretty sure I'd be happy
with just Matthew's proposal.  Happier than with just mine.

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Hannes S. <ha...@yl...>]

On Tue, 8 Dec 2015 22:45:43 -0600, "Serge E. Hallyn" <se...@ha...>
wrote:
> On Wed, Dec 09, 2015 at 05:17:23AM +0100, Hannes Schüller wrote:
> > Matthew Carter <m...@ah...>:
> > > "Serge E. Hallyn" <se...@ha...> writes:
> > > 
> > > > That does sound good.  Though when site A grabs content from
> > > > site B, which site should we use?
> > > >
> > > 
> > > I would say, whichever site is in the URL bar is the one I'd
> > > expect to set the cookie file (so, site A).
> > 
> > Hm, that sounds pretty much like the existing "no third party
> > cookies" setting...
> 
> Well no, the idea would be your config could set
> 
> set cookies_file *.launchpad.net cookies_lp
> set cookies_file *.github.com cookies_gh
> set cookies_file * cookies
> 
> and vimprobable2 would just do it.

Yes, of course, sorry. The original idea is fundamentally different, of
course. I'm just thinking that Matthew's proposal for automatically
handling one file per host name is similar to the existing function
(although also not completely identical).

Hannes

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Serge E. H. <se...@ha...>]

On Wed, Dec 09, 2015 at 05:17:23AM +0100, Hannes Schüller wrote:
> Matthew Carter <m...@ah...>:
> > "Serge E. Hallyn" <se...@ha...> writes:
> > 
> > > That does sound good.  Though when site A grabs content from site B,
> > > which site should we use?
> > >
> > 
> > I would say, whichever site is in the URL bar is the one I'd expect to
> > set the cookie file (so, site A).
> 
> Hm, that sounds pretty much like the existing "no third party cookies"
> setting...

Well no, the idea would be your config could set

set cookies_file *.launchpad.net cookies_lp
set cookies_file *.github.com cookies_gh
set cookies_file * cookies

and vimprobable2 would just do it.

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Hannes S. <ha...@yl...>]

Matthew Carter <m...@ah...>:
> "Serge E. Hallyn" <se...@ha...> writes:
> 
> > That does sound good.  Though when site A grabs content from site B,
> > which site should we use?
> >
> 
> I would say, whichever site is in the URL bar is the one I'd expect to
> set the cookie file (so, site A).

Hm, that sounds pretty much like the existing "no third party cookies"
setting...

Hannes

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Matthew C. <m...@ah...>]

"Serge E. Hallyn" <se...@ha...> writes:

> That does sound good.  Though when site A grabs content from site B,
> which site should we use?
>

I would say, whichever site is in the URL bar is the one I'd expect to
set the cookie file (so, site A).

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Serge E. H. <se...@ha...>]

That does sound good.  Though when site A grabs content from site B,
which site should we use?

On Mon, Dec 07, 2015 at 03:05:46PM -0500, Matthew Carter wrote:
> Dynamically setting a new cookie file based on the host domain automatically would be amazing 
> 
> -------- Original message --------
> From: "Serge E. Hallyn" <se...@ha...> 
> Date: 12/07/2015  1:36 PM  (GMT-05:00) 
> To: vim...@li... 
> Subject: Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site
  cookie files 
> 
> On Mon, Dec 07, 2015 at 07:12:13PM +0100, Hannes Schüller wrote:
> > Hi Serge,
> > 
> > thanks for this patch!
> > 
> > "Serge E. Hallyn" <se...@ha...>:
> > > The default cookie site is ~/.config/vimprobable/cookies.  With this
> > > patch, you can do
> > > 
> > > :cookies gh
> > > or
> > > :cookies lp
> > > 
> > > to load a per-site cookiefile called ~/.config/vimprobable/cookies_gh
> > > or cookies_lp (i.e. for github and launchpad).  This allows you to
> > > segregate cookies by sites, and more easily keep an eye on suspect
> > > sites.
> > 
> > I basically have two comments.
> > 
> > 1. I see no way of switching back to the original file.
> 
> true.
> 
> > 2. What's the rationale for defining this as a new command rather than
> >    a "setting"? From your original description, I would have expected
> >    something like
> >    :set cookiefile=...
> >    Don't you think it could be a little confusing to have both
> >    :set cookies=(on|off)
> >    *and*
> >    :cookies=...
> 
> In fact it is a little confusing :)  But I did it for lazyness'
> sake.  I'll probably have 4-5 cookie files (too many to assign 
> ctrl-<something> to each one), and I see no way to map, say,
> f6 to ":set cookie_file=" leaving me to fill in the name.  So
> ':c<tab>' works nicely.
> 
> I suppose providing a way (if I'm not wrong, and such a way doesn't
> already exist :) to allow such mapping, and making cookiefile a
> setting, would make the most sense.
> 
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users

> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140

> _______________________________________________
> Vimprobable-users mailing list
> Vim...@li...
> https://lists.sourceforge.net/lists/listinfo/vimprobable-users

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Matthew C. <mc...@ah...>]

Dynamically setting a new cookie file based on the host domain automatically would be amazing 

-------- Original message --------
From: "Serge E. Hallyn" <se...@ha...> 
Date: 12/07/2015  1:36 PM  (GMT-05:00) 
To: vim...@li... 
Subject: Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site
  cookie files 

On Mon, Dec 07, 2015 at 07:12:13PM +0100, Hannes Schüller wrote:
> Hi Serge,
> 
> thanks for this patch!
> 
> "Serge E. Hallyn" <se...@ha...>:
> > The default cookie site is ~/.config/vimprobable/cookies.  With this
> > patch, you can do
> > 
> > :cookies gh
> > or
> > :cookies lp
> > 
> > to load a per-site cookiefile called ~/.config/vimprobable/cookies_gh
> > or cookies_lp (i.e. for github and launchpad).  This allows you to
> > segregate cookies by sites, and more easily keep an eye on suspect
> > sites.
> 
> I basically have two comments.
> 
> 1. I see no way of switching back to the original file.

true.

> 2. What's the rationale for defining this as a new command rather than
>    a "setting"? From your original description, I would have expected
>    something like
>    :set cookiefile=...
>    Don't you think it could be a little confusing to have both
>    :set cookies=(on|off)
>    *and*
>    :cookies=...

In fact it is a little confusing :)  But I did it for lazyness'
sake.  I'll probably have 4-5 cookie files (too many to assign 
ctrl-<something> to each one), and I see no way to map, say,
f6 to ":set cookie_file=" leaving me to fill in the name.  So
':c<tab>' works nicely.

I suppose providing a way (if I'm not wrong, and such a way doesn't
already exist :) to allow such mapping, and making cookiefile a
setting, would make the most sense.

------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Vimprobable-users mailing list
Vim...@li...
https://lists.sourceforge.net/lists/listinfo/vimprobable-users

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Serge E. H. <se...@ha...>]

On Mon, Dec 07, 2015 at 07:12:13PM +0100, Hannes Schüller wrote:
> Hi Serge,
> 
> thanks for this patch!
> 
> "Serge E. Hallyn" <se...@ha...>:
> > The default cookie site is ~/.config/vimprobable/cookies.  With this
> > patch, you can do
> > 
> > :cookies gh
> > or
> > :cookies lp
> > 
> > to load a per-site cookiefile called ~/.config/vimprobable/cookies_gh
> > or cookies_lp (i.e. for github and launchpad).  This allows you to
> > segregate cookies by sites, and more easily keep an eye on suspect
> > sites.
> 
> I basically have two comments.
> 
> 1. I see no way of switching back to the original file.

true.

> 2. What's the rationale for defining this as a new command rather than
>    a "setting"? From your original description, I would have expected
>    something like
>    :set cookiefile=...
>    Don't you think it could be a little confusing to have both
>    :set cookies=(on|off)
>    *and*
>    :cookies=...

In fact it is a little confusing :)  But I did it for lazyness'
sake.  I'll probably have 4-5 cookie files (too many to assign 
ctrl-<something> to each one), and I see no way to map, say,
f6 to ":set cookie_file=" leaving me to fill in the name.  So
':c<tab>' works nicely.

I suppose providing a way (if I'm not wrong, and such a way doesn't
already exist :) to allow such mapping, and making cookiefile a
setting, would make the most sense.

Re: [Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Hannes S. <ha...@yl...>]

Hi Serge,

thanks for this patch!

"Serge E. Hallyn" <se...@ha...>:
> The default cookie site is ~/.config/vimprobable/cookies.  With this
> patch, you can do
> 
> :cookies gh
> or
> :cookies lp
> 
> to load a per-site cookiefile called ~/.config/vimprobable/cookies_gh
> or cookies_lp (i.e. for github and launchpad).  This allows you to
> segregate cookies by sites, and more easily keep an eye on suspect
> sites.

I basically have two comments.

1. I see no way of switching back to the original file.
2. What's the rationale for defining this as a new command rather than
   a "setting"? From your original description, I would have expected
   something like
   :set cookiefile=...
   Don't you think it could be a little confusing to have both
   :set cookies=(on|off)
   *and*
   :cookies=...

Hannes

[Vimprobable-users] [PATCH RFC] Add command to load per-site cookie files

[Serge E. H. <se...@ha...>]

The default cookie site is ~/.config/vimprobable/cookies.  With this patch,
you can do

:cookies gh
or
:cookies lp

to load a per-site cookiefile called ~/.config/vimprobable/cookies_gh or
cookies_lp (i.e. for github and launchpad).  This allows you to segregate
cookies by sites, and more easily keep an eye on suspect sites.

Signed-off-by: Serge Hallyn <ser...@ub...>
---
 config.h      |  2 ++
 main.c        | 31 +++++++++++++++++++++++++------
 vimprobable.h |  2 +-
 3 files changed, 28 insertions(+), 7 deletions(-)

diff --git a/config.h b/config.h
index e423f77..33ab743 100644
--- a/config.h
+++ b/config.h
@@ -83,6 +83,7 @@ static URIHandler uri_handlers[] = {
 /* cookies */
 #define             ENABLE_COOKIE_SUPPORT
 #define             COOKIES_STORAGE_FILENAME    "%s/vimprobable/cookies", client.config.config_base
+#define             COOKIES_STORAGE_PATH        "%s/vimprobable/cookies_%s", client.config.config_base
 #define             COOKIES_STORAGE_READONLY    FALSE   /* if TRUE new cookies will be lost if you quit */
 SoupCookieJarAcceptPolicy CookiePolicy = SOUP_COOKIE_JAR_ACCEPT_NO_THIRD_PARTY; /* by default, accept all cookies, but third party */
 SoupCookieJarAcceptPolicy CookiePolicyLastOn = SOUP_COOKIE_JAR_ACCEPT_NO_THIRD_PARTY; /* tracking variable for private mode */
@@ -156,6 +157,7 @@ Command commands[COMMANDSIZE] = {
     { "tabopen",                                       	open_arg,         {TargetNew} },
     { "print",                                         	print_frame,      {0} },
     { "bma",                                           	bookmark,         {0} },
+    { "cookies",                                       	switch_cookies,   {0} },
     { "bookmark",                                      	bookmark,         {0} },
     { "source",                                        	view_source,      {0} },
     { "esource",                                       	edit_source,      {0} },
diff --git a/main.c b/main.c
index d90c4c2..d72d0a1 100644
--- a/main.c
+++ b/main.c
@@ -66,6 +66,7 @@ static gboolean blank_cb(void);
 
 /* functions */
 static gboolean bookmark(const Arg *arg);
+static gboolean switch_cookies(const Arg *arg);
 static gboolean browser_settings(const Arg *arg);
 static gboolean commandhistoryfetch(const Arg *arg);
 static gboolean complete(const Arg *arg);
@@ -135,7 +136,7 @@ static char **args;
 
 /* Cookie support. */
 #ifdef ENABLE_COOKIE_SUPPORT
-static void setup_cookies(void);
+static void setup_cookies(const char *);
 static char *get_cookies(SoupURI *soup_uri);
 static void load_all_cookies(void);
 static void new_generic_request(SoupSession *soup_ses, SoupMessage *soup_msg, gpointer unused);
@@ -1765,6 +1766,24 @@ commandhistoryfetch(const Arg *arg) {
 }
 
 gboolean
+switch_cookies(const Arg *arg) {
+    if (!arg->s || !strlen(arg->s)) {
+        echo_message(Info, "No cookie file given");
+        return FALSE;
+    }
+
+    Network *net = &client.net;
+    if (net->file_cookie_jar)
+        g_object_unref(net->file_cookie_jar);
+    char *tmp = g_strdup_printf(COOKIES_STORAGE_PATH, arg->s);
+    setup_cookies(tmp);
+    g_free(tmp);
+
+    echo_message(Info, "Cookies loaded");
+    return TRUE;
+}
+
+gboolean
 bookmark(const Arg *arg) {
     FILE *f;
     const char *filename;
@@ -2969,11 +2988,9 @@ scripts_run_user_file() {
 
 #ifdef ENABLE_COOKIE_SUPPORT
 void
-setup_cookies()
+setup_cookies(const char *cookiefile)
 {
     Network *net = &client.net;
-    if (net->file_cookie_jar)
-        g_object_unref(net->file_cookie_jar);
 
     if (net->session_cookie_jar)
 		g_object_unref(net->session_cookie_jar);
@@ -2981,7 +2998,7 @@ setup_cookies()
 	net->session_cookie_jar = soup_cookie_jar_new();
 	soup_cookie_jar_set_accept_policy(net->session_cookie_jar, CookiePolicy);
 
-	net->cookie_store = g_strdup_printf(COOKIES_STORAGE_FILENAME);
+	net->cookie_store = g_strdup(cookiefile);
 
 	load_all_cookies();
 
@@ -3181,7 +3198,9 @@ main(int argc, char *argv[]) {
     make_keyslist();
     setup_gui();
 #ifdef ENABLE_COOKIE_SUPPORT
-    setup_cookies();
+    char *tmp = g_strdup_printf(COOKIES_STORAGE_FILENAME);
+    setup_cookies(tmp);
+    g_free(tmp);
 #endif
 
     make_searchengines_list(searchengines, LENGTH(searchengines));
diff --git a/vimprobable.h b/vimprobable.h
index 5f6ee83..949eb14 100644
--- a/vimprobable.h
+++ b/vimprobable.h
@@ -193,7 +193,7 @@ enum ConfigFileError {
 #define             CLOSED_URL_FILENAME         "%s/vimprobable/closed", client.config.config_base
 
 /* Command size */
-#define	            COMMANDSIZE	                49
+#define	            COMMANDSIZE	                51
 
 /* maximum size of internal string variable handled by :set
  * if you set this to anything lower than 8, colour values
-- 
2.5.0

Re: [Vimprobable-users] cookies

[Serge E. H. <ser...@ub...>]

On Sun, Nov 22, 2015 at 10:11:22AM +0100, Hannes Schüller wrote:
> "Serge E. Hallyn" <se...@ha...>:
> > has anyone written a patch to make the the cookies file and the
> > readonly state configurable? (I.e. :set cookies=~/github.cookies)
> 
> Sounds useful!

Ok, I'm playing with my wm right now, I'll try to get something along
these lines in the next few weeks.

Re: [Vimprobable-users] 117 new quickmarks

[Hannes S. <ha...@yl...>]

Merged (minus the unrelated whitespace changes)