IE8 compatibility

[masterleep]

Is there a released version of Prototype / Scriptaculous that supports
the now-final IE8?

I am getting some errors inside Prototype in that browser. Some
perusal of bug reports leads me to believe that possibly Prototype
doesn't support IE8 yet.

For example:
http://www.bestinclass.com/digital-cameras/best/canon-powershot

Line: 200
Error: 'this.input_elem.readAttribute(...)' is null or not an object

The error is occurring inside Prototype. Same code works on the other
major browsers.

Any advice appreciated!

[masterleep]

OK, I found this particular one... if you call
input_elem.readAttribute('value');
on an input element, and the value is equal to the empty string, then
in IE8 the result is null. On other browsers, the result is the empty
string.

[RobG]

On Mar 20, 6:18 am, masterleep <bill-goo...@lipa.name> wrote:
> OK, I found this particular one... if you call
> input_elem.readAttribute('value');
> on an input element, and the value is equal to the empty string, then
> in IE8 the result is null.

Then that is a bug in IE 8. readAttribute uses getAttribute, which
returns a string in browsers that are compliant with the W3C DOM Core
spec:

<URL: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-666EE0F9 >

>  On other browsers, the result is the empty
> string.

Which is compliant with the spec.

An alternative is to use the DOM property for HTML attributes (i.e.
inputElement.value) - what does that return (I don't have access to IE
8 at the moment)?


--
Rob

[T.J. Crowder]

@masterleep:

I think there are still some IE8 issues. Now that a final is out,
they'll probably get resolved soon. I know kangax (at least) is
working on some of them and several have already been resolved in the
trunk version. Would you give the trunk version a go?

@RobG:

> Then that is a bug in IE 8.

It _may_ be. Half the point of readAttribute it that it "...cleans up
the horrible mess Internet Explorer makes when handling attributes"[1]
and consequently it does a *lot* of processing around the getAttribute
call, including (in trunk) several IE8-specific branches. Always
possible that that code isn't handling something right. Equally, it's
entirely possible that there's a (new) bug in IE8. :-) I don't
currently have a machine I can load IE8 on to find out whether the
fault is in IE8's getAttribute or Prototype's readAttribute.

[1] http://prototypejs.org/api/element/readAttribute

--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

[Completely Free Dating - Andrew]

Hi All,

This appears to be a bug in IE, not prototype, as it is not applying
the class attribute using the specified 'className' property (http://
msdn.microsoft.com/en-us/library/ms533560(VS.85).aspx), but using the
attribute name 'class' instead, so as a work around I have added this
around line 1809 in prototype.js:

if (Prototype.Browser.IE && (parseFloat(navigator.appVersion.split
("MSIE")[1]) >= 8.0) && (name == "className")) name='class';

so it now looks like:

...
name = t.names[attr] || attr;
if (Prototype.Browser.IE && (parseFloat(navigator.appVersion.split
("MSIE")[1]) >= 8.0) && (name == "className")) name='class';
value = attributes[attr];
...

This seems to fix the problem and I have tested in IE7, IE8, FF3,
Opera 9.5, Safari 3 and Chrome 2.0 (all on Windows) and it appears to
have no other side effects.

Kinds regards,

Andrew
Completely Free Dating
www.completelyfreedating.co.uk

[kangax]

On Mar 21, 10:16 pm, Completely Free Dating - Andrew

<andrewjdi...@gmail.com> wrote:
> Hi All,
>
> This appears to be a bug in IE, not prototype, as it is not applying
> the class attribute using the specified 'className' property (http://
> msdn.microsoft.com/en-us/library/ms533560(VS.85).aspx), but using the
> attribute name 'class' instead, so as a work around I have added this
> around line 1809 in prototype.js:
>
> if (Prototype.Browser.IE && (parseFloat(navigator.appVersion.split
> ("MSIE")[1]) >= 8.0) && (name == "className")) name='class';

Do not ever rely on browser sniffing. The "className" "issue" is fixed
in a trunk with a proper feature test [1]. Ironically, the test still
happens in a huge `Prototype.Browser.IE` branch and only tests for IE
7,8 differences. We'll take it out of there as soon as possible.

Btw, as of today, all DOM tests fully pass on IE8.
T.J., do you mind giving it a spin?

[...]

[1] http://github.com/sstephenson/prototype/commit/30c1935cdb6f3a8d850dab8b07a37918740233fb

--
kangax

[T.J. Crowder]

Hi Juriy,

> Btw, as of today, all DOM tests fully pass on IE8.
> T.J., do you mind giving it a spin?

On IE7, you mean? (I have only IE6 and IE7 systems right now.)

IE7 on Windows still has issues in form, dom, and selector tests with
the trunk (assuming "git pull" brings me up to date, I'm a git
newbie):

** selector_test.html:
>> testSelectorWithEmpty
0 assertions, 2 failures, 0 errors
Failure: #level1 *:empty
expected: <[<span id="level3_1">, <span id="level3_2">, <div
id="level2_3">]>, actual: <[<span id="level3_1">, <span
id="level3_2">, <em id="level_only_child">, <div id="level2_3">]>
Failure: newlines count as content!
expected: <[]>, actual: <[<em id="level_only_child">]>

** dom_test.html:
>> testViewportDimensions
1 assertions, 1 failures, 0 errors
Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR
THIS TEST TO PASS
expected: <523>, actual: <485>

** form_test.html:
>> testFormMethodsOnExtendedElements
4 assertions, 1 failures, 1 errors
Failure: assert
got <undefined>
TypeError: Object doesn't support this property or method, error=
([object Error])

Can someone point me to an IE7 setting that controls whether
JavaScript can change the size of the window? The DOM test may be
running afoul of a setting I can't immediately find (in a rush this
morning).

When I get a chance, I'll fire up an IE6 VM and see how it does.

--
T.J. Crowder
tj / crowder software / com
Independent Software Engineer, consulting services available

> [1]http://github.com/sstephenson/prototype/commit/30c1935cdb6f3a8d850dab...
>
> --
> kangax

[kangax]

On Mar 22, 4:42 am, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
> Hi Juriy,
>
> > Btw, as of today, all DOM tests fully pass on IE8.
> > T.J., do you mind giving it a spin?
>
> On IE7, you mean?  (I have only IE6 and IE7 systems right now.)

I meant IE8 :)

>
> IE7 on Windows still has issues in form, dom, and selector tests with
> the trunk (assuming "git pull" brings me up to date, I'm a git
> newbie):
>
> ** selector_test.html:>> testSelectorWithEmpty
>
> 0 assertions, 2 failures, 0 errors
> Failure: #level1 *:empty
> expected: <[<span id="level3_1">, <span id="level3_2">, <div
> id="level2_3">]>, actual: <[<span id="level3_1">, <span
> id="level3_2">, <em id="level_only_child">, <div id="level2_3">]>
> Failure: newlines count as content!
> expected: <[]>, actual: <[<em id="level_only_child">]>
>

Andrew knows about this issue and, afaik, should be taking care of it
shortly.

> ** dom_test.html:>> testViewportDimensions
>
> 1 assertions, 1 failures, 0 errors
> Failure: NOTE: YOU MUST ALLOW JAVASCRIPT TO RESIZE YOUR WINDOW FOR
> THIS TEST TO PASS
> expected: <523>, actual: <485>
>
> ** form_test.html:>> testFormMethodsOnExtendedElements
>
> 4 assertions, 1 failures, 1 errors
> Failure: assert
> got <undefined>
> TypeError: Object doesn't support this property or method, error=
> ([object Error])

Thanks. I could reproduce this in IE6 and just pushed a fix
http://github.com/sstephenson/prototype/commit/2c986d8eaff47a6a181a1c1f43d88443cedfa418

>
> Can someone point me to an IE7 setting that controls whether
> JavaScript can change the size of the window?  The DOM test may be
> running afoul of a setting I can't immediately find (in a rush this
> morning).

I only have IE6 and IE8, both with default settings (I think) inside
virtual machine. Both fully pass DOM tests (including window resizing
tests)

>
> When I get a chance, I'll fire up an IE6 VM and see how it does.

Great.

[...]

--
kangax

[T.J. Crowder]

Hi Juriy,

> Thanks. I could reproduce this in IE6 and just pushed a fixhttp://github.com/sstephenson/prototype/commit/2c986d8eaff47a6a181a1c...

It's fixed in IE7 as well, nice one!

-- T.J. :-)

> Thanks. I could reproduce this in IE6 and just pushed a fixhttp://github.com/sstephenson/prototype/commit/2c986d8eaff47a6a181a1c...

[RobG]

On Mar 21, 10:22 pm, "T.J. Crowder" <t...@crowdersoftware.com> wrote:
[...]

> @RobG:
>
> > Then that is a bug in IE 8.
>
> It _may_ be.

If the OP's statement:

> > On Mar 20, 6:18 am, masterleep <bill-goo...@lipa.name> wrote:
>
> > > OK, I found this particular one... if you call
> > > input_elem.readAttribute('value');
> > > on an input element, and the value is equal to the empty string, then
> > > in IE8 the result is null.

is taken at face value, and the version of Prototype.js being used is
1.6.0.3 (which is still the "latest stable version" published on
prototypejs.org), it is very likely a bug in IE 8.

>  Half the point of readAttribute it that it "...cleans up
> the horrible mess Internet Explorer makes when handling attributes"[1]

In this case the OP is dealing with the value attribute, which is not
one of the properties that readAttribute does anything with - it just
calls getAttribute, even for IE.

> and consequently it does a *lot* of processing around the getAttribute
> call, including (in trunk) several IE8-specific branches.

That is a consequence of trying to write a general wrapper for
getAttribute, which is known to be buggy. Why not just forget get/
setAttribute altogether?

>  Always
> possible that that code isn't handling something right.  Equally, it's
> entirely possible that there's a (new) bug in IE8. :-)

It might be new in the context of all versions of IE, but it can
hardly be a new bug in a browser that hasn't been released yet. ;-)


--
Rob

[T.J. Crowder]

> It might be new in the context of all versions of IE, but it can
> hardly be a new bug in a browser that hasn't been released yet. ;-)

*Obviously* I meant new to the IE line. (And IE8 was released on
Thursday, although Microsoft's own Internet Explorer home page is a
bit divided about it...)

-- T.J. :-)