Using the latest revision (from today), I couldn't reproduce the first two issues: There was no popup from Google Maps and the demo worked normally; No errors occurred or were logged when changing theme.

The third issue is a more general issue that also happens in the 4.x trunk. Two hidden input elements that are automatically added to forms (javax.faces.ViewState and javax.faces.ClientWindow) are being rendered with a closing tag, whereas they should be rendered as singleton tags.

<input type="hidden" name="javax.faces.ViewState" id="j_id1:javax.faces.ViewState:1" value="5239631506982053703:5833428545550954248" autocomplete="off"></input>
<input type="hidden" name="javax.faces.ClientWindow" id="j_id1:javax.faces.ClientWindow:1" value="5ji8kjxbut" autocomplete="off"></input>

Other hidden input elements that are also added automatically by the framework like 'ice.view' and 'ice.window' are rendered correctly, without the closing tag. Input elements rendered by components are also rendered correctly, as singleton tags.

IE11 is complaining about this fact, while other browsers don't seem to care. Functionality is not affected by this, however. These warnings are only logged when refreshing the page (either manually or automatically).

After some more investigation, it seems like Mojarra is the one responsible for rendering those hidden inputs with closing tags. On MyFaces, the 'javax.faces.ViewState' input is rendered as a singleton because we handle that rendering ourselves in DOMResponseWriter.WriteViewStateMarkup, and the 'javax.faces.ClientWindow' is just not rendered at all on MyFaces.

Adding EE-1.8.2.GA_P08 as fix target since these issues also occur in the 1.8 trunk.

Committed fix for second issue to the 3.3 EE maintenance branch at revision 44518 and to the 1.8 trunk at revision 44519.

The error occurred in many other extended components, not just ice:selectOneMenu. The problem was that these components passed a 'form' object to the submit function that wasn't declared anywhere in the event handlers. I've never been aware of a 'form' object that is readily available from event handlers and points to the enclosing form. If that was the case in other browsers, IE11 doesn't seem to recognize it. If that wasn't the case, then other browsers simply didn't complain about it. This issue was fixed by adding 'var form=formOf(this);' at the beginning of those event handlers that use the 'form' object so that this object is not null when passing it to the submit function.

Testing notes: please test all extended components in 3.3 and 1.8 on IE 11, using a separate machine to access the application. For some reason, accessing the application from the same machine the server was running didn't show these errors.

Tested with ICEfaces EE-3.3.0 maintenance branch r44519.
First issue (gMap popup error) is still reproducible. It will occur when accessing a demo that is served up on a separate machine or by using your local machine and accessing the URL with your ip address rather than localhost. This is not exclusive to IE 11, it happens on all browsers when accessing the demo as described above. Replacing the key value in the web.xml with the key value used in the ICEfaces 1.8 component-showcase solved the issue. The popup did not occur in ICEfaces 1.8 component-showcase at any time.

  <context-param>
        <param-name>com.icesoft.faces.gmapKey</param-name>
        <param-value>*****yAATyWVqT2qNusNGmcVTyQ0Qm*******</param-value>
    </context-param>

Second issue is verified resolved by testing extended components using ICEfaces EE-3.3.0 maintenance branch and ICEfaces 1.8.2 r44519. Tomcat 7, IE 11, Chrome 41, FF 34.

r44521: changed Google Maps key to that used in the 1.8 trunk, in order to avoid cross-domain permission issues.

The issue with the mismatched tag warning messages on IE11 will be left as a known issue, since it's an issue with Mojarra not rendering self-closing input tags.

Verified with EE-3.3.0-maintenance branch r.44533 in IE11, FF34, Chrome42.