Details
Improvement
Major
Description
When navigate to some new content and clicking a button triggers the rendering of a large table
Then menu bar becomes very slow and it takes ~2 sec to display the submenus in IE
Firefox shows no symptom of the issue
If revisit the content by clicking the submenu option again which makes table go away, menu bar responsed normally
-
Hide
-
-
index.jsp
-
index.jspx
-
META-INF/MANIFEST.MF
-
WEB-INF/classes/com/.../test/MyBean.class
-
WEB-INF/classes/com/ice/test/Row.class
-
WEB-INF/classes/com/.../test/TableBean.class
-
WEB-INF/faces-config.xml
-
WEB-INF/lib/backport-util-concurrent.jar
-
WEB-INF/lib/commons-beanutils.jar
-
WEB-INF/lib/commons-collections.jar
-
WEB-INF/lib/commons-digester.jar
-
WEB-INF/lib/commons-discovery.jar
-
WEB-INF/lib/commons-el.jar
-
WEB-INF/lib/commons-fileupload.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/FastInfoset.jar
-
WEB-INF/lib/icefaces-comps.jar
-
WEB-INF/lib/icefaces.jar
-
WEB-INF/lib/jsf-api-1.2.jar
-
WEB-INF/lib/jsf-impl-1.2.jar
-
WEB-INF/lib/jstl.jar
-
WEB-INF/web.xml
-
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Thats good news that the issue is fixed. I have been watching the ICEfaces Subversion (SVN) source code which is available for anonymous access, it is at version 19200 and hasn't been updated for over a week. Can someone please push the latest code to be made available via anonymous access. Is there any other way to access the code base?
The public SVN repo is now refreshed. Had a little systems glitch, sorry.
Thanks we verified that the issue is fixed on IE7 on Tomcat 6.0.16. Appreciate teams help to get the issue resolved in time.
putting menuBar inside a panelGroup which positioned either "relative" or "absolute" would helps too.
<ice:panelGroup style="position:relative;">
<ice:menuBar ..>
</ice:panelGroup>
Horizontal menu delay with IE6 has been fixed.
Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\lib\extras\keyboardNavigator.js
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\lib\extras\keyboardNavigator.js
Completed: At revision: 19255
The problem does not seem to be related to changing CSS classes. I compared their app to an app I created myself in which no additional style classes were specified and also the *:hover CSS classes were removed from our themes, and the problem was still there.
My hypothesis is that this could be related to selecting elements by id, since it's well know that selecting elements in IE is dramatically slower than in other browsers (see http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-vs-dojo-comparison-revised). Since, in order to display a menu we have to make numerous calls to Prototype's selector "$()", which is basically an alias for document.selectElementById(), to hide all other visible menus that aren't selected and to display submenus, this could be a reason.
I guess IE has a very inefficient algorithm for document.selectElementById(). Maybe it simply iterates over all the ids in the page until it finds the desired element, instead of using a more efficient searching algorithm, or maybe it doesn't index the ids in a page at all, etc. Since, data tables can create a lot of elements with their own ids, this seems likely. I will test this with other components to see if they get slower too.