Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.0
-
Fix Version/s: EE-4.1.0.RC1, EE-4.1.0.GA, 4.2.BETA, 4.2
-
Component/s: ACE-Components, Sample Apps
-
Labels:None
-
Environment:Tomcat 7, ICEfaces 4.0, All browsers
Description
To reproduce:
- Go to http://icefaces-showcase.icesoft.org/showcase.jsf?grp=aceMenu&exp=tooltipOverviewBean
- Mouse over the Camaro Button, the id of the tooltip is "qtip-form:tooltipCamaro-content"
- In the top selectmenu change the Effect to "Grow Effect"
- Mouse over the Camaro button again, the id of the tooltip is "qtip-0-content"
- In the top selectmenu change the Effect to "Fade Effect"
- Mouse over the Camaro button again, the id of the tooltip is "qtip-1-content"
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Tested with ICEfaces 4 trunk r47791. Issue appears resolved and all regression tests pass except for the Tooltip Iterative Selection test. In this test case the tooltip (an image) only appears when mousing over the last item in the ui:repeat. The tooltip image is supposed to appear when the first and second items are moused over as well. This failure was not occurring with r47600 (jenkins build 1797) which was the last revision before the changes were made for this JIRA.
To reproduce:
1.) Use the QA test application /tooltipSelectIterative.jsf found at:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/tooltip
2.) Mouse over the first and second items on the page. Instead of the expected ICEsoft logo being shown, the tooltip takes the form of a windows tooltip.
3.) Mouse over the third item, the ICEsoft logo as a tooltip is displayed as expected.
r48119: reverted to old behaviour of assigning numeric ids in the cases where the target component is inside an iterative container
Verified ICEfaces 4 trunk r48120. Tomcat 8, FF 43, Chrome 48, IE 11, 10, 9, 8.
r47603: removed mechanism in qtip code that assigned new numeric ids to new tooltip instances and instead added call to destroy the previous instance with the same id
While this wasn't a real issue, because those ids, prefixed with qtip-, were only created in the client side by the qtip plugin when rendering the actual tooltip markup, this behaviour was causing the page to use more memory to keep the markup of the previous tooltip versions as well as the entire instance object. In the delegate mode, this was being done for every row that triggered the tooltip. So, this fix not only prevents qtip from using different ids but also makes sure to destroy a previous tooltip instance if it had the same id of the one currently being rendered.
Testing notes: because this was a change in the underlying qtip widget, please run all regression tests.