Pattern on delayed action

[Brian]

Hi all... This question is more for the GURUs out there. It is not a
question on how to do something, but why it happens, and I am trying to
figure out if there is a pattern. I am using IE, but this pattern also
happens in Mozilla, but not always the same way... I am not as interested in
how the browsers are different, but the big question is: Is there a pattern
to what type of actions are delayed for after the scripts have finished, and
what type of actions happen instantly?

Here is a snippit, to start out the discussion:

alert(location.href)
location.href = "SOMEPLACE_NOT_HERE"
alert(location.href)

If you run this code, the alert message will respond with the same
answer...the current page. Even though the href string is set, the value is
delayed. It is not until the script block has finished that the location
changes, and the string value has changed.

Now, under the hood, I understand what is going on... The JavaScript engine
executes code on a DOM model, maintained by the browser. The JS engine
needs to finish before control is given back to the browser, to act on the
change. In the mean time, since the actual location has not changed,
reading the location.href stays the same.

Ok, moving on... Look at the following code:

function ButtonWasClicked ()
{
document.forms['form_id'].elements['text_id'].value = "WOOHOO";
document.forms['form_id'].submit();
document.forms['form_id'].elements['text_id'].value = "BLUBBER";
alert(document.forms['form_id'].elements['text_id'].value
}

This code will also wait until the script has ended to run submit, so the
alert will show "BLUBBER"... BUT, the actual submission will be of "WOOHOO".

Lets replace the alert with another submit:

function ButtonWasClicked ()
{
document.forms['form_id'].elements['text_id'].value = "WOOHOO";
document.forms['form_id'].submit();
document.forms['form_id'].elements['text_id'].value = "BLUBBER";
document.forms['form_id'].submit();
}

In this case, only ONE of the submits had occurred... I did a scan of the
HTTP traffic to verify that this was the case. In IE, BLUBBER is sent, and
in Mozilla, WOOHOO is sent to the form handler.

I hope this makes sense... I can elaborate more if necessary.

Thanks,
Brian

 

[VK]

You are exploring the twilight zone of so called "orphan" scripts.

In theory any inline client-side script (JavaScript, JScript, VBScript)
exists only within the "parenting" page and goes away with that page.
Thus statements like "self.document.location.href=x",
"self.document.write()" and so suppose to be the last bullet in your
(script) temple: "do it and die".

On practice, to improve the performance, each script interpreter has a
cash for currently executing code with rather complicated "advance
reading" mechanics. As a result, the script may stay alive even after
the parenting page is "passed away". When, how and in what consequence
the leftovers will be executed and destroyed, depends on the script cash
programming of the current browser and on the current air pressure in
Panama City, FL

IMHO making and using orphan scripts is a bad programming practice. Try
to avoid it.

 

[Brian]

You are exploring the twilight zone of so called "orphan" scripts.

In theory any inline client-side script (JavaScript, JScript, VBScript)
exists only within the "parenting" page and goes away with that page.
Thus statements like "self.document.location.href=x",
"self.document.write()" and so suppose to be the last bullet in your
(script) temple: "do it and die".

On practice, to improve the performance, each script interpreter has a
cash for currently executing code with rather complicated "advance
reading" mechanics. As a result, the script may stay alive even after
the parenting page is "passed away". When, how and in what consequence
the leftovers will be executed and destroyed, depends on the script cash
programming of the current browser and on the current air pressure in
Panama City, FL

IMHO making and using orphan scripts is a bad programming practice. Try
to avoid it.

Thanks for the info... unfortuantely, in the context of the question, I am
not a scripter, but a browser developer. I am trying to make decisions in
my interpreter that closely mimic the popular browsers. Because of this,
the advice to not use orphan scripts doesnt work for me, because people
might do it, and expect it to work since it works in the other browsers, and
I need to act accordingly.

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

B

 

[Lee]

Brian said:

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

You must be at the very early stages of beginning to think
about planning to develop a browser if this isn't obvious.

Tasks that are completely within the control of the browser
happen immediately. Tasks that are delegated to the operating
system or to the server happen asynchronously.

 

[Brian]

Brian said:

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

You must be at the very early stages of beginning to think
about planning to develop a browser if this isn't obvious.

Tasks that are completely within the control of the browser
happen immediately. Tasks that are delegated to the operating
system or to the server happen asynchronously.

No need to be condecending... I am well past the planning stages... The
reason it is not obvious, is because the browsers (IE and Mozilla) do these
things differently. For the most part, what you said makes sense, but there
is a level of caching that happens of the values that is not making sense.

For instance, when you change location.href, the JS engine is attached to
the DOM, and it is very easy to make that change immediately. In fact, it
is harder to delay the change. I have already implemented my location
object to work with the delay (like IE), and it works fine... I am just
getting confused to know exactly which values are set immediately, which are
cached.

Brian

 

[Lee]

Brian said:

Brian said:

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

You must be at the very early stages of beginning to think
about planning to develop a browser if this isn't obvious.

Tasks that are completely within the control of the browser
happen immediately. Tasks that are delegated to the operating
system or to the server happen asynchronously.

No need to be condecending... I am well past the planning stages... The
reason it is not obvious, is because the browsers (IE and Mozilla) do these
things differently. For the most part, what you said makes sense, but there
is a level of caching that happens of the values that is not making sense.

For instance, when you change location.href, the JS engine is attached to
the DOM, and it is very easy to make that change immediately. In fact, it
is harder to delay the change. I have already implemented my location
object to work with the delay (like IE), and it works fine... I am just
getting confused to know exactly which values are set immediately, which are
cached.

You don't seem to be modeling it correctly.
Writing to and reading from the Location object are not like similar
actions on a custom Object. When you you assign a value to the href
attribute, a complete URL is determined and a page load is initiated.
When you read the value of the href attribute, you get a reflection
of the URL of the currently loaded page. It doesn't just fetch the
value that was assigned.

 

[VK]

1. "delay with location.href"
document.location.href is really not a property (despite it's stated and
it looks like one), but a method. Moreover, this is a system peer
method. By setting href, you are peering to the internal browser code to
get the indicated resource (emulation of <address>+<Enter> input in the
address bar).
By requesting href, your are peering again, and you are getting the
system value of the page your browser considers to be current. And most
of browsers follow the rule "don't drop the old until the new came", so
they keep the old href value until the requested page fires onload
event. (Because it also can be an error or a redirection on the go).

2. Globally I don't think you can emulate the EXACT script engine
behavior w/o complete reverse engineering of this engine.

3. If you still want to play with orphan scripts, check the behaviour:
a) inline script vs. filed script (<script>...</script> vs. <script
src=..></script>)
b) A construct used one-two times before the script's "suicide" and a
construct being in intensive use before the "suicide". This alone will
keep you buzy for a couple of weeks. Also "Interference of runtime code
optimization and orphaned scripts" would sound good enough for a
master's degree

 

[Grant Wagner]

Brian said:

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

You must be at the very early stages of beginning to think
about planning to develop a browser if this isn't obvious.

Tasks that are completely within the control of the browser
happen immediately. Tasks that are delegated to the operating
system or to the server happen asynchronously.

In all fairness, I think the pattern isn't quite so clear cut. Take for
example:

<img src="image1.jpg" name="test" />
<script type="text/javascript">
document.images['test'].src = 'image2.jpg';
alert(document.images['test'].src);
</script>

If it were true that the image had to be loaded from the server before you'd
see the result in client-side script, the above would alert "image1.jpg", but
it does not. In every browser I tested (Netscape 4.78, Firebird 0.7, IE6SP1
and Opera 7.23), it alerted "image2.jpg", regardless of whether the image had
actually completed loading successfully. In fact, in some cases, I specified
document.image['test'].src = 'file.pdf'; and client-side JavaScript alerted
"file.pdf", even when it's obvious that image object could never successfully
load the file.

On the other hand:

<script type="text/javascript">
window.location.href = 'http://www.yahoo.com';
alert(window.location.href);
</script>

Always alerts the page you're on.

That said, I think it's pretty clear that the location object is "special" in
many ways (not the least of which is that you can assign location =
'something'; and it magically assigns the value to the href property). The way
I'd view it is that window.location.href is a "request message" for the
location object to navigate to a new page, not an assignment (and as such
should probably have been a method, not a property). In other words, think of
href as a read-only property, and any assignment to it (or the location object
itself) as an invocation of a method:

<script type="text/javascript">
window.location.navigateTo('http://www.yahoo.com'); // fictional method
invocation
alert(window.location.href);
</script>

Now it's clear why href isn't set to what you might think it should be,
because it isn't set by the object until navigateTo() has completed
successfully.

document.images[].src on the other hand, is both the GET request and an
assignment to the property.

--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html

 

[Lasse Reichstein Nielsen]

In all fairness, I think the pattern isn't quite so clear cut. Take for
example:

<img src="image1.jpg" name="test" />
<script type="text/javascript">
document.images['test'].src = 'image2.jpg';
alert(document.images['test'].src);
</script>

If it were true that the image had to be loaded from the server before you'd
see the result in client-side script, the above would alert "image1.jpg", but
it does not.

No it shouldn't, it should alert "image2.jpg" (possibly expanded to a
full URL). You make an assignment, and that takes effect immediately,
as any other assignment to a property value. What is delayed is the
effect of that assignment on the image shown. With the next refresh,
the old image is gone, but the new image doesn't appear until it has
been loaded.

In every browser I tested (Netscape 4.78, Firebird 0.7, IE6SP1
and Opera 7.23), it alerted "image2.jpg", regardless of whether the image had
actually completed loading successfully.

It should.

On the other hand: ....
window.location.href = 'http://www.yahoo.com';
alert(window.location.href); ....
Always alerts the page you're on.

That said, I think it's pretty clear that the location object is "special" in
many ways ....

In other words, think of href as a read-only property, and any
assignment to it (or the location object itself) as an invocation of
a method: ....
window.location.navigateTo('http://www.yahoo.com'); // fictional method
invocation

Agree completely.

Now it's clear why href isn't set to what you might think it should be,
because it isn't set by the object until navigateTo() has completed
successfully.

And then it is actually a different location object on a different page.

document.images[].src on the other hand, is both the GET request and an
assignment to the property.

Yes. The assignment is insantaneous. The GET takes time (and will eventually
trigger the image's onload handler).

/L

 

[Brian]

Brian said:

Brian said:

What I am looking for, is to see if there are any patterns with what is
executed instantly, and what is not... I know that location.href is not
changed instantly, but forms[0].elements[0].value is changed the moment I
set it. What is the pattern? Has anyone noticed one?

You must be at the very early stages of beginning to think
about planning to develop a browser if this isn't obvious.

Tasks that are completely within the control of the browser
happen immediately. Tasks that are delegated to the operating
system or to the server happen asynchronously.

No need to be condecending... I am well past the planning stages... The
reason it is not obvious, is because the browsers (IE and Mozilla) do these
things differently. For the most part, what you said makes sense, but there
is a level of caching that happens of the values that is not making sense.

For instance, when you change location.href, the JS engine is attached to
the DOM, and it is very easy to make that change immediately. In fact, it
is harder to delay the change. I have already implemented my location
object to work with the delay (like IE), and it works fine... I am just
getting confused to know exactly which values are set immediately, which are
cached.

You don't seem to be modeling it correctly.
Writing to and reading from the Location object are not like similar
actions on a custom Object. When you you assign a value to the href
attribute, a complete URL is determined and a page load is initiated.
When you read the value of the href attribute, you get a reflection
of the URL of the currently loaded page. It doesn't just fetch the
value that was assigned.

Yes, that is how I have implemented it.
B

 

[Brian]

In all fairness, I think the pattern isn't quite so clear cut. Take for
example:

<img src="image1.jpg" name="test" />
<script type="text/javascript">
document.images['test'].src = 'image2.jpg';
alert(document.images['test'].src);
</script>

If it were true that the image had to be loaded from the server before you'd
see the result in client-side script, the above would alert "image1.jpg", but
it does not.

No it shouldn't, it should alert "image2.jpg" (possibly expanded to a
full URL). You make an assignment, and that takes effect immediately,
as any other assignment to a property value. What is delayed is the
effect of that assignment on the image shown. With the next refresh,
the old image is gone, but the new image doesn't appear until it has
been loaded.

In every browser I tested (Netscape 4.78, Firebird 0.7, IE6SP1
and Opera 7.23), it alerted "image2.jpg", regardless of whether the image had
actually completed loading successfully.

It should.

On the other hand: ...
window.location.href = 'http://www.yahoo.com';
alert(window.location.href); ...
Always alerts the page you're on.

That said, I think it's pretty clear that the location object is "special" in
many ways ...

In other words, think of href as a read-only property, and any
assignment to it (or the location object itself) as an invocation of
a method: ...
window.location.navigateTo('http://www.yahoo.com'); // fictional method
invocation

Agree completely.

Now it's clear why href isn't set to what you might think it should be,
because it isn't set by the object until navigateTo() has completed
successfully.

And then it is actually a different location object on a different page.

document.images[].src on the other hand, is both the GET request and an
assignment to the property.

Yes. The assignment is insantaneous. The GET takes time (and will eventually
trigger the image's onload handler).

/L

'Faith without judgement merely degrades the spirit divine.'

Ok, with that said, what is known about the form.submit() method?

document.forms['myform'].elements['mytext'].value = "Something1";
document.forms['myform'].submit();
document.forms['myform'].elements['mytext'].value = "Something2";
document.forms['myform'].submit();

What happens if you call form.submit() twice? In IE, the form handler will
get Something2, but in Mozilla, it will get Something1. If you take away
the second submit in IE, the form handler will get Something1, even though
Something2 was set before the script block ended. In any case, there is
only one HTTP request being made.

(IE) It is almost as if the submit is captured as a flag is set for when the
script block has ended, and a snapshot of the elements was taken. When the
second submit is called, the same thing happens, so any changes to elements
after that moment are not actually sent. Actually, it is probably more
likely that the URL including the search portion of the path is built up,
and stored every time submit() is called. When the script block returns to
the browser, the string is checked... if it is not empty, a GET or POST is
made and the string is cleared.

In Mozilla, I guess it likely does something similar, except that when the
second submit occurs, it recognizes that the new URL string is set, and
refuses to do anything.

Just a thought,
Brian

 

[Thomas 'PointedEars' Lahn]

document.location.href is really not a property (despite
it's stated and it looks like one), but a method.

No, it is a property which has setter/getter methods assigned to it.


PointedEars

 

[VK]

document.forms['myform'].elements['mytext'].value = "Something1";

document.forms['myform'].submit();
document.forms['myform'].elements['mytext'].value = "Something2";
document.forms['myform'].submit();

I'm affraid that the big picture is still escaping you. By the HTTP
protocol and scripting specs, the above code has no meanning starting
the 3rd line. It's as meaningless as a Java code like:
public int crazyMethod(int b, int c) {
int a = b + c;
Runtime.getRuntime().exit(a);
return(a);
}

or Perl code like:
$a = $b+$c;
exit($a);
doMyStuffWith($a);

or it's as absurde as sentence "He died and made a cup of coffee".

Yes, the system allows you to execute it and even receive some results
(for the reasons spelled before this posting).

You want to mimic it exactly (that was the reason of your first
posting)? You cannot.
You want to bring some order in the haos? An object's model *mainly* is
not available during the replacement of that object with another object.
The replacing object's model *mainly* is not available until that object
arrived safely and in one piece (onload event).

Hope this help.