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

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

Shutting script down when leaving page

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

Contents

  Shutting script down when leaving page Xox <etacx18@etaoin.com> - 2014-01-27 03:25 +0000
    Re: Shutting script down when leaving page Andrew Poulos <ap_prog@hotmail.com> - 2014-01-27 18:08 +1100
      Re: Shutting script down when leaving page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-27 10:23 +0100
      Re: Shutting script down when leaving page Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-27 11:21 +0100
        Re: Shutting script down when leaving page Tim Streater <timstreater@greenbee.net> - 2014-01-27 10:41 +0000
          Re: Shutting script down when leaving page Xox <etacx18@etaoin.com> - 2014-01-27 19:43 +0000
            Re: Shutting script down when leaving page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-27 20:53 +0100
              Re: Shutting script down when leaving page Xox <etacx18@etaoin.com> - 2014-01-27 20:52 +0000
            Re: Shutting script down when leaving page Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 01:20 +0100
              Re: Shutting script down when leaving page Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 01:24 +0100
              Re: Shutting script down when leaving page "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-27 18:44 -0800
              Re: Shutting script down when leaving page Xox <etacx18@etaoin.com> - 2014-01-28 05:03 +0000
                Re: Shutting script down when leaving page Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 11:33 +0100
                  Re: Shutting script down when leaving page Xox <etacx18@etaoin.com> - 2014-01-28 19:40 +0000
              Re: Shutting script down when leaving page "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-28 09:31 +0100
        Re: Shutting script down when leaving page Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-27 21:37 +0100
          Re: Shutting script down when leaving page Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-01-28 00:10 +0100
            Re: Shutting script down when leaving page Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-28 00:54 +0100

#22811 — Shutting script down when leaving page

Let us suppose I have a page, a.html, which contains a
script which constantly invokes itself or is invoked --
it's running not necessarily continuously but at regular
intervals, or maybe it is looping.  In any case it's
active.  Now the viewer goes to an entirely different
page using the same window/tab, so a.html has disappeared.
It seems reasonable to assume that the script would stop
running.  But is this in fact known to be the case across 
all contemporary browsers?  The reason I ask is that I 
observed some CPU usage which seemed to indicate that
something was going on after the page had been left.
The script I am dealing with could be costly in terms
of CPU and if it continues to run I should shut it
down explicitly when the browser leaves the page.

[toc] | [next] | [standalone]

#22812

On 27/01/2014 2:25 PM, Xox wrote:
> Let us suppose I have a page, a.html, which contains a
> script which constantly invokes itself or is invoked --
> it's running not necessarily continuously but at regular
> intervals, or maybe it is looping.  In any case it's
> active.  Now the viewer goes to an entirely different
> page using the same window/tab, so a.html has disappeared.
> It seems reasonable to assume that the script would stop
> running.  But is this in fact known to be the case across
> all contemporary browsers?  The reason I ask is that I
> observed some CPU usage which seemed to indicate that
> something was going on after the page had been left.
> The script I am dealing with could be costly in terms
> of CPU and if it continues to run I should shut it
> down explicitly when the browser leaves the page.

Perhaps calling onunload and/or onbeforeunload and stopping the script 
will help.

Andrew Poulos

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

#22814

Andrew Poulos <ap_prog@hotmail.com> wrote on 27 jan 2014 in 
comp.lang.javascript:

> On 27/01/2014 2:25 PM, Xox wrote:
>> Let us suppose I have a page, a.html, which contains a
>> script which constantly invokes itself or is invoked --
>> it's running not necessarily continuously but at regular
>> intervals, or maybe it is looping.  In any case it's
>> active.  Now the viewer goes to an entirely different
>> page using the same window/tab, so a.html has disappeared.
>> It seems reasonable to assume that the script would stop
>> running.  But is this in fact known to be the case across
>> all contemporary browsers?  The reason I ask is that I
>> observed some CPU usage which seemed to indicate that
>> something was going on after the page had been left.
>> The script I am dealing with could be costly in terms
>> of CPU and if it continues to run I should shut it
>> down explicitly when the browser leaves the page.
> 
> Perhaps calling onunload and/or onbeforeunload and stopping the script 
> will help.

Methinks this is nonsence.

Let us not prescribe a cure before we detect an illness.

Is there any evidence showing this fairly illogical idea?

It feels like a believe in postmortal life,
while death is defined as the end of life.

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

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

#22822

Andrew Poulos wrote:

> On 27/01/2014 2:25 PM, Xox wrote:
>> Let us suppose I have a page, a.html, which contains a script which
>> constantly invokes itself or is invoked -- it's running not necessarily
>> continuously but at regular intervals, or maybe it is looping.

There are no pages, they are not “running”, and they certainly do not 
“loop”.  Scripts do not “invoke themselves” either.

Script code may cause other code to be executed repeatedly, using the 
browser API, and it may cause a resource in a view to be reloaded, upon 
which it could be executed again if it was part of that resource.  That
is not a loop.

>> In any case it's active.

HTTP is a stateless protocol.

>> Now the viewer goes to an entirely different page using the same
>> window/tab, so a.html has disappeared.

The resource has been navigated away from.  It is still existing, but is not 
displayed anymore.

>> It seems reasonable to assume that the script would stop running. 

No, it is not.  Window and document are separate entities.

>> But is this in fact known to be the case across all contemporary
>> browsers?

No, it never was.

>> The reason I ask is that I observed some CPU usage which seemed to
>> indicate that something was going on after the page had been left.
>> The script I am dealing with could be costly in terms of CPU

And therefore might need to be replaced with something more efficient, or 
removed.

>> and if it continues to run I should shut it down explicitly when the
>> browser leaves the page.
> 
> Perhaps calling onunload and/or onbeforeunload and stopping the script
> will help.

“onunload” and “onbeforeunload” are event-handler attributes and properties.  
They cannot be called by the developer to the desired effect because the 
developer does not know when they should call them in the first place.

There is an unfortunate tendency of saying that something is “called” when 
any action is caused by anything, particularly among beginners.  People 
nonsensically speak of “Ajax calls”, for example.

Also, because the implementation is single-threaded, scripts cannot be 
stopped or shut down; only the execution of code planned for later execution 
can be prevented (with window.clearTimeout() or window.clearInterval(), or 
setting a key variable or property to a key value so that repeated execution 
is prevented).

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22823

In article <6507961.N3xZG9CObR@PointedEars.de>, Thomas 'PointedEars'
Lahn <PointedEars@web.de> wrote:

> Andrew Poulos wrote:
> 
> > On 27/01/2014 2:25 PM, Xox wrote:
> >> Let us suppose I have a page, a.html, which contains a script which
> >> constantly invokes itself or is invoked -- it's running not necessarily
> >> continuously but at regular intervals, or maybe it is looping.
> 
> There are no pages, they are not “running”, and they certainly do not 
> “loop”.  Scripts do not “invoke themselves” either.
> 
> Script code may cause other code to be executed repeatedly, using the 
> browser API, and it may cause a resource in a view to be reloaded, upon 
> which it could be executed again if it was part of that resource.  That
> is not a loop.

Yet more sneering by PointyHead at people's "incorrect" use of
terminology. Still, I expect it's how he's used to treating his
students, if any.

> > Perhaps calling onunload and/or onbeforeunload and stopping the script
> > will help.
> 
> “onunload” and “onbeforeunload” are event-handler attributes and properties.  
> They cannot be called by the developer to the desired effect because the 
> developer does not know when they should call them in the first place.
> 
> There is an unfortunate tendency of saying that something is “called” when 
> any action is caused by anything, particularly among beginners.  People 
> nonsensically speak of “Ajax calls”, for example.

  var request = new XMLHttpRequest ();
  ...
  request.send (data);

Hmmm, looks like a function call to me.

If PointyHead were less of an arsehole, he might have simply reassured
the OP by describing what happens to a page being displayed, and its
resources, when the user navigates to another page. IOW, behaved like a
good teacher. But no. Instead, he feels an irresistible urge to demean
posters by making corrections to their usage of terminology, and their
manner of posting.

-- 
"The idea that Bill Gates has appeared like a knight in shining armour to
 lead all customers out of a mire of technological chaos neatly ignores 
 the fact that it was he who, by peddling second-rate technology, led them
 into it in the first place."                             - Douglas Adams

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

#22825

On Mon, 27 Jan 2014 10:41:24 +0000, Tim Streater wrote:

> In article <6507961.N3xZG9CObR@PointedEars.de>, Thomas 'PointedEars'
> Lahn <PointedEars@web.de> wrote:
> 
>> Andrew Poulos wrote:
>> 
>> > On 27/01/2014 2:25 PM, Xox wrote:
>> >> Let us suppose I have a page, a.html, which contains a script which
>> >> constantly invokes itself or is invoked -- it's running not
>> >> necessarily continuously but at regular intervals, or maybe it is
>> >> looping.
>> 
>> There are no pages, they are not “running”, and they certainly do not
>> “loop”.  Scripts do not “invoke themselves” either.
>> 
>> Script code may cause other code to be executed repeatedly, using the
>> browser API, and it may cause a resource in a view to be reloaded, upon
>> which it could be executed again if it was part of that resource.  That
>> is not a loop.
> 
> Yet more sneering by PointyHead at people's "incorrect" use of
> terminology. Still, I expect it's how he's used to treating his
> students, if any.
> 
>> > Perhaps calling onunload and/or onbeforeunload and stopping the
>> > script will help.
>> 
>> “onunload” and “onbeforeunload” are event-handler attributes and
>> properties.
>> They cannot be called by the developer to the desired effect because
>> the developer does not know when they should call them in the first
>> place.
>> 
>> There is an unfortunate tendency of saying that something is “called”
>> when any action is caused by anything, particularly among beginners. 
>> People nonsensically speak of “Ajax calls”, for example.
> 
>   var request = new XMLHttpRequest ();
>   ...
>   request.send (data);
> 
> Hmmm, looks like a function call to me.
> 
> If PointyHead were less of an arsehole, he might have simply reassured
> the OP by describing what happens to a page being displayed, and its
> resources, when the user navigates to another page. IOW, behaved like a
> good teacher. But no. Instead, he feels an irresistible urge to demean
> posters by making corrections to their usage of terminology, and their
> manner of posting.

I am sorry my vocabulary offended.  (Although I don't know
what the statelessness of HTTP has to do with anything.)  I
will explain in another way.  I have a page which has some
Javascript functions on/in it.  Some of the functions are
repeatedly called/started/invoked/run by setInterval or setTimeout.
They look to see whether certain objects etc. are present and
where they are, and may move or create other objects accordingly.
There could be a lot of these objects.  The functions could 
thus consume a lot of resources.

Now suppose the browser navigates to another page.  I am
wondering whether some browsers may continue to execute the 
aforesaid function invocations anyway.  I would think not, but 
stranger things have been coded.

I could make a list of the ids returned by setInterval
and run clearInterval against each on the onunload event,
but I'd just as soon not bother if it's superfluous.

Does anyone know?

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

#22826

Xox <etacx18@etaoin.com> wrote on 27 jan 2014 in comp.lang.javascript:

> Now suppose the browser navigates to another page.  I am
> wondering whether some browsers may continue to execute the 
> aforesaid function invocations anyway.  I would think not, but 
> stranger things have been coded.
> 
> I could make a list of the ids returned by setInterval
> and run clearInterval against each on the onunload event,
> but I'd just as soon not bother if it's superfluous.

What nonsense.

Why do you bother us,
if you do don't bother if it's superfluous?

You could defend homeopathy with the same words.

1 There is no evidence that does.

2 There is no logical reason why it should.

3 It could be easily tested if you wanted to do that,
as you are afraid of cpu consumption. Well you can measure that.

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

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

#22828

On Mon, 27 Jan 2014 20:53:02 +0100, Evertjan. wrote:

> Xox <etacx18@etaoin.com> wrote on 27 jan 2014 in comp.lang.javascript:
> 
>> Now suppose the browser navigates to another page.  I am wondering
>> whether some browsers may continue to execute the aforesaid function
>> invocations anyway.  I would think not, but stranger things have been
>> coded.
>> 
>> I could make a list of the ids returned by setInterval and run
>> clearInterval against each on the onunload event,
>> but I'd just as soon not bother if it's superfluous.
> 
> What nonsense.
> 
> Why do you bother us,
> if you do don't bother if it's superfluous?
> 
> You could defend homeopathy with the same words.
> 
> 1 There is no evidence that does.
> 
> 2 There is no logical reason why it should.
> 
> 3 It could be easily tested if you wanted to do that,
> as you are afraid of cpu consumption. Well you can measure that.

Yes, I can.  However, I don't run instances of all
contemporary browsers, and I thought someone might know
offhand because they knew more about how browsers are 
constructed than I do.  It is clear there are lots of
extremely knowledgeable people participating in this
newsgroup, to say nothing of their incisive wit.

I love the smell of napalm in the morning, too.

The fact that something is reasonable and logical is no
guarantee that people have done things that way.  My
very humble advice is not to make this assumption in any
kind of computer programming, systems design, or
engineering, at least not if they can come after you
when your stuff doesn't work.

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

#22832

Xox wrote:
^^^
Please fix this.

> I am sorry my vocabulary offended.

ACK.

> (Although I don't know what the statelessness of HTTP has to do with
> anything.)

You told of “pages”, meaning documents, being “active”, which is utter 
nonsense with a stateless protocol.  The document resource is served, i.e. 
transferred from the server to the client, and that is it.  Only a client-
side *script* can be “active”, i.e. running.

> I will explain in another way.  I have a page which has some

You do not have a page, you have a document.

> Javascript functions on/in it.

There is no “Javascript”, but, for the sake of discussion, let us continue 
under the assumption that you wrote “JavaScript”, even though even that term 
is insufficient to describe the situation.

> Some of the functions are repeatedly called/started/invoked/run by
> setInterval or setTimeout.  They look to see whether certain objects etc.
> are present and where they are, and may move or create other objects
> accordingly. There could be a lot of these objects.  The functions could
> thus consume a lot of resources.
> 
> Now suppose the browser navigates to another page.

s/browser/user/
s/page/resource/

> I am wondering whether some browsers may continue to execute the
> aforesaid function invocations anyway.

Some do.

> I would think not,

Why?

> but stranger things have been coded.

Indeed.
 
> I could make a list of the ids returned by setInterval
> and run clearInterval against each on the onunload event,

Good idea.

> but I'd just as soon not bother if it's superfluous.

ACK.  (Some people with less understanding of English appear to have 
misunderstood you here.  Keep in mind that this is an international 
newsgroup, so it is best to avoid the more peculiar idioms of the
language in order not to be misunderstood.)
 
> Does anyone know?

Yes.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22833

Thomas 'PointedEars' Lahn wrote:

> Xox wrote:
>> I could make a list of the ids returned by setInterval
>> and run clearInterval against each on the onunload event,
> 
> Good idea.

... except that is _in_ _an_ _unload_ event _listener_.

<http://www.w3.org/TR/DOM-Level-3-Events>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22835

On Monday, January 27, 2014 6:20:22 PM UTC-6, Thomas 'PointedEars' Lahn wrote:
> Keep in mind that this is an international 
> newsgroup, so it is best to avoid the more peculiar idioms of the
> language in order not to be misunderstood.)

This would have been a legitimate criticism to throw at me I'll admit. I am definitely guilty of using perfectly cromulent[1] words where something more appropriate could have been used. I'm glad you raised this issue

[1] https://en.wikipedia.org/wiki/Lisa_the_Iconoclast#Embiggen_and_cromulent

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

#22836

On Tue, 28 Jan 2014 01:20:22 +0100, Thomas 'PointedEars' Lahn wrote:

> Xox wrote:
> ^^^
> Please fix this.

What would you prefer?
 
>> I am sorry my vocabulary offended.
> 
> ACK.
> 
>> (Although I don't know what the statelessness of HTTP has to do with
>> anything.)
> 
> You told of “pages”, meaning documents, being “active”, which is utter
> nonsense with a stateless protocol.  The document resource is served,
> i.e. transferred from the server to the client, and that is it.  Only a
> client-
> side *script* can be “active”, i.e. running.

What I meant, of course, is that the 'page' is
present and visible in the browser and that the
scripts are (possibly) running, regardless of how
it got there, via HTTP or reading a file.  It's a 
little metonymy, like 'a hot cup of coffee' -- actually, 
the cup is not made of hot coffee, it's just the 
container.  Actually the page/document is not
active, but it contains material which is being
displayed and script which are running, maybe.
 
>> I will explain in another way.  I have a page which has some

> You do not have a page, you have a document.

Well, actually, I wrote a 'page' of code, which
implies a document, but when I wrote it, it was a
page, that is, an HTML file, which happened to include 
scripts.  That gets turned into a document when it is 
read and interpreted, but it was not a document in 
the sense I think we are using this word when I wrote
it.

> 
>> Javascript functions on/in it.
> 
> There is no “Javascript”, but, for the sake of discussion, let us
> continue under the assumption that you wrote “JavaScript”, even though
> even that term is insufficient to describe the situation.

Out of curiosity, I wonder what you would prefer.
I thought I was writing Javascript, I used grammar
widely attributed to Javascript, and hence I 
wrote my question in a newsgroup called, of all
things, comp.lang.javascript, where we are having
this discussion, so you can see how I might have
gotten that impression.
 
>> Some of the functions are repeatedly called/started/invoked/run by
>> setInterval or setTimeout.  They look to see whether certain objects
>> etc.
>> are present and where they are, and may move or create other objects
>> accordingly. There could be a lot of these objects.  The functions
>> could thus consume a lot of resources.
>> 
>> Now suppose the browser navigates to another page.
> 
> s/browser/user/
> s/page/resource/
> 
>> I am wondering whether some browsers may continue to execute the
>> aforesaid function invocations anyway.
> 
> Some do.
> 
>> I would think not,
> 
> Why?

I may be showing my age, but back in the day, if you
didn't need a resource, you got rid of it -- you freed
memory, and stopped processes/threads/tasks/transactions
that were no longer useful (in this case, to affect what
the user sees/hears etc.)  Conceded, you might keep the
material around if you thought it could be revisited in
the near future.  But indefinite retention of the resources
seems likely to bog down the supporting platform.

But maybe nobody cares any more.  I read somewhere that
Firefox kept allocated memory around indefinitely until
the process(es) terminated.  Like all day or all week, if
the user didn't quit.

>> but stranger things have been coded.
> 
> Indeed.
>  
>> I could make a list of the ids returned by setInterval and run
>> clearInterval against each on the onunload event,
> 
> Good idea.
> 
>> but I'd just as soon not bother if it's superfluous.
> 
> ACK.  (Some people with less understanding of English appear to have
> misunderstood you here.  Keep in mind that this is an international
> newsgroup, so it is best to avoid the more peculiar idioms of the
> language in order not to be misunderstood.)
>  
>> Does anyone know?
> 
> Yes.

It looks like you have given the answer I was looking
for, although it's not what I wanted to hear.  So it
goes.

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

#22839

Xox wrote:

> On Tue, 28 Jan 2014 01:20:22 +0100, Thomas 'PointedEars' Lahn wrote: 
>> Xox wrote:
>> ^^^
>> Please fix this.
> 
> What would you prefer?

Your real name, of course.  You may insert your nickname as well, though.  
See my From header field value for an example.
  
>>> I will explain in another way.  I have a page which has some
>> 
>> You do not have a page, you have a document.
> 
> Well, actually, I wrote a 'page' of code,

Actually, you did not.  You wrote a file that contained, or maybe a program 
that generated, a document.  There is no page unless you print it out.  But 
the advantage of HTML, and the Web in general, is that presentation of 
content depends on the medium of presentation.

> which implies a document,

Hypertext resources on the Web, especially HTML resources, are called 
documents.

<http://www.w3.org/TR/html4>
<http://www.w3.org/TR/html5>

This use originates from the beginnings of the World Wide Web, at CERN:

<http://www.w3.org/History/1989/proposal.html>

> but when I wrote it, it was a page, that is, an HTML file,

You are using terminology that is not well-defined.  Such leads to confusion 
and is to be avoided.

> which happened to include scripts.  That gets turned into a document when-
> it is read and interpreted,

No, before.

> but it was not a document in the sense I think we are using this word when
> I wrote it.

See above.
 
>>> Javascript functions on/in it.
>> 
>> There is no “Javascript”, but, for the sake of discussion, let us
>> continue under the assumption that you wrote “JavaScript”, even though
>> even that term is insufficient to describe the situation.
> 
> Out of curiosity, I wonder what you would prefer.
> I thought I was writing Javascript, I used grammar
> widely attributed to Javascript, and hence I
> wrote my question in a newsgroup called, of all
> things, comp.lang.javascript, where we are having
> this discussion, so you can see how I might have
> gotten that impression.

First of all, you are using wrong spelling, in particular wrong character 
case.  Second, “JavaScript” is only the name of one ECMAScript 
implementation used in browsers; one of many.  Read the ECMAScript Support 
Matrix for details.

I would prefer “functions written in/for an ECMAScript implementation” of 
course, but I can see that this may not be practical.  Thus, since we are 
already discussing in comp.lang.javascript, we can make use of the context, 
drop the superfluous attributes altogether, and just say “functions”.  The 
dedicated reader will then be able to infer from the context that what we 
meant were entities that are described exactly using the words in the first 
sentence of this paragraph.
  
>>> I would think not,
>> 
>> Why?
> 
> I may be showing my age, but back in the day, if you
> didn't need a resource, you got rid of it -- you freed
> memory, and stopped processes/threads/tasks/transactions
> that were no longer useful (in this case, to affect what
> the user sees/hears etc.)  Conceded, you might keep the
> material around if you thought it could be revisited in
> the near future.  But indefinite retention of the resources
> seems likely to bog down the supporting platform.
> 
> But maybe nobody cares any more.  I read somewhere that
> Firefox kept allocated memory around indefinitely until
> the process(es) terminated.  Like all day or all week, if
> the user didn't quit.

You are still proceeding from the false, but common, assumption that window 
and document were the same entity, or even represented by the same object.  
(In part, the original design of JavaScript[tm] is to blame for that.) 

Instead, it is quite possible that code executed by window.setTimeout() or 
window.setInterval() does not have anything to do with the document resource 
that is displayed in one of the window's views (which is represented by the 
“document” property).

So what logical reason could there be not to continue executing it when that 
document resource is being navigated away from, unless the author of the 
document explicitly said so?

> It looks like you have given the answer I was looking
> for, although it's not what I wanted to hear.  So it
> goes.

A polite person would have said “thank you” at this point anyway.

And trimmed their quotes before.

<http://PointedEars.de/faq#posting> pp.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22857

On Tue, 28 Jan 2014 01:20:22 +0100, Thomas 'PointedEars' Lahn wrote:
>>> Xox wrote:
>>> ^^^
>>> Please fix this.

Xox: 
>> What would you prefer?

On Tue, 28 Jan 2014 11:33:33 +0100, Thomas 'PointedEars' Lahn wrote: 
> Your real name, of course.  You may insert your nickname as well,
> though.
> See my From header field value for an example.

Any name is a 'real' name.  You probably means something
like a legal, street, or business name.

Several years ago, I got tired of receiving death threats
and promises of lawsuits because of completely rational,
innocent items I had posted or referred to on Usenet and
elsewhere.  It occurred to me then that some lunatic or 
criminal could just look me up in the phone book and pay
a visit.  Indeed, I actually had people come to my place 
of business, although not to kill me but to try to sell 
me something.  Since then, I've used pseudonyms.  However,
I'll keep your preference in mind should I revisit this
newsgroup in the future.  It will be a special thing between
me and comp.lang.javascript, dependent, of course, on your
not issuing any death threats.  

  
[ argument about terminology not worth pursuing ]

>>>> Javascript functions on/in it.
>>> 
>>> There is no “Javascript”, but, for the sake of discussion, let us
>>> continue under the assumption that you wrote “JavaScript”, even though
>>> even that term is insufficient to describe the situation.
>> 
>> Out of curiosity, I wonder what you would prefer.
>> I thought I was writing Javascript, I used grammar widely attributed to
>> Javascript, and hence I wrote my question in a newsgroup called, of all
>> things, comp.lang.javascript, where we are having this discussion, so
>> you can see how I might have gotten that impression.
> 
> First of all, you are using wrong spelling, in particular wrong
> character case.  Second, “JavaScript” is only the name of one ECMAScript
> implementation used in browsers; one of many.  Read the ECMAScript
> Support Matrix for details.
> 
> I would prefer “functions written in/for an ECMAScript implementation”
> of course, but I can see that this may not be practical.  Thus, since we
> are already discussing in comp.lang.javascript, we can make use of the
> context, drop the superfluous attributes altogether, and just say
> “functions”.  The dedicated reader will then be able to infer from the
> context that what we meant were entities that are described exactly
> using the words in the first sentence of this paragraph.

On a stylistic note, I find internal capitalization
rather twee when writing in natural language, but again,
I will defer to local usage.

In the matter of the names of scripts, at one time I
was much vexed by the variety of interpreters, versions,
DOMs, etc., with which I am sure you are familiar.  For
all I know, this browser or that may include many
interpreters which behave differently from each other
even in the same browser, and of course from all the 
others in different browsers, platforms, etc. etc. etc.  
Saying 'JavaScript' approximated my particular area of 
interest in this case, that is, what I get if I write
'<script type="text/javascript">' in an HTML file.  If
that is really an ECMAScript interpreter, so be it.

   
[ on whether scripts could be expected to keep running ]

>> I may be showing my age, but back in the day, if you didn't need a
>> resource, you got rid of it -- you freed memory, and stopped
>> processes/threads/tasks/transactions that were no longer useful (in
>> this case, to affect what the user sees/hears etc.)  Conceded, you
>> might keep the material around if you thought it could be revisited in
>> the near future.  But indefinite retention of the resources seems
>> likely to bog down the supporting platform.
>> 
>> But maybe nobody cares any more.  I read somewhere that Firefox kept
>> allocated memory around indefinitely until the process(es) terminated. 
>> Like all day or all week, if the user didn't quit.
> 
> You are still proceeding from the false, but common, assumption that
> window and document were the same entity, or even represented by the
> same object. (In part, the original design of JavaScript[tm] is to blame
> for that.)
> 
> Instead, it is quite possible that code executed by window.setTimeout()
> or window.setInterval() does not have anything to do with the document
> resource that is displayed in one of the window's views (which is
> represented by the “document” property).
> 
> So what logical reason could there be not to continue executing it when
> that document resource is being navigated away from, unless the author
> of the document explicitly said so?

To me the contents of the window are a projection of the
document.

The fact that the document is being navigated away from,
so it is no longer 'active' in the metonymous sense in
which I used the word previously, should, I would think,
indicate to the browser that the function which was a part
of the document (according to your terminology, I think)
is no longer of interest.  Practically speaking, a user
could navigate through dozens of pages with hundreds of
functions/routines/methods and thousands of objects, 
which, if they were kept around indefinitely, would surely 
impede the performance of the platform and the browser and 
in addition might afford many opportunities for mischief 
(stuff running out of sight).  So, were I writing a
browser, I would stop anything where continued
execution was not explicitly requested, and I would tear
down the structures related to the document, maybe not
immediately, but pretty soon after it was no longer
'active' (again, my terminology).  But I don't write
browsers, so what do I know?

 
>> It looks like you have given the answer I was looking for, although
>> it's not what I wanted to hear.  So it goes.
> 
> A polite person would have said “thank you” at this point anyway.
> 
> And trimmed their quotes before.
> 
> <http://PointedEars.de/faq#posting> pp.

People complain when I trim the quotes ('you have deleted
my precious text') and when I don't.  But, anyway, you have 
my undying gratitude.

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

#22837

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 28 jan 2014 in 
comp.lang.javascript:

>> I am wondering whether some browsers may continue to execute the
>> aforesaid function invocations anyway.
> 
> Some do.

I doubt the mainstream modern browsers do. 
Please show me otherwise if some of you think it important.

It beats me [sorry PE] that you would include code that only applies to an 
infinitesimal part of your users, who possibly use windows 95 and Netscape 
0.8, a text-browser on a prehistoric unix-platform or perhaps a 8088 with 
256kb of RAM, precluding errorless execution of your present day Javascript 
[sorry PE] code and CSS anyway, and by their choice of platform would 
probably delight in showing off the waistfullness of modern clientside 
coding. 

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

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

#22827

Thomas 'PointedEars' Lahn wrote:

> Andrew Poulos wrote:
> 
>> On 27/01/2014 2:25 PM, Xox wrote:
>>> Now the viewer goes to an entirely different page using the same
>>> window/tab, so a.html has disappeared.
> 
> The resource has been navigated away from.  It is still existing, but is not 
> displayed anymore.
> 
>>> It seems reasonable to assume that the script would stop running. 
> 
> No, it is not.  Window and document are separate entities.
>
>>> But is this in fact known to be the case across all contemporary
>>> browsers?
> 
> No, it never was.

According to the HTML5 CR "Unloading documents"[1]:

| If the Document's salvageable state is false, empty the Document's
| Window's list of active timers.

Apparently you claim that there are or have been browsers that didn't do
this.  Can you name them or otherwise elaborate a bit on the issue, please.

[1] <http://www.w3.org/TR/html5/browsers.html#unload-a-document>

-- 
Christoph M. Becker

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

#22829

Christoph Michael Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> On 27/01/2014 2:25 PM, Xox wrote:
>>>> It seems reasonable to assume that the script would stop running.
>> 
>> No, it is not.  Window and document are separate entities.
>>
>>>> But is this in fact known to be the case across all contemporary
>>>> browsers?
>> 
>> No, it never was.
> 
> According to the HTML5 CR "Unloading documents"[1]:
> 
> | If the Document's salvageable state is false, empty the Document's
> | Window's list of active timers.

Thanks, but I wouldn’t hold my breath for conforming implementations of 
HTML5.
 
> Apparently you claim that there are or have been browsers that didn't do
> this.

There have been some, at least.

> Can you name them or otherwise elaborate a bit on the issue, please.
                                                                     ^
Well, BTST (and no, I cannot remember exactly¹), so I prefer to call 
window.clearInterval()/clearTimeout onunload at the latest.  Better safe 
than sorry.
 
> [1] <http://www.w3.org/TR/html5/browsers.html#unload-a-document>

________
¹  Sorry, it has been 14 years of professional Web development, and
   about 16 years of ECMAScript-based Web programming in total now.
-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#22830

Thomas 'PointedEars' Lahn wrote:

> Christoph Michael Becker wrote:
>
>> According to the HTML5 CR "Unloading documents"[1]:
>>
>> | If the Document's salvageable state is false, empty the Document's
>> | Window's list of active timers.
> 
> Thanks, but I wouldn’t hold my breath for conforming implementations of 
> HTML5.

ACK.

>> Apparently you claim that there are or have been browsers that didn't do
>> this.
> 
> There have been some, at least.
> 
>> Can you name them or otherwise elaborate a bit on the issue, please.
>                                                                      ^
> Well, BTST (and no, I cannot remember exactly¹),

Fair enough.  I'm doing web development for less than three years only,
and that already happens to me.

>                                                   so I prefer to call 
> window.clearInterval()/clearTimeout onunload at the latest.  Better safe 
> than sorry.

ACK.  However, I'm trying to minimize the code I write resp. revise, and
prefer to avoid workarounds for unsupported browsers (for an appropriate
definition of "workaround" and "unsupported", suited for the project).
I'm afraid that otherwise the code might get unwieldy over time.

For this reason I greatly appreciate your efforts wrt. the ES matrix[2],
as well as caniuse[3] and PPK's quirksmode[4] and others, and I hope
that there'll be more of such invaluable resources in the future.

>> [1] <http://www.w3.org/TR/html5/browsers.html#unload-a-document>
> 
> ________
> ¹  Sorry, it has been 14 years of professional Web development, and
>    about 16 years of ECMAScript-based Web programming in total now.

[2] <http://pointedears.de/es-matrix>
[3] <http://caniuse.com/>
[4] <http://www.quirksmode.org/>

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

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

csiph-web