Details
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
- ice4106.war
- 5.42 MB
- Arturo Zambrano
-
- index.jsp 0.1 kB
- index.jspx 19 kB
- META-INF/MANIFEST.MF 0.1 kB
- WEB-INF/classes/com/.../test/MyBean.class 2 kB
- WEB-INF/classes/com/ice/test/Row.class 1 kB
- WEB-INF/classes/com/.../test/TableBean.class 1 kB
- WEB-INF/faces-config.xml 2 kB
- WEB-INF/lib/backport-util-concurrent.jar 319 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-collections.jar 558 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-discovery.jar 75 kB
- WEB-INF/lib/commons-el.jar 110 kB
- WEB-INF/lib/commons-fileupload.jar 56 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/FastInfoset.jar 285 kB
- WEB-INF/lib/icefaces-comps.jar 1.90 MB
- WEB-INF/lib/icefaces.jar 1.05 MB
- WEB-INF/lib/jsf-api-1.2.jar 350 kB
- WEB-INF/lib/jsf-impl-1.2.jar 816 kB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/web.xml 9 kB
-
- IE6-menuBar.JPG
- 63 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Assigned Mircea to investigate alternative/faster approaches to using "selectByID" in the IE version of the bridge.
The last things I tried were:
- Instead of having a large table on the page, I included 40 ice:selectInputDate components, and the menu bar got slower, as well – as slow as with the table. More calendars made it even slower, just as having a larger table made it slower as well.
- I tried to find out if the problem had to do with the rendering engine, but that doesn't seem to be the problem. With the table and with the calendars on the page, I added some non-ICEfaces Javascript and markup to display a div when clicking on a button (using $() once) but it wasn't slow at all.
It seems that the bottle neck is Element.viewportOffset method from Prototype library. This method is invoked 7 times when Ice.Menu.show method is used to render the submenu.
I profiled the Element.viewportOffset method in IE, it's execution takes under 1 ms most of the times. But when the table is rendered the method execution takes about 16 ms.
Fix added.
Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\component\menu.js
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\component\menu.js
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\lib\extras\keyboardNavigator.js
Completed: At revision: 19116
ICE1.8.1 with revisions up to 19035 works perfect.
With this last patch main menu items do not opens on click!
click regression has been fixed under the following JIRA:
ICE-4788
IE specific fix added:
Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\component\menu.js
Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\bridge\component\menu.js
Completed: At revision: 19202
The menu miss alignment can be avoid by specifying appropriate width to the panelGrid which containing the menu component(e.g.)
<ice:panelGrid style="width:100%">
<ice:panelGroup>
<ice:menuBar id="menuBar">
Can this code be pushed on SVN available code so we can try the fix?
Verified successfully on trunk revision 19228 + Tomcat 6.0 using IE6 and IE7. The miss alignment issue on IE6 is confirmed fixed as well.
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.