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

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

fetch with beforeunload

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

Contents

  fetch with beforeunload Andrew Poulos <ap_prog@hotmail.com> - 2018-08-16 16:48 +1000
    Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-16 04:46 -0700
      Re: fetch with beforeunload Andrew Poulos <ap_prog@hotmail.com> - 2018-08-17 14:30 +1000
        Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-17 04:18 -0700
          Re: fetch with beforeunload Andrew Poulos <ap_prog@hotmail.com> - 2018-08-18 19:01 +1000
            Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-18 02:56 -0700
        Re: fetch with beforeunload Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-08-29 22:26 +0200
    Re: fetch with beforeunload "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-08-16 13:18 -0700
      Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-16 13:44 -0700
        Re: fetch with beforeunload "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-08-16 14:28 -0700
          Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-16 14:36 -0700
            Re: fetch with beforeunload "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-08-16 15:32 -0700
            Re: fetch with beforeunload John G Harris <niam@jghnorth.org.uk.invalid> - 2018-08-17 10:46 +0100
              Re: fetch with beforeunload Julio Di Egidio <julio@diegidio.name> - 2018-08-17 04:12 -0700

#35494 — fetch with beforeunload

When the use leaves the page I need to tell the server (send a token - 
short string) so that the server can do some cleaning up.

When I try this

window.addEventListener('beforeunload', function() {
   fetch(url, {
     method: 'POST',
     headers: {
       "Content-Type": "application/x-www-form-urlencoded"
     },
     body: "tk=" + token
   })
   .then (function(response) {
     return response.text();
   })
   .then(function (data) {
     console.log(data);
   });
});

Sometimes the server receives the token and sometimes not. Is there a 
reliable way to do this?

I'm not concerned with whatever data the server might return as the code 
won't be there to process the promise.

If I test by creating the function as a standalone the server doesn't 
return an error and does receive the token.

Andrew Poulos

[toc] | [next] | [standalone]

#35497

On Thursday, 16 August 2018 08:49:01 UTC+2, Andrew Poulos  wrote:

> Sometimes the server receives the token and sometimes not. Is there a 
> reliable way to do this?

You could try and google it first, that is a FAQ and a quick search returns
lots of results.  That said:

To begin with, you should at least set your ajax request to be synchronous,
which will freeze the browser until the request is complete.  It still won't
work reliably as the user might e.g. just kill the browser window, then no
events will fire anyway.

A reliable solution requires a different approach: essentially, poll the server
at intervals to rather say "I am (still) on this page", then on the server use
timeouts to manage a client just disappearing.  If no great granularity is
needed, and there are no other technical reasons to do otherwise, the web
server's session management (which includes a configurable timeout) is usually
quite enough.

HTH,

Julio

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

#35507

On 16/08/2018 9:46 PM, Julio Di Egidio wrote:
> On Thursday, 16 August 2018 08:49:01 UTC+2, Andrew Poulos  wrote:
> 
>> Sometimes the server receives the token and sometimes not. Is there a
>> reliable way to do this?
> 
> You could try and google it first, that is a FAQ and a quick search returns
> lots of results.  That said:
> 
> To begin with, you should at least set your ajax request to be synchronous,
> which will freeze the browser until the request is complete.  It still won't
> work reliably as the user might e.g. just kill the browser window, then no
> events will fire anyway.
> 
> A reliable solution requires a different approach: essentially, poll the server
> at intervals to rather say "I am (still) on this page", then on the server use
> timeouts to manage a client just disappearing.  If no great granularity is
> needed, and there are no other technical reasons to do otherwise, the web
> server's session management (which includes a configurable timeout) is usually
> quite enough.

Thanks. So is the issue that I can't know if whatever I've set to run in 
beforeunload will actually run?

Andrew Poulos

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

#35512

On Friday, 17 August 2018 06:30:22 UTC+2, Andrew Poulos  wrote:

> So is the issue that I can't know if whatever I've set to run in 
> beforeunload will actually run?

Yes, not just asynchronous jobs, the browser or the OS could even just crash:
that's why for anything critical you'd use a different approach, e.g. polling.

Julio

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

#35517

On 17/08/2018 9:18 PM, Julio Di Egidio wrote:
> On Friday, 17 August 2018 06:30:22 UTC+2, Andrew Poulos  wrote:
> 
>> So is the issue that I can't know if whatever I've set to run in
>> beforeunload will actually run?
> 
> Yes, not just asynchronous jobs, the browser or the OS could even just crash:
> that's why for anything critical you'd use a different approach, e.g. polling.

Hmm, so even using navigator.sendBeacon is no guarantee of success.

Andrew Poulos

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

#35518

On Saturday, 18 August 2018 11:01:34 UTC+2, Andrew Poulos  wrote:
> On 17/08/2018 9:18 PM, Julio Di Egidio wrote:
> > On Friday, 17 August 2018 06:30:22 UTC+2, Andrew Poulos  wrote:
> > 
> >> So is the issue that I can't know if whatever I've set to run in
> >> beforeunload will actually run?
> > 
> > Yes, not just asynchronous jobs, the browser or the OS could even just crash:
> > that's why for anything critical you'd use a different approach, e.g. polling.
> 
> Hmm, so even using navigator.sendBeacon is no guarantee of success.

Or simply the Internet could go down...

Rather, in engineering the only guarantee is *guarantee of failure* (Murphy's
Law), and a discipline to handle it: which itself is not about guarantees (this
ain't mathematics),  it's about margins and cost-benefits, in reliability
just as in security and so on.  (E.g. the civil engineer who designs a bridge
calculates minimum material to do the job then, as by law, at least doubles
it, to have more *margin* of safety not any guarantee in any strong sense;
or the fact that one has to take three backups in three different places for important information: not even that is a guarantee in the strong sense, but
it's still good enough to beat the chances and as experience confirms.  And so
on: I suggest a good software engineering book to those who are serious about
programming/software development...)

So you rather start from your requirements and work to cover just those and
at a level of reliability and security and so on that is "economical" all
requirements, explicit and implicit, considered (and so far you have said
nothing about your requirements, which is why you just get a quick overview
of the usual possible approaches).

That said, in the usual web scenario, when the web application (server-side)
goes down, all games are in stand-by anyway, hence the problem (mostly) reduces
to just the problem of the client-side being essentially unreliable.  Hence you
rather use server sessions or, for more sophisticated needs, polling, etc.

HTH,

Julio

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

#35547

Andrew Poulos wrote:
> On 16/08/2018 9:46 PM, Julio Di Egidio wrote:
>> On Thursday, 16 August 2018 08:49:01 UTC+2, Andrew Poulos  wrote:
>>> Sometimes the server receives the token and sometimes not.

“Does not work” is not a problem description.  Certainly you could have
attempted to track down in which circumstances “the server receives the
token” and in which it does not.

>> Is there a reliable way to do this?
>>
>> You could try and google it first, that is a FAQ and a quick search returns
>> lots of results.  That said:
>>
>> To begin with, you should at least set your ajax request to be synchronous,
>> which will freeze the browser until the request is complete. 

Once again the troll manages to come up with the worst possible approach
first.  Synchronous HTTP requests are OBSOLETE since quite a while for good
reasons.  Certainly the Fetch API does not provide a way for it, and that is
good so.  (That API was introduced by the WhatWG to replace the HttpRequest2
API.)

> Thanks. So is the issue that I can't know if whatever I've set to run in 
> beforeunload will actually run?

You might not even be allowed to issue HTTP requests in the “beforeunload”
event listener.  Several other actions are already forbidden/ignored there
in some runtime environments because of usability concerns.


PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

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

#35502

Andrew Poulos wrote:
> When the use leaves the page I need to tell the server (send a token - 
> short string) so that the server can do some cleaning up.
> [...]
> Sometimes the server receives the token and sometimes not. Is there a 
> reliable way to do this?

Generally not in the way you are approaching it as you can not prevent the user from closing a tab, nor the window, nor from turning off the computer, and only limited control over navigation.

One possible approach as an alternative is to periodically send a heartbeat to the server letting it know the client is still active, then once the heartbeed stops you assume the client is dead and do cleanup.

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

#35503

On Thursday, 16 August 2018 22:18:24 UTC+2, Michael Haufe (TNO)  wrote:
> Andrew Poulos wrote:
> > When the use leaves the page I need to tell the server (send a token - 
> > short string) so that the server can do some cleaning up.
> > [...]
> > Sometimes the server receives the token and sometimes not. Is there a 
> > reliable way to do this?
> 
> Generally not in the way you are approaching it as you can not prevent the user from closing a tab, nor the window, nor from turning off the computer, and only limited control over navigation.
> 
> One possible approach as an alternative is to periodically send a heartbeat to the server letting it know the client is still active, then once the heartbeed stops you assume the client is dead and do cleanup.

Another resident moron chiming in to repeat, badly, what already explained...

*Plonk*

Julio

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

#35504

Julio Di Egidio wrote:

> Another resident moron chiming in to repeat, badly, what already explained...

The fact that you suggested using synchronous ajax disqualifies you. Learn To JavaScript.

If you look at the current spec: 

<https://xhr.spec.whatwg.org/#the-open()-method>

You'll see the following:

"Synchronous XMLHttpRequest outside of workers is in the process of being removed from the web platform as it has detrimental effects to the end user’s experience. (This is a long process that takes many years.) Developers must not pass false for the async argument when current global object is a Window object. User agents are strongly encouraged to warn about such usage in developer tools and may experiment with throwing an "InvalidAccessError" DOMException when it occurs."

Do try to keep up.

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

#35505

On Thursday, 16 August 2018 23:28:49 UTC+2, Michael Haufe (TNO)  wrote:
> Julio Di Egidio wrote:
> 
> > Another resident moron chiming in to repeat, badly, what already explained...
> 
> The fact that you suggested using synchronous ajax disqualifies you.

Idiot, I didn't "suggest" any such thing.

> Learn To JavaScript.

FYI, I teach that stuff, you clueless moron and troll.

*Plonk*

Julio

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

#35506

Julio Di Egidio wrote:
> Michael Haufe (TNO)  wrote:

> > The fact that you suggested using synchronous ajax disqualifies you.
> 
> Idiot, I didn't "suggest" any such thing.

"To begin with, you should at least set your ajax request to be synchronous,
which will freeze the browser until the request is complete."

> > Learn To JavaScript.
> 
> FYI, I teach that stuff, you clueless moron and troll.

I weep for your students.

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

#35510

On Thu, 16 Aug 2018 14:36:34 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Thursday, 16 August 2018 23:28:49 UTC+2, Michael Haufe (TNO)  wrote:
>> Julio Di Egidio wrote:

  <snip>
>> Learn To JavaScript.
>
>FYI, I teach that stuff, you clueless moron and troll.

Gawd help us!

  John

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

#35511

On Friday, 17 August 2018 11:46:13 UTC+2, John G Harris  wrote:
> On Thu, 16 Aug 2018 14:36:34 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote:
> >On Thursday, 16 August 2018 23:28:49 UTC+2, Michael Haufe (TNO)  wrote:
> >> Julio Di Egidio wrote:
>   <snip>
> >> Learn To JavaScript.
> >
> >FYI, I teach that stuff, you clueless moron and troll.
> 
> Gawd help us!

God has long left this desolated rock.  (LOL.)

Julio

[toc] | [prev] | [standalone]

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

csiph-web