ICEfaces
  1. ICEfaces
  2. ICE-8674

showcase - ace:tabSet - Server Side page loads in Firefox with empty content

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: 3.2
    • Component/s: ACE-Components, Sample Apps
    • Labels:
      None
    • Environment:
      Icefaces3/trunk revision# 31601 / 31613

      Description

      In showcase:
      TabSet - Server Side: when coming first time to this page, the content of the tabSet is empty; must click on the first tab to enable its content (Firefox only).
      This occurrs randomly, only when navigating first to the 'TabSet - Overview', and 'TabSet - Client side' pages and testing their functionality (screen shot attached).

      Steps:
      - load showcase in Firefox.
      - navigate to 'TabSet - Overview', select one or two checkboxes, then select each of the tabs on this page.
      - navigate to 'TabSet - Client Side' page, select each of the tabs.
      - click on 'TabSet - Server Side'; page loads with none of the tabs selected, and no content displayed.

        Activity

        Migration created issue -
        Hide
        Mark Collette added a comment - - edited

        To reproduce this issue is even easier, simply load the tabSet section in the showcase, then click to go to the Client example, and change the tab, and then click to go to the Server section. Essentially what's happening is that the two examples each have a tabSet component with the same clientId, which is causing them to share some state, when each expects a clean slate. It's not really clear to the system the difference between a postback that updates an existing component, versus a postback that uses dynamic ui:include to swap components that identify themselves identically. It should be an application best practice, and necessary practice, to give different ids to components that may take each other's place in a single postback.
        To fix this specific issue I've changed the tabSet ids to be unique amongst the various tabSet examples. But likely it would be best for all of the form names in all of the examples to be unique.
        icefaces3 trunk
        Subversion 31622 [Committed with comment referring accidentally to ICE-8565]

        Show
        Mark Collette added a comment - - edited To reproduce this issue is even easier, simply load the tabSet section in the showcase, then click to go to the Client example, and change the tab, and then click to go to the Server section. Essentially what's happening is that the two examples each have a tabSet component with the same clientId, which is causing them to share some state, when each expects a clean slate. It's not really clear to the system the difference between a postback that updates an existing component, versus a postback that uses dynamic ui:include to swap components that identify themselves identically. It should be an application best practice, and necessary practice, to give different ids to components that may take each other's place in a single postback. To fix this specific issue I've changed the tabSet ids to be unique amongst the various tabSet examples. But likely it would be best for all of the form names in all of the examples to be unique. icefaces3 trunk Subversion 31622 [Committed with comment referring accidentally to ICE-8565]
        Migration made changes -
        Field Original Value New Value
        Reporter Migration [ remote ] Carmen Cristurean [ ccristurean ]
        Migration made changes -
        Attachment tabSet-ServerSide-FF.png [ 14907 ]
        Migration made changes -
        Attachment tabSet-ServerSide-FF.png [ 14908 ]
        Migration made changes -
        Assignee Mark Collette [ mark.collette ]
        Fix Version/s 3.2 [ 10338 ]
        Assignee Priority P1 [ 10010 ]
        Hide
        Migration added a comment -

        Re-tested with revision # 31631 (Firefox 16), and these issues don't exist anymore.

        Show
        Migration added a comment - Re-tested with revision # 31631 (Firefox 16), and these issues don't exist anymore.
        Migration made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Icefaces Administrator made changes -
        Security Private [ 10001 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Assignee Priority P1 [ 10010 ]

          People

          • Assignee:
            Mark Collette
            Reporter:
            Carmen Cristurean
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: