ICEfaces
  1. ICEfaces
  2. ICE-7601

ace:tooltip not adopting dynamically updated attribute values

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.RC2
    • Fix Version/s: 3.0
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      ICEfaces 3.0 svn rvn #26993
    • Assignee Priority:
      P1

      Description

      The ace:tooltip no longer adopts attribute value changes that are made dynamically (after the component is initially rendered on the page).

      To reproduce, using the showcase Tooltip demo, change any of the effect configuration settings dynamically and a see that the tooltip will not adopt them unless you force a reload of the page.

      Analysis shows that the tooltip is being updated in the DOM update in response to the ajax request that changes the value, but the component doesn't update it's internal state.

      Here's the response that is returned when the showDelay is changed to 2 seconds (2000 mills). This looks to be correct, but the tooltip component doesn't respect the new attribute values:
       

      <?xml version='1.0' encoding='UTF-8'?>
      <partial-response><changes><update id="j_idt44:tooltipShowDelaySelector"><![CDATA[<select id="j_idt44:tooltipShowDelaySelector" name="j_idt44:tooltipShowDelaySelector" size="1"> <option value="500">0.5 seconds</option>
      <option value="1000">1 second</option>
      <option value="2000" selected="true">2 seconds</option>
      </select>]]></update><update id="j_idt44:tooltip"><![CDATA[<script id="j_idt44:tooltip" type="text/javascript">jQuery(function() {widget_j_idt44_tooltip = new ice.ace.Tooltip({"global":false,"id":"j_idt44:tooltip","displayListener":false,"forComponent":"j_idt44:text",content:document.getElementById('j_idt44:tooltip_content').innerHTML,"show":{"when":{"event":"mouseover"},"delay":2000,"effect":{"length":100,"type":"slide"}},"hide":{"when":{"event":"mouseout"},"delay":500,"effect":{"length":100,"type":"slide"}},"position":{"container":jQuery(ice.ace.escapeClientId('j_idt44:text')).parent(),"corner":{"target":"bottomRight","tooltip":"topLeft"}}});});</script>]]></update><update id="dynamic-code-compat"><![CDATA[<span id="dynamic-code-compat"></span>]]></update><update id="javax.faces.ViewState"><![CDATA[-6438305865883867682:-4979992529496162372]]></update><extension aceCallbackParam="validationFailed">{"validationFailed":false}</extension></changes></partial-response>
      1. screenshot-1.png
        190 kB
      2. screenshot-2.png
        175 kB
      3. screenshot-3.png
        250 kB
      4. screenshot-4.png
        287 kB
      5. screenshot-5.png
        288 kB

        Activity

        Hide
        yip.ng added a comment -

        There is a malformedXML error from the bridge after submitting the show delay change. See screenshot-1.png.

        Show
        yip.ng added a comment - There is a malformedXML error from the bridge after submitting the show delay change. See screenshot-1.png.
        Hide
        yip.ng added a comment -

        Validation shows that the response is valid XML. See screenshot-2.png. The JS is also valid as inspected by IntelliJ.

        Show
        yip.ng added a comment - Validation shows that the response is valid XML. See screenshot-2.png. The JS is also valid as inspected by IntelliJ.
        Hide
        yip.ng added a comment -

        [12:04:27 PM] Ken Fyten: Yip, try removing the singleSubmit tag usage and replacing with f:ajax to see if it changes anything.

        Show
        yip.ng added a comment - [12:04:27 PM] Ken Fyten: Yip, try removing the singleSubmit tag usage and replacing with f:ajax to see if it changes anything.
        Hide
        yip.ng added a comment -

        Same. See screenshot-3.png.

        Show
        yip.ng added a comment - Same. See screenshot-3.png.
        Hide
        Deryk Sinotte added a comment -

        When the updates come back, one of the updates is a single <script> element, responsible for updating the tooltip to use the newly selected attribute values:

        <update id="j_idt68:tooltip">
        <![CDATA[<script id="j_idt68:tooltip" type="text/javascript">jQuery(function() {widget_j_idt68_tooltip = new ice.ace.Tooltip({"global":false,"id":"j_idt68:tooltip","displayListener":false,"forComponent":"j_idt68:text",content:document.getElementById('j_idt68:tooltip_content').innerHTML,"show":{"when":

        {"event":"mouseover"}

        ,"delay":1000,"effect":{"length":0,"type":"grow"}},"hide":{"when":

        {"event":"mouseout"}

        ,"delay":0,"effect":{"length":0,"type":"grow"}},"position":{"container":jQuery(ice.ace.escapeClientId('j_idt68:text')).parent(),"corner":

        {"target":"","tooltip":""}

        }});});</script>]]>
        </update>

        It appears that, in processing this script, JSF runs into difficulty - this affects both Mojarra and MyFaces it appears although there isn't an error with MyFaces.

        I looked at the TooltipRenderer and specifically at a recent fix related to http://jira.icefaces.org/browse/ICE-7588. As part of that fix, it added an id to the script:

        protected void encodeScript(FacesContext facesContext, Tooltip tooltip) throws IOException {
        ResponseWriter writer = facesContext.getResponseWriter();
        boolean global = tooltip.isGlobal();
        String owner = getTarget(facesContext, tooltip);
        String clientId = tooltip.getClientId(facesContext);

        writer.startElement("script", null);
        -> writer.writeAttribute("id", clientId, null);
        writer.writeAttribute("type", "text/javascript", null);

        Simply by commenting out that single line, the tooltip example in the showcase works again and the attributes are properly applied. The downside is that the updates are much bigger as they have to go higher up the chain in order to find a common parent to replace.

        Show
        Deryk Sinotte added a comment - When the updates come back, one of the updates is a single <script> element, responsible for updating the tooltip to use the newly selected attribute values: <update id="j_idt68:tooltip"> <![CDATA[<script id="j_idt68:tooltip" type="text/javascript">jQuery(function() {widget_j_idt68_tooltip = new ice.ace.Tooltip({"global":false,"id":"j_idt68:tooltip","displayListener":false,"forComponent":"j_idt68:text",content:document.getElementById('j_idt68:tooltip_content').innerHTML,"show":{"when": {"event":"mouseover"} ,"delay":1000,"effect":{"length":0,"type":"grow"}},"hide":{"when": {"event":"mouseout"} ,"delay":0,"effect":{"length":0,"type":"grow"}},"position":{"container":jQuery(ice.ace.escapeClientId('j_idt68:text')).parent(),"corner": {"target":"","tooltip":""} }});});</script>]]> </update> It appears that, in processing this script, JSF runs into difficulty - this affects both Mojarra and MyFaces it appears although there isn't an error with MyFaces. I looked at the TooltipRenderer and specifically at a recent fix related to http://jira.icefaces.org/browse/ICE-7588 . As part of that fix, it added an id to the script: protected void encodeScript(FacesContext facesContext, Tooltip tooltip) throws IOException { ResponseWriter writer = facesContext.getResponseWriter(); boolean global = tooltip.isGlobal(); String owner = getTarget(facesContext, tooltip); String clientId = tooltip.getClientId(facesContext); writer.startElement("script", null); -> writer.writeAttribute("id", clientId, null); writer.writeAttribute("type", "text/javascript", null); Simply by commenting out that single line, the tooltip example in the showcase works again and the attributes are properly applied. The downside is that the updates are much bigger as they have to go higher up the chain in order to find a common parent to replace.
        Hide
        Deryk Sinotte added a comment -

        Had a quick chat with Mircea and he confirmed some things I was suspecting. While adding and id to the script may help with the issue for ICE-7588, we generally recommend the practice of putting a containter, such as a <span> tag, around the script element and add the id to the container element. However, I tried that technique in the TooltipRenderer and the problem was still there where the attributes are not being applied properly. However the error is gone and debugging shows that the scripts are being added and removed from the head.

        Show
        Deryk Sinotte added a comment - Had a quick chat with Mircea and he confirmed some things I was suspecting. While adding and id to the script may help with the issue for ICE-7588 , we generally recommend the practice of putting a containter, such as a <span> tag, around the script element and add the id to the container element. However, I tried that technique in the TooltipRenderer and the problem was still there where the attributes are not being applied properly. However the error is gone and debugging shows that the scripts are being added and removed from the head.
        Hide
        Deryk Sinotte added a comment -

        I've applied the fix that puts a containing <span> around the script so that when Mojarra sees the update as a single script, it doesn't complain. After that it appeared that everything was doing what it was supposed to but the tooltip attributes were still not appearing to be applied.

        As it eventually turns out, they scripts with the updates are being received and applied but they are not being removed. That is, all the choices are being applied and remembered. I was only able to determine this by noting that, as I changed more attributes, the tooltip display got more flickery and flakey.

        To finally verify, I:

        • set all the delays to their longest setting (2 seconds)
        • navigated to a different demo (e.g. tabset) then navigated back
        • check to ensure that the current settings are working (everything should take 2 seconds)
        • then change only the effect (e.g. from Slide to Fade)
        • try the tooltip again

        As you do this, you should note that the image both fades AND slides in. In other words, both effects are in play. The same applies for the delay values which is what causes the flakey behaviour and the appearance that the attributes are not being applied.

        I presume that the tooltip.js file needs to be modified so that the various listeners are removed and re-applied when the updates come in.

        Show
        Deryk Sinotte added a comment - I've applied the fix that puts a containing <span> around the script so that when Mojarra sees the update as a single script, it doesn't complain. After that it appeared that everything was doing what it was supposed to but the tooltip attributes were still not appearing to be applied. As it eventually turns out, they scripts with the updates are being received and applied but they are not being removed. That is, all the choices are being applied and remembered. I was only able to determine this by noting that, as I changed more attributes, the tooltip display got more flickery and flakey. To finally verify, I: set all the delays to their longest setting (2 seconds) navigated to a different demo (e.g. tabset) then navigated back check to ensure that the current settings are working (everything should take 2 seconds) then change only the effect (e.g. from Slide to Fade) try the tooltip again As you do this, you should note that the image both fades AND slides in. In other words, both effects are in play. The same applies for the delay values which is what causes the flakey behaviour and the appearance that the attributes are not being applied. I presume that the tooltip.js file needs to be modified so that the various listeners are removed and re-applied when the updates come in.
        Hide
        yip.ng added a comment - - edited

        Two causes:
        1. App. backing bean didn't initialize values to match dropdown lists, resulting in zeros and empty strings for the effects and position params. See screenshot-4.png.
        2. Same general problem as ICE-7361 and ICE-7388 and ICE-7506: multiple instances and framework trying to control the same sections of HTML and CSS. See screenshot-5.png.

        Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\resources\icefaces.ace\tooltip\tooltip.js
        Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\java\org\icefaces\samples\showcase\example\ace\tooltip\TooltipOverviewBean.java
        Completed: At revision: 27068

        Show
        yip.ng added a comment - - edited Two causes: 1. App. backing bean didn't initialize values to match dropdown lists, resulting in zeros and empty strings for the effects and position params. See screenshot-4.png. 2. Same general problem as ICE-7361 and ICE-7388 and ICE-7506 : multiple instances and framework trying to control the same sections of HTML and CSS. See screenshot-5.png. Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\ace\component\resources\icefaces.ace\tooltip\tooltip.js Modified: C:\svn\ossrepo\icefaces3\trunk\icefaces\samples\showcase\showcase\src\main\java\org\icefaces\samples\showcase\example\ace\tooltip\TooltipOverviewBean.java Completed: At revision: 27068
        Hide
        Nils Lundquist added a comment -

        ICE-7601: add a containing span around the script so that Mojarra doesn't complain during update processing.
        Caused regression of ICE-7588.

        Show
        Nils Lundquist added a comment - ICE-7601 : add a containing span around the script so that Mojarra doesn't complain during update processing. Caused regression of ICE-7588 .

          People

          • Assignee:
            yip.ng
            Reporter:
            Ken Fyten
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: