earthoutreach / earth-api-utility-library

Automatically exported from code.google.com/p/earth-api-utility-library
0 stars 0 forks source link

IE9 RC1 throwing error on GEarthExtensions.prototype.util.callMethod #34

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Run most any of the examples

Looks like there's some problem with the typeof check in 
GEarthExtensions.prototype.util.callMethod that's making it fall through.

Original issue reported on code.google.com by bcke...@google.com on 15 Feb 2011 at 11:48

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
If you need an immediate workaround, add the following to your page to force 
the document mode to be IE8:

<meta http-equiv="X-UA-Compatible" content="IE=8">

Original comment by bcke...@google.com on 15 Feb 2011 at 11:52

GoogleCodeExporter commented 8 years ago
It looks as though the Google Earth object is being initiated differently in IE9

In the page
http://earth-api-samples.googlecode.com/svn/trunk/demos/helloearth/index.html

the following code using console will return different results in IE9 vs all 
other browsers 

typeof ge.createPlacemark  

in chrome, firefox ie8 : "function" is returned

in ie9: "unknown"

Original comment by Berwyn.M...@gmail.com on 16 Feb 2011 at 12:45

GoogleCodeExporter commented 8 years ago
Since the plugin's functions are technically host objects, IE doesn't put them 
in the proper prototype hierarchy and so typeof returns "unknown". This is a 
wontfix for them: https://connect.microsoft.com/IE/feedback/details/585293

what's changed in IE9 is that window['eval'] is now properly an indirect eval 
call, and so evaluates in the global scope (where object isn't defined).

This should be a one line fix, just have to keep IE8, IE9, and the YUI 
Compressor happy.

Original comment by bcke...@google.com on 16 Feb 2011 at 1:47

GoogleCodeExporter commented 8 years ago

I replaced the second return statement in 
GEarthExtensions.prototype.util.callMethod

FROM:
return window['eval']('object.' + method + '(' + reprArgs.join(',') + ')');

TO:
return function(_o, _m, _a){ return _o[_m](_a); }(object,method,(args.length 
=== 1) ? args[0] : args );

I have tested it with IE9 RC, FF 3.6.13 and Chrome 9.0.597.98 and things seem 
to work now in ie9 standards mode

 it also addresses the comment :
// Don't use eval directly due to a YUI Compressor bug/feature.

since we are not using eval and concating some strings it may run faster

Original comment by Berwyn.M...@gmail.com on 16 Feb 2011 at 2:24

GoogleCodeExporter commented 8 years ago
this seams to work also, more testing needed though

return object[method]((args.length === 1) ? args[0] : args );

Original comment by Berwyn.M...@gmail.com on 16 Feb 2011 at 2:38

GoogleCodeExporter commented 8 years ago
Did some testing with IE8, things work.

I don't have a native ie7 or ie6 machine handy, things work for IE6 and IE7, 
using ieeTester, http://www.my-debugbar.com/wiki/IETester/HomePage

Original comment by Berwyn.M...@gmail.com on 16 Feb 2011 at 7:31

GoogleCodeExporter commented 8 years ago
I've now pushed a fix to trunk; thanks for your help. The issue with your 
suggestion (unless I'm missing something) is that the conditional's second 
AssignmentExpression (args) is an array and would need an apply() call to use 
it, which of course IE doesn't support on host objects. That said, all the uses 
of callMethod() within the utility library worked with your fix because they 
all invoked it with zero or one arguments.

I've taken the slightly more drastic step of eliminating callMethod() 
altogether. This eliminates the undesirable eval, the YUI Compressor fragility, 
and the strange code path IE had to take. This might be a breaking change for 
some users, but I find it unlikely anyone was using this function. Anybody that 
was should take a look at, e.g.

http://code.google.com/p/earth-api-utility-library/source/diff?spec=svn66&r=66&f
ormat=side&path=/trunk/extensions/src/dom/_header.js

for the simple fix.

I've tested the change fairly extensively, but would appreciate any feedback, 
especially if you find any issues with the update.

Original comment by bcke...@google.com on 17 Feb 2011 at 9:27

GoogleCodeExporter commented 8 years ago
I think there is something wierd in the way IE is handls the arrays, 

It seams to be undocumented, IE8 and ie9 with the changes , I havn`t tried it 
in IE7 or ie6 though

I was testing in IE9 and IE8 and the second conditional assignment expression 
was working.  I actually had :
return object[method](args );

and this worked in ie9 for most calls, in the cases where it didn`t work ,  the 
function being called had only one argument

adding the assignment expression corrected it
return object[method]((args.length === 1) ? args[0] : args );

I don`t know why, but it works

Original comment by Berwyn.M...@gmail.com on 18 Feb 2011 at 7:28

GoogleCodeExporter commented 8 years ago
the function calls I was testing with were createPlacemark createPolygon, which 
had multiple arguments

Original comment by Berwyn.M...@gmail.com on 18 Feb 2011 at 7:31

GoogleCodeExporter commented 8 years ago
My mistake, you were right, I didn't stumble upon a IE javascript quirk.

Looking at the code this morning, the functions I was testing with were only 
passing one or 0 arguments.

if things break with util.callMethod a hack with switch could always be used to 
accomidate the different sizes for args.length  

Original comment by Berwyn.M...@gmail.com on 18 Feb 2011 at 6:37