The ice:gMap -> Render Type component page might be commented out in the MapBean.java file:

@MenuLink(title = "menu.compat.map.subMenu.latlong", exampleBeanName = MapLatLong.BEAN_NAME),
@MenuLink(title = "menu.compat.map.subMenu.controls", exampleBeanName = MapControls.BEAN_NAME),
@MenuLink(title = "menu.compat.map.subMenu.zoom", exampleBeanName = MapZoom.BEAN_NAME),
//@MenuLink(title = "menu.compat.map.subMenu.type", exampleBeanName = MapType.BEAN_NAME),
@MenuLink(title = "menu.compat.map.subMenu.load", exampleBeanName = MapLoad.BEAN_NAME)

In order to enable the component page, uncomment the commented line, rebuild and redeploy the showcase.war

This is a follow-up JIRA to ICE-7448

This bug is still reproducible. Take a look at the attached screenshot IEconsoleOutput.jpg showing IE9 console output in different document modes side by side.

When decorating the event object we use IE or Netscape-like specific implementations. Choosing the right one is done by looking at the global variable window.event, if present, IE implementation is used. Problem is that sometimes window.event can point to non-DOM events (like 'onreadystate' in XHR) and the decorator will use that even when an event object is provided. The solution applied tries to use the provided event object, when missing the window.event is used then.

I can still reproduce this on my machine with maintenance branch code rev #28485. It's no longer an issue with IF3 trunk version of the code.

Applied fix to maintenance branch as well.

Re-opened.

This change is causing new regression test failures with the specific combination of IE7 browser and MyFaces JSF (other browsers or using mojarra passes):

Icefaces3.0.x-maintenance revision# 28507
Server: tomcat6 , on icepc13
Browser: FF3.6, IE7 & GoogleChrome17

compat-basic:
Internet Explorer: Test Compat Basic times out waiting for text 'Stock JSF*Show*Hide based on backing bean' to render. Fails manually, clicking on 'Stock JSF Page' button in Internet Explorer does not redirect to Stock JSF page. This is not an issue in Firefox or Chrome.

basic:
Internet Explorer: Test Basic application times out waiting for text 'Stock JSF: Show / Hide based on backing bean' to render. Fails manually, clicking on 'Stock JSF Page' button in Internet Explorer does not redirect to Stock JSF page. This is not an issue in Firefox or Chrome.

This is no longer reproducible on the maintenance branch of ICEfaces showcase since rev#28507. Added ice:gmap > Render Type link back to the showcase. (rev# 28514)

I could not reproduce the IE7+MyFaces issue. The basic and basic-compat were behaving in the same way as when tested with Chrome or FF.

On the other hand running IE7+Mojarra after clicking the 'Stock JSF Page' the browser would freeze for some time (30sec) and then render the expected content.

Tested ice:gMap > Render Type using 3.0 branch rev. 28588 (Mojarra), server: Tomcat 7.0.8/7.0.26, browsers IE9, IE8, IE7, Chrome, FF11.

First, the showcase application was deployed on icepc-ie9 and accessed locally on IE9, and no errors could be reproduced.

Then the application was deployed on my PC and the pages were loaded remotely in IE9 from icepc-ie9, and I got JS errors:

1)when loading the ice:gMap page in IE9

Webpage error details

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)
Timestamp: Thu, 29 Mar 2012 22:17:37 UTC
Message: 'GClientGeocoder' is undefined
Line: 8
Char: 154801
Code: 0
URI: http://10.18.39.149:8080/showcase/javax.faces.resource/icefaces-compat.js.jsf

2) when clicking on Render Type link:

Message: 'GMap2' is undefined
Line: 8
Char: 157086
Code: 0
URI: http://10.18.39.149:8080/showcase/javax.faces.resource/icefaces-compat.js.jsf

When loading the pages remotely in IE7 from icepc13, 2 Runtime Errors occurred when clicking ice:gMap link, and when clicking on Render Type link (same messages as for IE9).

In IE8, Firefox 11, Chrome17 (tested locally): no issues.

Tested basic and compat-basic (MyFaces) in IE7 using 3.0 branch rev. 28594, server: Tomcat 7.0.26, .
I could not reproduce the failures in IE7 w/ MyFaces, when building the apps on my PC (Windows 7 64 bit).
I could reproduce the failures when building the apps on icepc13 using the same code revision. (Windows XP 32 bit); java version "1.6.0_26", Java(TM) SE Runtime Environment (build 1.6.0_26-b03).

Tested basic and compat-basic (MyFaces) in IE7 on icepc18 using 3.0 branch rev. 28579, server: Tomcat6; java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03), and could not reproduce the issue.

Something must be messed up with the IE7 browser on icepc13: basic and compat-basic test fails in IE7 on icepc13, for the locally deployed apps on icepc13, but it passes in IE7 on icepc13 if accessing the same app deployed on icepc18.
Test passes in IE7 on icepc18 if accessing any of the apps, the ones deployed locally on icepc18, or the ones on icepc13.