Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #36514 > unrolled thread

GreaseMonkey GM_setValue - is there a session-only variant ?

Back to article view | Back to comp.lang.javascript

Contents

  GreaseMonkey GM_setValue - is there a session-only variant ? "R.Wieser" <address@not.available> - 2019-05-01 13:44 +0200
    Re: GreaseMonkey GM_setValue - is there a session-only variant ? JJ <jj4public@vfemail.net> - 2019-05-01 19:36 +0700
      Re: GreaseMonkey GM_setValue - is there a session-only variant ? "R.Wieser" <address@not.available> - 2019-05-01 15:08 +0200
        Re: GreaseMonkey GM_setValue - is there a session-only variant ? JJ <jj4public@vfemail.net> - 2019-05-02 17:50 +0700
          Re: GreaseMonkey GM_setValue - is there a session-only variant ? "R.Wieser" <address@not.available> - 2019-05-02 14:25 +0200
            Re: GreaseMonkey GM_setValue - is there a session-only variant ? Julio Di Egidio <julio@diegidio.name> - 2019-05-03 02:02 -0700
            Re: GreaseMonkey GM_setValue - is there a session-only variant ? JJ <jj4public@vfemail.net> - 2019-05-03 19:56 +0700
              Re: GreaseMonkey GM_setValue - is there a session-only variant ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-05-03 15:41 +0200
                Re: GreaseMonkey GM_setValue - is there a session-only variant ? JJ <jj4public@vfemail.net> - 2019-05-04 18:16 +0700
                  Re: GreaseMonkey GM_setValue - is there a session-only variant ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-05-04 13:26 +0200
              Re: GreaseMonkey GM_setValue - is there a session-only variant ? "R.Wieser" <address@not.available> - 2019-05-04 14:40 +0200
    Re: GreaseMonkey GM_setValue - is there a session-only variant ? Julio Di Egidio <julio@diegidio.name> - 2019-05-01 08:22 -0700

#36514 — GreaseMonkey GM_setValue - is there a session-only variant ?

Hello all,

I'm currently using GM_setValue / GM_getValue to store a few preferences 
that should survive page reloads, but noticed that values also survive a 
full browser reload, which is not what I was aiming for.

My question therefore is: is there a session-only variant of the above 
GM_?etValue command available ?

Related question (if the above doesn't exist): Can GM retrieve a 
session-bound value (unique ID) from the browser (so I can compare and 
discard old settings when a new session is found to be running) ?

Regards,
Rudy Wieser

[toc] | [next] | [standalone]

#36516

On Wed, 1 May 2019 13:44:37 +0200, R.Wieser wrote:
> Hello all,
> 
> I'm currently using GM_setValue / GM_getValue to store a few preferences 
> that should survive page reloads, but noticed that values also survive a 
> full browser reload, which is not what I was aiming for.
> 
> My question therefore is: is there a session-only variant of the above 
> GM_?etValue command available ?

GM_setValue / GM_getValue use the LocalStorage of the GM addon's context.
So, the stored data will survive even when a browser tab is closed, and also
when the browser application is closed.

Use plain variables instead. You can also use "one-shot" cookies, but it's
more tedious to maintain.

> Related question (if the above doesn't exist): Can GM retrieve a 
> session-bound value (unique ID) from the browser (so I can compare and 
> discard old settings when a new session is found to be running) ?

You can just use the time value from Date object as the ID. Retrieve it
during the script startup. IMO, its millisecond time resolution is enough to
differentiate between page reloads. And you can still shorten it by removing
the year part, or even the month part from the time value.

[toc] | [prev] | [next] | [standalone]

#36520

JJ,

> Use plain variables instead.

???  I did not think those survive even a a simple reload of the current 
page (all scripts get reloaded-and-started).

> You can just use the time value from Date object as the ID.
> Retrieve it during the script startup.

As each page reload also restarts all involved scripts (and thus retrieves a 
new time) that won't work either I'm afraid.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#36546

On Wed, 1 May 2019 15:08:41 +0200, R.Wieser wrote:
> 
> ???  I did not think those survive even a a simple reload of the current 
> page (all scripts get reloaded-and-started).

Oh sorry. Use SessionStorage in that case. The data will only survive for
the current domain of the loaded page, and as long as the tab or the browser
is not closed.

> As each page reload also restarts all involved scripts (and thus retrieves a 
> new time) that won't work either I'm afraid.

With SessionStorage, the presence of the ID should be checked first. If it
doesn't exist, it'd mean that it's a new session from the script's point of
view. In this case, a new timestamp should be assigned to the ID.

[toc] | [prev] | [next] | [standalone]

#36547

JJ,

> Oh sorry. Use SessionStorage in that case.

Although I've seen a few mentions of 'Session Storage', it looked like it 
needed quite a bit of scripting to create it (as in, not build-in).  But, 
I'll take another look at it.

> The data will only survive for the current domain of the loaded
> page, and as long as the tab or the browser is not closed.

The sounds logical enough, and the on tab-closing might even be better than 
keeping it until the browser itself is closed.

> With SessionStorage, the presence of the ID should be checked first.
> If it doesn't exist, it'd mean that it's a new session from the script's
> point of view. In this case, a new timestamp should be assigned to
> the ID.

I get the "if it doesn't exist" check, but loading it with a timestamp ? 
Not so much.

And thanks.   Knowing what to actually look for makes searching a whole lot 
easier.

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#36555

On Thursday, 2 May 2019 14:25:15 UTC+2, R.Wieser  wrote:
> JJ,

[What post are you replying to?  This is not a forum...]

> > Oh sorry. Use SessionStorage in that case.
> 
> Although I've seen a few mentions of 'Session Storage', it looked like it 
> needed quite a bit of scripting to create it (as in, not build-in).  But, 
> I'll take another look at it.

I suppose it's simply this one:

<https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage>

Indeed it's not built into GM, anyway it's totally straightforward.

HTH,

Julio

[toc] | [prev] | [next] | [standalone]

#36558

On Thu, 2 May 2019 14:25:02 +0200, R.Wieser wrote:
> 
> Although I've seen a few mentions of 'Session Storage', it looked like it 
> needed quite a bit of scripting to create it (as in, not build-in).  But, 
> I'll take another look at it.

SessionStorage is not a GM feature. It's a DOM feature, and it doesn't need
to be created. The usage is just like LocalStorage. Only the name is
different.

[toc] | [prev] | [next] | [standalone]

#36563

JJ <jj4public@vfemail.net> wrote on 03 May 2019 in comp.lang.javascript:

> SessionStorage is not a GM feature. It's a DOM feature, and it doesn't need
> to be created. The usage is just like LocalStorage. Only the name is
> different.

Not so, LocalStorage is kept indefinitely, SessionStorage is destroyed on 
session end [whatever that means in a stateless world.]

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#36566

On Fri, 03 May 2019 15:41:02 +0200, Evertjan. wrote:
> 
> Not so, LocalStorage is kept indefinitely, SessionStorage is destroyed on 
> session end [whatever that means in a stateless world.]

I've already explained that part.

[toc] | [prev] | [next] | [standalone]

#36568

JJ <jj4public@vfemail.net> wrote on 04 May 2019 in comp.lang.javascript:

> On Fri, 03 May 2019 15:41:02 +0200, Evertjan. wrote:
>> 
>> Not so, LocalStorage is kept indefinitely, SessionStorage is destroyed on 
>> session end [whatever that means in a stateless world.]
> 
> I've already explained that part.

If you skip the line, 
where my "Not so" is about,
Usenet discussion becomes impossible.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#36571

JJ,

> SessionStorage is not a GM feature. It's a DOM feature, and it
> doesn't need to be created.

Ackk..  No wonder I couldn't readily find it.     I found a nice bit of info 
about it here:
https://developer.mozilla.org/nl/docs/DOM/Storage

Regards,
Rudy Wieser

[toc] | [prev] | [next] | [standalone]

#36529

On Wednesday, 1 May 2019 13:44:51 UTC+2, R.Wieser  wrote:

> My question therefore is: is there a session-only variant of the above 
> GM_?etValue command available ?

No, not as far as I can see after quickly skimming the docs (very poorly
written by the way, so I might have missed it, but I don't think so...).

> Related question (if the above doesn't exist): Can GM retrieve a
> session-bound value (unique ID) from the browser (so I can compare and
> discard old settings when a new session is found to be running) ?

Can't you simply use so called session cookies (as opposed to permanent
cookies)?  These indeed get unset when the browser (the process, not just
a window) is closed.

HTH,

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web