ICEfaces
  1. ICEfaces
  2. ICE-9522

ace:tooltip > Tooltip renders in incorrect location in IE8 + IE10 JS error

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: EE-3.3.0.GA_P01, 4.0.BETA
    • Fix Version/s: EE-3.3.0.GA_P01, 4.0.BETA
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces3/trunk revision# 37332
      icefaces-ee-3.3.0.GA_P01/icefaces tag revision# 37405
    • Assignee Priority:
      P1

      Description

      1. When changing the tooltip position dynamically with speechBubble enabled and then displaying it the tooltip renders in the incorrect location. Only reproducible in IE8.

      To reproduce:
      1) Build / deploy test app located at: http://server.ice:8888/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/tooltip
      2) Navigate to 'Tooltip Dynamic Attribute Test' in IE8
      3) Click 'rendered' checkbox
      4) Click 'speechBubble' checkbox
      5) Change 'position' to 'bottomRight'
      6) Highlight over the text 'I generate a tooltip if for=tooltipOutput' to display the tooltip
      Tooltip will be rendered in the incorrect location, see screenshot. The tooltip will render correctly on the second try.

      2. There is a JS error occurring in IE10 when trying to display the tooltip on any of the test pages:
      Message: Member not found.
      Line: 2582
      Char: 17
      Code: 0
      URI: http://icepc4:8080/tooltip/javax.faces.resource/util/ace-jquery.uncompressed.js.jsf?ln=icefaces.ace&v=3_4_0_130807

      This can be reproduced by navigating to any of the test pages in IE10 and trying to render the tooltip.

        Activity

        Hide
        Arturo Zambrano added a comment - - edited

        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.

        Show
        Arturo Zambrano added a comment - - edited 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.
        Hide
        Ken Fyten added a comment -

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

        Show
        Ken Fyten added a comment - Cruz, please try to reproduce on the ICEPC-IE10 machine and update the JIRA accordingly.
        Hide
        Cruz Miraback added a comment - - edited

        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

        Show
        Cruz Miraback added a comment - - edited 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
        Hide
        Arturo Zambrano added a comment -

        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.
        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Ken Fyten added a comment -

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

        Show
        Ken Fyten added a comment - Issue does not need to be fixed within ICEfaces code, but rather by adjusting the IE configuration settings to not use IE7 standards mode.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Cruz Miraback
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: