ICEfaces
  1. ICEfaces
  2. ICE-10622

IE11 specific issues with samples/compat/component-showcase

    Details

    • Assignee Priority:
      P1

      Description

      rom samples/compat/component-showcase .
      Problems only exist using IE11
      Upon loading the app, issue with gmap (see screen shot IE11_component-showcase_gmap).
      Change theme, and get js error regarding form, see screen shot IE11_component-showcase-js_error)
      note that changing the language, causes full page reload and see the following screenshot IE11_componentShowcase_err) which documents IE11 seeing un matched html tags for markup.

        Activity

        Hide
        Arturo Zambrano added a comment - - edited

        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).

        Show
        Arturo Zambrano added a comment - - edited 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).
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Arturo Zambrano added a comment -

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

        Show
        Arturo Zambrano added a comment - Adding EE-1.8.2.GA_P08 as fix target since these issues also occur in the 1.8 trunk.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Liana Munroe added a comment - - edited

        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.

        Show
        Liana Munroe added a comment - - edited 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.
        Hide
        Arturo Zambrano added a comment -

        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.

        Show
        Arturo Zambrano added a comment - 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.
        Hide
        Carmen Cristurean added a comment -

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

        Show
        Carmen Cristurean added a comment - Verified with EE-3.3.0-maintenance branch r.44533 in IE11, FF34, Chrome42.

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Judy Guglielmin
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: