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

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

XMLHttpRequest and Google Chrome

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

Contents

  XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-12 19:36 +0100
    Re: XMLHttpRequest and Google Chrome JJ <jj4public@vfemail.net> - 2015-04-13 12:33 +0700
      Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 07:41 +0100
    Re: XMLHttpRequest and Google Chrome Martin Honnen <mahotrash@yahoo.de> - 2015-04-13 11:30 +0200
      Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 11:50 +0100
        Re: XMLHttpRequest and Google Chrome Tim Streater <timstreater@greenbee.net> - 2015-04-13 13:17 +0100
          Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 13:34 +0100
            Re: XMLHttpRequest and Google Chrome Tim Streater <timstreater@greenbee.net> - 2015-04-13 14:26 +0100
            Re: XMLHttpRequest and Google Chrome Martin Honnen <mahotrash@yahoo.de> - 2015-04-13 16:15 +0200
              Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 16:03 +0100
                Re: XMLHttpRequest and Google Chrome Martin Honnen <mahotrash@yahoo.de> - 2015-04-13 19:26 +0200
                  Re: XMLHttpRequest and Google Chrome "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-13 20:23 +0200
            Re: XMLHttpRequest and Google Chrome Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-04-13 15:50 +0100
              Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 16:10 +0100
                Re: XMLHttpRequest and Google Chrome "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-13 17:46 +0200
                  Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 17:28 +0100
                    Re: XMLHttpRequest and Google Chrome "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-13 19:14 +0200
                    Re: XMLHttpRequest and Google Chrome Tim Streater <timstreater@greenbee.net> - 2015-04-13 18:29 +0100
                      Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 18:59 +0100
                        Re: XMLHttpRequest and Google Chrome "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-04-13 20:29 +0200
                        Re: XMLHttpRequest and Google Chrome Tim Streater <timstreater@greenbee.net> - 2015-04-13 19:34 +0100
                          Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 20:11 +0100
                        Re: XMLHttpRequest and Google Chrome "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-04-13 20:44 +0200
                          Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 20:21 +0100
                        Re: XMLHttpRequest and Google Chrome Denis McMahon <denismfmcmahon@gmail.com> - 2015-04-14 12:43 +0000
                          Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-14 14:50 +0100
                          Re: XMLHttpRequest and Google Chrome Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-14 22:51 +0200
                  Re: XMLHttpRequest and Google Chrome Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-04-13 22:28 +0200
    Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-13 19:23 +0100
      Re: XMLHttpRequest and Google Chrome Tim Streater <timstreater@greenbee.net> - 2015-04-13 19:38 +0100
    Re: XMLHttpRequest and Google Chrome "Leonardo Azpurua" <leonardo@exmvps.org> - 2015-04-13 17:36 -0430
    Re: XMLHttpRequest and Google Chrome Robbie Brown <rob@example.com> - 2015-04-14 11:35 +0100
    Re: XMLHttpRequest and Google Chrome Denis McMahon <denismfmcmahon@gmail.com> - 2015-04-14 11:37 +0000

Page 2 of 2 — ← Prev page 1 [2]

#27362

In article <mgh03o$3lk$1@dont-email.me>, Robbie Brown <rob@example.com>
wrote:

>On 13/04/15 18:29, Tim Streater wrote:

>OK, I did a test.
>
>In <head> I have
>
><script type="text/javascript">>
>    window.onload = getCart();
></script>
>
>In getCart() I put an alert as the first line
>
>(incidentally getCart() is in a file that is referenced thusly in <head>
><script type="text/javascript" src="/javascript/cart.js"></script>
>before the call obviously)
>
>alert("hello");
>
>when I load any page in Firefox (and occasionally in Chrome) I get 
>"hello" *before* the page is displayed

IOW before it is loaded.

>if I change <head>
>
><script type="text/javascript">
>    window.onload = getCart;
></script>
>
>The function doesn't get called, I get no "hello"
>This is the same in all my browsers. I have no idea why as you and 
>others say that getCart should work, it simply doesn't. I'm not making 
>it up, it doesn't execute, I'm not mistaken, so, obviously something is 
>still missing.

But this is the point. You don't want getCart to be executed when the
following code is encountered by the browser:

><script type="text/javascript">
>    window.onload = getCart;
></script>

That is too soon. The browser will likely not yet have seen and parsed
everything, or completed its tasks. The page, IOW, is not yet ready.
You want it to be executed *later*, when the page *is* ready (i.e.
loaded). What you are telling the browser with:

  window.onload = getCart; 

is: "Please note that getCart is the function I want to be run when the
onload is complete". If you say:

  window.onload = getCart ();

you are saying to the browser: "Please run getCart *now* and assign its
return result as the function to be run *later* when the onload is
complete". But as someone noted, getCart doesn't return anything
anyway.


Now - using:

  window.onload = getCart; 

is anything reported in any browser's error console?

-- 
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

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

#27365

On 13/04/15 19:34, Tim Streater wrote:
> In article <mgh03o$3lk$1@dont-email.me>, Robbie Brown <rob@example.com>
> wrote:
>
>> On 13/04/15 18:29, Tim Streater wrote:
>
>> OK, I did a test.
>>
>> In <head> I have
>>
>> <script type="text/javascript">>
>>    window.onload = getCart();
>> </script>
>>
>> In getCart() I put an alert as the first line
>>
>> (incidentally getCart() is in a file that is referenced thusly in <head>
>> <script type="text/javascript" src="/javascript/cart.js"></script>
>> before the call obviously)
>>
>> alert("hello");
>>
>> when I load any page in Firefox (and occasionally in Chrome) I get
>> "hello" *before* the page is displayed
>
> IOW before it is loaded.
>
>> if I change <head>
>>
>> <script type="text/javascript">
>>    window.onload = getCart;
>> </script>
>>
>> The function doesn't get called, I get no "hello"
>> This is the same in all my browsers. I have no idea why as you and
>> others say that getCart should work, it simply doesn't. I'm not making
>> it up, it doesn't execute, I'm not mistaken, so, obviously something
>> is still missing.
>
> But this is the point. You don't want getCart to be executed when the
> following code is encountered by the browser:
>
>> <script type="text/javascript">
>>    window.onload = getCart;
>> </script>
>
> That is too soon. The browser will likely not yet have seen and parsed
> everything, or completed its tasks. The page, IOW, is not yet ready.
> You want it to be executed *later*, when the page *is* ready (i.e.
> loaded). What you are telling the browser with:
>
>   window.onload = getCart;
> is: "Please note that getCart is the function I want to be run when the
> onload is complete". If you say:
>
>   window.onload = getCart ();
>
> you are saying to the browser: "Please run getCart *now* and assign its
> return result as the function to be run *later* when the onload is
> complete". But as someone noted, getCart doesn't return anything
> anyway.
>
>
> Now - using:
>
>   window.onload = getCart;
> is anything reported in any browser's error console?
>

Er, yes, I get an error from the google analytics stuff ...erk

Failed to load resource: the server responded with a status of 404 not 
found  http://www.google-analytics.com/analytics.js

but this happens regardless, yet analytics is obviously working because 
I can see the daily totals and live view works perfectly ... oh jeez, 
this is becoming a mess ... but no, apart from the apparent anomalous 
analytics error I get nothing


-- 
Not floundering ... just fishing

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

#27364

Robbie Brown <rob@example.com> wrote on 13 apr 2015 in comp.lang.javascript:

> The function doesn't get called, I get no "hello"

Try this [using: window.onload=myLoad;]:

========== test1.html ===========
<script type='text/javascript'>
	var test=0;
	function myLoad() {
	   alert(test);
	};
	window.onload=myLoad;
	test=1;
	alert(test);
	test=2;
	alert(test);
	test=3;
	document.write(7+'<br>');
</script>
4<br>
5<br>
==============================

and this [using: window.onload=myLoad();]:

========== test2.html ===========
<script type='text/javascript'>
	var test=0;
	function myLoad() {
	   alert(test);
	};
	window.onload=myLoad();
	test=1;
	alert(test);
	test=2;
	alert(test);
	test=3;
	document.write(7+'<br>');
</script>
4<br>
5<br>
==============================

and explain the difference to yourself.

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

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

#27366

On 13/04/15 19:44, Evertjan. wrote:
> Robbie Brown <rob@example.com> wrote on 13 apr 2015 in comp.lang.javascript:
>
>> The function doesn't get called, I get no "hello"
>
> Try this [using: window.onload=myLoad;]:
>
> ========== test1.html ===========
> <script type='text/javascript'>
> 	var test=0;
> 	function myLoad() {
> 	   alert(test);
> 	};
> 	window.onload=myLoad;
> 	test=1;
> 	alert(test);
> 	test=2;
> 	alert(test);
> 	test=3;
> 	document.write(7+'<br>');
> </script>
> 4<br>
> 5<br>
> ==============================
>
> and this [using: window.onload=myLoad();]:
>
> ========== test2.html ===========
> <script type='text/javascript'>
> 	var test=0;
> 	function myLoad() {
> 	   alert(test);
> 	};
> 	window.onload=myLoad();
> 	test=1;
> 	alert(test);
> 	test=2;
> 	alert(test);
> 	test=3;
> 	document.write(7+'<br>');
> </script>
> 4<br>
> 5<br>
> ==============================
>
> and explain the difference to yourself.
>

Will do, thanks


-- 
Not floundering ... just fishing

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

#27372

On Mon, 13 Apr 2015 18:59:13 +0100, Robbie Brown wrote:

> if I change <head>
> 
> <script type="text/javascript">
> 	window.onload = getCart;
> </script>
> 
> The function doesn't get called, I get no "hello"
> This is the same in all my browsers. I have no idea why as you and
> others say that getCart should work, it simply doesn't. I'm not making
> it up, it doesn't execute, I'm not mistaken, so, obviously something is
> still missing.
> 
> So it's back to the drawing board and javascript console.

What you're missing is the previously explained "getCart should be a 
reference to a function".

This code:

<script type="text/javascript">
	window.onload = getCart();
</script>

runs the getCart function as soon as the parser finds it, and stores the 
return value of getCart in the onload attribute of the window object. 
When the window finishes loading, it attempts to call the stored value as 
if it were a function, which does nothing because getCart doesn't return 
a function object.

This code:

<script type="text/javascript">
	window.onload = function() {getCart();};
</script>

stores a function that calls getCart() in the onload attribute of the 
window object. When the window finishes loading, it attempts to call the 
stored value as if it were a function, which works because what has been 
stored is actually a function.

This code:

<script type="text/javascript">
        var bing = function() {getCart();};
	window.onload = bing;
</script>

stores the function object in the variable named bing, and then stores 
bing in the onload attribute of the window object. When the window 
finishes loading, it attempts to call the stored value as if it were a 
function, which works because what has been stored is actually a function.

Now, let's test these. Working code at 

www.sined.co.uk/tmp/loadfunc1.htm

www.sined.co.uk/tmp/loadfunc2.htm

www.sined.co.uk/tmp/loadfunc3.htm 

Essentially they're all calling the getCart function, but the difference 
is in when they call it.

You should notice that the call with "1" happens before the page load 
completes, ie the alert box appears over a blank page background. The 
calls with 2 and 3 should appear after the page has loaded, ie with text 
and images in the background.

When you have a function that you wish to invoke during page loading, but 
which accesses the elements of the document dom that is being loaded, it 
is essential to defer the function call until after the document has 
finished loaded.

My "normal" method of doing this is to use the following:

<script type="text/javascript">
	window.onload = function() {pageLoaded();};
</script>

and then everything else I want to do is in my pageLoaded function.

Note that multiple calls to assign different functions to window.onload 
may not do as you expect, window.onload does not store a list of 
functions to execute, it stores a single value.

If you make the calls:

<script type="text/javascript">
	window.onload = function() {getCart();};
	window.onload = function() {pageLoaded();};
	window.onload = function() {init();};
</script>

then only the init() function will be called when the page has finished 
loading. Hence my preference for having one pageLoaded() function which 
does all the other work.

Hope this helps your understanding.

p.s. The elf will probably whine I'm wrong, but if the code examples I 
posted work for you then I suggest you ignore him. He just enjoys waving 
his e-wang around and pretending he knows best. LoNg LiVe ThE jAvAsCrIpT 
lIbErAtIoN fRoNt!

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#27373

On 14/04/15 13:43, Denis McMahon wrote:
> On Mon, 13 Apr 2015 18:59:13 +0100, Robbie Brown wrote:
>
>> if I change <head>
>>
>> <script type="text/javascript">
>> 	window.onload = getCart;
>> </script>
>>
>> The function doesn't get called, I get no "hello"
>> This is the same in all my browsers. I have no idea why as you and
>> others say that getCart should work, it simply doesn't. I'm not making
>> it up, it doesn't execute, I'm not mistaken, so, obviously something is
>> still missing.
>>
>> So it's back to the drawing board and javascript console.
>
> What you're missing is the previously explained "getCart should be a
> reference to a function".
>
> This code:
>
> <script type="text/javascript">
> 	window.onload = getCart();
> </script>
>
> runs the getCart function as soon as the parser finds it, and stores the
> return value of getCart in the onload attribute of the window object.
> When the window finishes loading, it attempts to call the stored value as
> if it were a function, which does nothing because getCart doesn't return
> a function object.
>
> This code:
>
> <script type="text/javascript">
> 	window.onload = function() {getCart();};
> </script>
>
> stores a function that calls getCart() in the onload attribute of the
> window object. When the window finishes loading, it attempts to call the
> stored value as if it were a function, which works because what has been
> stored is actually a function.
>
> This code:
>
> <script type="text/javascript">
>          var bing = function() {getCart();};
> 	window.onload = bing;
> </script>
>
> stores the function object in the variable named bing, and then stores
> bing in the onload attribute of the window object. When the window
> finishes loading, it attempts to call the stored value as if it were a
> function, which works because what has been stored is actually a function.

Yes, thanks, I've got this now.

I've spent my entire working life writing in compiled languages where 
calling a function or method always requires the use of parentheses. 
What I was missing is the exact semantics of window.onload, I do get it 
now, the light came on when I did this

<script>
    onload=foo;
    onload=bar;
</script>

and only bar was executed

(loud clunk as the penny dropped)

Hey, I thought, how about

<script>
    func baz(){
       foo();
       bar();
    }
</script>

This is much more familiar.

Now

<script>
    onload=baz;
</script>

Does the business

many thanks for your detailed description.

<snip>

Rob

-- 
Not floundering ... just fishing

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

#27374

Denis McMahon wrote:

> What you're missing is the previously explained "getCart should be a
> reference to a function".
> 
> This code:
> 
> <script type="text/javascript">
> window.onload = getCart();
> </script>
> 
> runs the getCart function as soon as the parser finds it,

No, it calls that function as soon as execution reaches that statement.  
Parsing always happens *before* execution in a computer program, in order to 
build an abstract syntax tree out of the source code.

> and stores the return value of getCart in the onload attribute of the 
> window object.

This is not Python.  It is a _property_, not an attribute.  Properties 
*have* attributes in ECMAScript implementations, as have elements in markup 
languages.

> When the window finishes loading, it attempts to call the stored value as
> if it were a function, which does nothing because getCart doesn't return
> a function object.

Worse, in some environments (such as MSHTML) it is possible that the code 
that would be executed after this statement is not executed because the 
“undefined” value is not a proper value for an event-handler property (a 
yellow triangle in the IE status bar would indicate that).  As others said 
before, either “null” or a reference to a Function instance is required.  
Failure to do so has caused a runtime error in said environments (I had that 
problem in particular, and reported on it here, when I switched the order of 
property assignments in my code.  That experience eventually lead me to 
change my approach of using closures towards one more similar to the module 
pattern, because that was less error-prone.)
 
> This code:
> 
> <script type="text/javascript">
> window.onload = function() {getCart();};
> </script>
> 
> stores a function that calls getCart() in the onload attribute of the
> window object. When the window finishes loading, it attempts to call the
> stored value as if it were a function, which works because what has been
> stored is actually a function.

What is stored in the property is a _reference_ to a Function instance, 
which is a callable object (implements the [[Call]] property).  The 
associated function is _not_ called by the window, but by browser code.

Proper, context-sensitive terminology is important to understand the 
underlying concepts.

> This code:
> 
> <script type="text/javascript">
>         var bing = function() {getCart();};
> window.onload = bing;
> </script>
> 
> stores the function object in the variable named bing, and then stores
> bing in the onload attribute of the window object. When the window
> finishes loading, it attempts to call the stored value as if it were a
> function, which works because what has been stored is actually a function.

There is no point in introducing a global variable here.
 
> p.s. The elf

My nickname has nothing to do with elves.

> will probably whine I'm wrong,

I am pointing out that you are wrong when you are wrong (which happens 
rather often), so that those statements of you that are wrong are not 
misleading other people as well.

> but if the code examples I posted work for you then I suggest you ignore 
> him. He just enjoys waving his e-wang around and pretending he knows best.

Spoken like a true wannabe.  You would be well-advised to shed your 
arrogance and ignorance, and *listen* to what people have to say that have 
considerably more experience in a field than you (and are still trying to 
teach you something despite your ongoing impudence).  For example, I have 
been dealing with these languages for more than 17 years now.  I wrote a 
thesis on it, and defended it successfully.  I am fortunate to have a great, 
well-paid job that requires a deep understanding of them and their 
applications.  And you?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#27367

Christoph M. Becker wrote:

> The onload property of the window element

s/element/object/

> is supposed to hold the reference to a Function object (or null).  This 
> function object is automatically called (with a single argument, namely 
> the respective Event object[1]) after the documented has been loaded.

s/documented/document/

Also, one must carefully consider what it means that “a document has been 
loaded”.  Historically, there has been an inconsistency among layout engines 
with regard to loading the image resources referred by a document, for 
example.

> […]
> [1] This argument isn't supplied in old versions of MSHTML.

… and in MSHTML 9+ when in a backwards-compatible browser mode.

In general, one should not write such code, but use a wrapper that only 
falls back to “.on…” in case .addEventListener() is not available, in a way 
that works like .addEventListener().

The disadvantage of the .on…  properties is that, if used directly, the code 
not only overwrites any event listener previously defined in *this* way, but 
today’s test in WebKit as of "Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36" 
shows that this can place the new event listener *after* all other listeners 
for the same event type.

This can be tested by example of the “click” event of the “body” element 
using

  document.body.onclick = function () { console.log(1337); };

  document.body.addEventListener("click",
    function () { console.log(42); }, 
    false);

  document.body.onclick = function () { console.log(23); };

and then clicking somewhere within the document body.  In the aforementioned 
environment, I get

  42
  23

which shows that the event listener is replaced *and* moved.

After a subsequent

  document.body.addEventListener("click",
    function () { console.log(1701); }, 
    false);

call, I get

  42
  23
  1701

when clicking, which shows that .addEventListener() preserves the listener 
order: the new listener comes not only after all listeners added with 
.addEventListener(), but all listeners for the same event no matter how they 
were added (including .onclick assignments).

If I repeat the second .onclick assignment, I get

  42
  1701
  23

when clicking.  So I must assume that this is the implemented behavior and 
cannot be attributed to an arbitrary order of calling the listeners.

[I have not checked the HTML5 Specification for this yet.  That 
.addEventListener() would preserve listener order was specified in DOM Level 
3 Events, and implemented so before HTML5, but that specification did not 
say anything about how .addEventListener() was supposed to work in 
combination with event-handler properties on element objects.]

That said, such considerations may not be relevant with certain other 
objects and event types.  It is then merely a matter of consistency in the 
application design.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#27360

On 12/04/15 19:36, Robbie Brown wrote:
>
>
> Chrome 41.0.2272.118
> Windows 8.1
>
> Chrome 41.0.2272.118
> Ubuntu 12.10
>
> Chrome 26.0.1410.43
> Ubuntu 12.04 LTS
>
> all 64bit
>
> I'm having a problem with asynch' javascript requests in the above
> versions of Chrome on the above platforms. The same code works fine in
> various versions of Firefox and Opera on the above platforms.
>
> The problem is worst on Ubu 12.10, not so bad but annoyingly frequent on
> Win 8.1 and hardly happens at all on Ubu 12.04 LTS
>
> Here's the admittedly old function I call to get an XMLHttpRequest object
>
> function newXMLHttpRequest() {
>
>    var xmlreq = false;
>
>    if (window.XMLHttpRequest) {
>      // Create XMLHttpRequest object in non-Microsoft browsers
>      xmlreq = new XMLHttpRequest();
>
>    }
>    else if (window.ActiveXObject) {
>      try {
>          xmlreq = new ActiveXObject("MSXML2.XMLHTTP.3.0");
>      }
>      catch(e){
>          try {
>            // Try to create XMLHttpRequest in later versions
>            // of Internet Explorer
>            xmlreq = new ActiveXObject("Msxml2.XMLHTTP");
>          }
>          catch (e1) {
>            // Failed to create required ActiveXObject
>            try {
>              // Try version supported by older versions
>              // of Internet Explorer
>              xmlreq = new ActiveXObject("Microsoft.XMLHTTP");
>            }
>            catch (e2) {
>
>              // Unable to create an XMLHttpRequest with ActiveX
>            }
>          }
>        }
>      }
>     return xmlreq;
> }
>
> and here's a function I call when a page is loaded
>
> function getCart(){
>      var req = newXMLHttpRequest();
>       req.onreadystatechange = getReadyStateHandler(req, updateCart);
>       req.open("POST", "common/ManageCart?cartmode=crtget", true);
>       req.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded");
>       req.send("");
> }
>
> updateCart uses javascript DOM to update the innerHTML property of a <div>
>
> The error in the Chrome javascript console is
>
> Uncaught TypeError: Cannot set property 'innerHTML' of null
>
> Like I say, it's only Chrome that has this problem frequently enough to
> be a problem
>
> Any ideas on what might be causing this problem in Chrome greatly
> appreciated
>
> Thanks
>
> Rob

I've been doing some tests and I noticed something interesting

I commented out all existing calls to getCart() and placed a call to the 
function just below the end of the relevant <div>

So now I have
<div id="cartsnapshot">
...
</div>
<script type="text/javascript">
    getCart();
</script>

Now, if I add an alert to getCart() the page loads until it gets to the 
point where the function is called, the alert fires and then loading 
continues, the element is available and the snapshot is updated, it 
seems to solve the problem and works fine in Firefox, Chrome and Opera.

What do you think of this approach

Thanks





-- 
Not floundering ... just fishing

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

#27363

In article <mgh1h1$agr$1@dont-email.me>, Robbie Brown <rob@example.com>
wrote:

>Now, if I add an alert to getCart() the page loads until it gets to the 
>point where the function is called, the alert fires and then loading 
>continues, the element is available and the snapshot is updated, it 
>seems to solve the problem and works fine in Firefox, Chrome and Opera.
>
>What do you think of this approach

It doesn't solve the problem, it just alters the timings so that it
works. Then along comes another browser or version of FF, Chrome, etc,
and its bust again.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

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

#27368

"Robbie Brown" <rob@example.com> escribió en el mensaje 
news:mgedt0$ki9$1@dont-email.me...
>
>
> Chrome 41.0.2272.118
> Windows 8.1
>
> Chrome 41.0.2272.118
> Ubuntu 12.10
>
> Chrome 26.0.1410.43
> Ubuntu 12.04 LTS
>
> all 64bit
>
>  [...snip...] function getCart(){
>     var req = newXMLHttpRequest();
>      req.onreadystatechange = getReadyStateHandler(req, updateCart);
>      req.open("POST", "common/ManageCart?cartmode=crtget", true);
>      req.setRequestHeader("Content-Type", 
> "application/x-www-form-urlencoded");
>      req.send("");
> }
>
> updateCart uses javascript DOM to update the innerHTML property of a <div>
>
> The error in the Chrome javascript console is
>
> Uncaught TypeError: Cannot set property 'innerHTML' of null
>
> Like I say, it's only Chrome that has this problem frequently enough to be 
> a problem
>
> Any ideas on what might be causing this problem in Chrome greatly 
> appreciated
>
> Thanks
>
> Rob

Hi,

I don't know if this might help (in fact, I am not sure whether what I say 
makes any sense at all), but usually you don't POST your parameters 
("cartmode=crtget") in the source URL (that is how GET works).

You might try replacing POST with GET (I've heard it might have weirds 
effects with caching), or else pass the arguments when you call send:

 function getCart() {
     var req = newXMLHttpRequest();
      req.onreadystatechange = getReadyStateHandler(req, updateCart);
      req.open("POST", "common/ManageCart", true);
      req.setRequestHeader("Content-Type", 
"application/x-www-form-urlencoded");
      req.send("cartmode=crtget");
 }

Perhaps other browsers HTTPRequest do some sort of trickery with the 
arguments which Chroe doesn't.


Good Luck.

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

#27370

On 12/04/15 19:36, Robbie Brown wrote:
>
>
> Chrome 41.0.2272.118
> Windows 8.1
>
> Chrome 41.0.2272.118
> Ubuntu 12.10
>
> Chrome 26.0.1410.43
> Ubuntu 12.04 LTS
>
> all 64bit
>
> I'm having a problem with asynch' javascript requests in the above
> versions of Chrome on the above platforms. The same code works fine in
> various versions of Firefox and Opera on the above platforms.
>
> The problem is worst on Ubu 12.10, not so bad but annoyingly frequent on
> Win 8.1 and hardly happens at all on Ubu 12.04 LTS
>
> Here's the admittedly old function I call to get an XMLHttpRequest object
>
> function newXMLHttpRequest() {
>
>    var xmlreq = false;
>
>    if (window.XMLHttpRequest) {
>      // Create XMLHttpRequest object in non-Microsoft browsers
>      xmlreq = new XMLHttpRequest();
>
>    }
>    else if (window.ActiveXObject) {
>      try {
>          xmlreq = new ActiveXObject("MSXML2.XMLHTTP.3.0");
>      }
>      catch(e){
>          try {
>            // Try to create XMLHttpRequest in later versions
>            // of Internet Explorer
>            xmlreq = new ActiveXObject("Msxml2.XMLHTTP");
>          }
>          catch (e1) {
>            // Failed to create required ActiveXObject
>            try {
>              // Try version supported by older versions
>              // of Internet Explorer
>              xmlreq = new ActiveXObject("Microsoft.XMLHTTP");
>            }
>            catch (e2) {
>
>              // Unable to create an XMLHttpRequest with ActiveX
>            }
>          }
>        }
>      }
>     return xmlreq;
> }
>
> and here's a function I call when a page is loaded
>
> function getCart(){
>      var req = newXMLHttpRequest();
>       req.onreadystatechange = getReadyStateHandler(req, updateCart);
>       req.open("POST", "common/ManageCart?cartmode=crtget", true);
>       req.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded");
>       req.send("");
> }
>
> updateCart uses javascript DOM to update the innerHTML property of a <div>
>
> The error in the Chrome javascript console is
>
> Uncaught TypeError: Cannot set property 'innerHTML' of null
>
> Like I say, it's only Chrome that has this problem frequently enough to
> be a problem
>
> Any ideas on what might be causing this problem in Chrome greatly
> appreciated
>
> Thanks
>
> Rob


Oh My, what a mistake ...

Firstly, thanks to everyone who took the time to respond, it's much 
appreciated.

As a reward I'll give you a good laugh

I have two areas that are dynamically updated
A cart snapshot and a compare list snapshot
at one point I had this in <head>

<script type="text/javascript">
    window.onload=getCart;
    window.onload=getCompareList;	
</script>

No, don't laugh ... oh all right then, I suppose I deserve it.

So I changed it to

<script type="text/javascript">
    function loadDynamics(){
       getCart();
       getCompareList();
    }	
</script>

<script type="text/javascript">
    window.onload=loadDynamics;	
</script>

and now, so far, it all seems to work as expected even in the Chrome 
instances that were giving the most trouble. Unless there's another 
howler I've missed of course :-(

There is a fair amount of latency that causes the cart area particularly 
to sometimes show the 'network congestion' message, but it gets there 
eventually ... and users can always click the 'get on with it' button if 
they become impatient.

Such is the price of asynchronism I suppose.


Thanks again


-- 
Not floundering ... just fishing

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

#27371

On Sun, 12 Apr 2015 19:36:08 +0100, Robbie Brown wrote:

> Uncaught TypeError: Cannot set property 'innerHTML' of null

Suggests that the problem is less to do with the XMLHTTPRequest and more 
to do with identifying the element whose innerHTML you're trying to set.

How are you selecting the element?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web