Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.3
    • Fix Version/s: 1.2.4
    • Component/s: JSR-252
    • Labels:
      None
    • Environment:
      MSIE

      Description

      Since nothing seems to be happening with MYFACES-1723, I'm raising this major bug against the JSF 1.2 specification.

      Summary: MyFaces 1.2.3 does not support <f:param name="id" /> under Microsoft Internet Explorer, which violates the JSF 1.2 specification;
      cf. section 4.1.11 UIParameter and section 9.4.8 <f:param> the 'name' attribute of <f:param> is a String with no specific exceptions for a name of "id".

      Some additional details: with myfaces-api-1.2.2.jar and myfaces-impl-1.2.2.jar, using <f:param name="id" /> works;
      with myfaces-api-1.2.3.jar and myfaces-impl-1.2.3.jar using <f:param name="id" /> fails, e.g. an

      <h:commandLink actionListener="#

      {myController.selectId}

      ">
      <f:param name="id" value="123" />
      </h:commandLink>

      when submitted does not pass the param to selectId(), that is: the value in

      public void selectId(ActionEvent event)

      { final String value = FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("id"); }

      remains null.

      1. myfaces-1900-patch.txt
        3 kB
        Gertjan van Oosten
      2. patchMYFACES1900Proposal2.patch
        1 kB
        Leonardo Uribe

        Issue Links

          Activity

          Hide
          Gertjan van Oosten added a comment -

          Copied from MyFaces Dev list:

          As quoted from Gertjan van Oosten <gertjan@West.NL>:
          > To follow-up on my own message: the classes from r645741 seem to work,
          > the classes from r647237 fail under MSIE. So the incompatible change
          > seems to appear first after:
          >
          > 2008-04-11 17:39 lu4242
          > * [r647237]
          > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java,
          > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java,
          > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java:
          > fix MYFACES-1855 hidden fields created when using h:commandLink
          > and f:param should be created and removed using javascript
          >
          >
          > [All this is in myfaces/shared/trunk_3.0.x]

          Then if I re-enable the lines on trunk commented out in r647237 in
          HtmlButtonRendererBase and HtmlLinkRendererBase, it works again.

          I'll attach a patch

          Show
          Gertjan van Oosten added a comment - Copied from MyFaces Dev list: As quoted from Gertjan van Oosten <gertjan@West.NL>: > To follow-up on my own message: the classes from r645741 seem to work, > the classes from r647237 fail under MSIE. So the incompatible change > seems to appear first after: > > 2008-04-11 17:39 lu4242 > * [r647237] > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java, > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java, > core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java: > fix MYFACES-1855 hidden fields created when using h:commandLink > and f:param should be created and removed using javascript > > > [All this is in myfaces/shared/trunk_3.0.x] Then if I re-enable the lines on trunk commented out in r647237 in HtmlButtonRendererBase and HtmlLinkRendererBase, it works again. I'll attach a patch
          Hide
          Leonardo Uribe added a comment -

          After checking the problem and doing some intensive tests, the problem is the behavior of form.elements['xxx'] method on IE.

          In the method oamSetHiddenInput it says:

          if(typeof form.elements[name]=='undefined')

          { ................... }

          but form.elements['id'] or form.elements['name'] returns the attribute value rather than the child (on firefox just return undefined). So, the child is never added to the dom tree.

          The solution is check if the value is a "INPUT", doing something like this:

          function oamSetHiddenInput(formname, name, value)
          {
          var form = document.forms[formname];
          if(!typeof form.elements[name]=='undefined' && form.elements[name].nodeName=='INPUT')

          { form.elements[name].value=value; }

          else

          { var newInput = document.createElement('input'); newInput.setAttribute('type','hidden'); newInput.setAttribute('id',name); newInput.setAttribute('name',name); newInput.setAttribute('value',value); form.appendChild(newInput); }

          }

          So, only if the value returned is not undefined it is checked again if is an INPUT. If does not exist this property just create but if exists do not create and set the value (since is was defined before using html).

          It could be good if I have some feedback about this solution(since this part has been a very problematic part and any change must be done with care), if not I'll commit it.

          Show
          Leonardo Uribe added a comment - After checking the problem and doing some intensive tests, the problem is the behavior of form.elements ['xxx'] method on IE. In the method oamSetHiddenInput it says: if(typeof form.elements [name] =='undefined') { ................... } but form.elements ['id'] or form.elements ['name'] returns the attribute value rather than the child (on firefox just return undefined). So, the child is never added to the dom tree. The solution is check if the value is a "INPUT", doing something like this: function oamSetHiddenInput(formname, name, value) { var form = document.forms [formname] ; if(!typeof form.elements [name] =='undefined' && form.elements [name] .nodeName=='INPUT') { form.elements[name].value=value; } else { var newInput = document.createElement('input'); newInput.setAttribute('type','hidden'); newInput.setAttribute('id',name); newInput.setAttribute('name',name); newInput.setAttribute('value',value); form.appendChild(newInput); } } So, only if the value returned is not undefined it is checked again if is an INPUT. If does not exist this property just create but if exists do not create and set the value (since is was defined before using html). It could be good if I have some feedback about this solution(since this part has been a very problematic part and any change must be done with care), if not I'll commit it.
          Hide
          Leonardo Uribe added a comment -

          I have committed the solution 2 proposed

          Show
          Leonardo Uribe added a comment - I have committed the solution 2 proposed
          Hide
          Alan Chan added a comment -

          Hi, found that when I test to click the link generated by h:commandLink using Windows Mobile 6 emulator, the link just has no response. And after I applied back the patch mentioned in myfaces-1900-patch.txt, it works again. Please un-comment back the code mentioned in myfaces-1900-patch.txt. It is because the Windows Mobile doesn't support the document.createElement() and form.appendChild() inside the javascript function oamSetHiddenInput

          The emulator I used to test is downloaded from here:

          http://www.microsoft.com/downloads/details.aspx?familyid=38C46AA8-1DD7-426F-A913-4F370A65A582&displaylang=en#filelist

          Show
          Alan Chan added a comment - Hi, found that when I test to click the link generated by h:commandLink using Windows Mobile 6 emulator, the link just has no response. And after I applied back the patch mentioned in myfaces-1900-patch.txt, it works again. Please un-comment back the code mentioned in myfaces-1900-patch.txt. It is because the Windows Mobile doesn't support the document.createElement() and form.appendChild() inside the javascript function oamSetHiddenInput The emulator I used to test is downloaded from here: http://www.microsoft.com/downloads/details.aspx?familyid=38C46AA8-1DD7-426F-A913-4F370A65A582&displaylang=en#filelist

            People

            • Assignee:
              Leonardo Uribe
              Reporter:
              Gertjan van Oosten
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development