Issue does not need to be fixed within ICEfaces code, but rather by adjusting the IE configuration settings to not use IE7 standards mode.

Since issue #2 only occurs on intranet sites, we will let the users handle it on their end.

To prevent IE10 from entering IE7 mode, follow these steps:

• Click on the 'Tools' item on the IE10 menu bar.
• Select 'Compatibility View Settings'
• In the dialog that pops up, uncheck the box next to 'Display intranet sites in Compatibility View'.

After this you can try displaying the tooltip again, and you won't see the error.

Regarding issue #2...

The reason why there's a JS error when using the host name and not when using localhost or an ip address is that IE10 automatically changes to IE7 mode when using the host name. It's easy to see this by yourself by simply using the host name in the address bar (even if it's the same computer you're on, like icepc-ie10) and pressing F12 to open the developer tools window and seeing that the document mode is 'IE7 Standards'. IE seems to do this when it detects that you're accessing an intranet site. A more thorough explanation can be found here:
http://stackoverflow.com/questions/13284083/ie10-renders-in-ie7-mode-how-to-force-standards-mode

Specifically, the error occurs in the jQuery code. It's not a problem with the tooltip code in particular, but a more general problem. When an older IE browser is detected, jQuery adds some hooks for setting attributes and fixing some issues with older IE browsers. When calling jQuery.attr(), these hooks might be invoked if they were earlier defined by jQuery after having detected an older IE browser. The JS error occurs inside one of these hooks, one used to set values to attributes. When in IE10 standards mode, these hooks are never invoked and no error occurs. When in IE7 mode, the error not always occurs, I found out that it only occurs when setting the 'aria-atomic' attribute; for some reason, the attribute object doesn't have and can't accept a 'value' property.

So, our options so far are:

• Removing the 'aria-atomic' attribute from the qtip code. I already tried this and no more errors occur.
• Implementing a more general fix in the framework to avoid IE10 changing to IE7 mode when accessing an intranet site.

Issue #1 is an IE8 specific issue so I didn't test this on ICEPC-IE10 but I can no longer reproduce it. I tried two IE8 test machines.

Issue #2 can be reproduced on ICEPC-IE10 but only when using the hostname in the URL instead of the IP address.

I get the error if accessing the test page like this:
http://cruz-pc:8080/tooltip/tooltipDynAttribute.jsf
but not when I accessing it using the IP:
http://10.18.39.136:8080/tooltip/tooltipDynAttribute.jsf

I noticed that I can't reproduce it when using the hostname 'localhost' on my machine, so it seems it only occurs when using a hostname other than localhost...

Tested on trunk revision# 37447

Cruz, please try to reproduce on the ICEPC-IE10 machine and update the JIRA accordingly.

So far, I haven't been able to reproduce these two issues. I used the latest revision of the test app, as well as the latest revisions of the trunk and p01 tag. I also went back to trunk revision 37332, as stated in the environment field of this JIRA. I tried all this on my machine and I couldn't reproduce the issues. I also used icepcvm-ie8 and never saw the issues there.

I talked to Cruz, and he tried to reproduce the issues again. We discovered that these issues are very weird. The first issue seems to only occur when using an external monitor connected to his laptop, and not when using his laptop's screen. I work on a laptop only, so I never saw this issue. So, the issue could be related to the screen resolution. I looked at qtip's code, and there isn't much code related to the screen resolution. There's only one part that reads window.innerWidth and window.innerHeight, but it's related to tooltips that use the window or document as the target, not when a specific element is the target.

As for the second issue, Cruz found out that it was only reproducible when using the host name in the URL like http://icepc4:8080/tooltip/tooltipDynAttribute.jsf, and not when using the IP address like http://10.18.39.146:8080/tooltip/tooltipDynAttribute.jsf. I tried to reproduce the issue by accessing both addresses on IE10 from my machine, and I couldn't see the Javascript error. I double-checked to see that I have all the debugging and warning messages enabled on my browser.