MyFaces Core
  1. MyFaces Core
  2. MYFACES-1259

login page commandLink error -- default AutoScroll setting depends on Tomahawk

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1.2-SNAPSHOT
    • Fix Version/s: 1.1.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      JBoss 4.0.4 RC1, MyFaces 4/4/06 night build.

      Description

      Upgraded to JBoss 4.0.4RC1 and MyFaces 4/4/06 night build.

      When user visit a protected page, the login.jsp will show up for user to login in.
      But in the login.jsp, if clicking commandLink "Forget Password", "Error on Page" will show up on browser status bar (IE).
      nothing else happens. It was working before: JBoss 4.0.3 RC1 and MyFaces 1/16/06.

      login.jsp (simplified for testing)
      -----------

      <%@ page contentType="text/html; charset=UTF-8"%>

      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

      <HTML>

      <body>

      <f:view>

      <h:commandLink value="Forget Password"
      action="#

      {bean.resetPassword}

      "/>
      </f:view>
      </body>
      </html>

      Browser source
      ------------------

      <HTML>

      <body>

      <a href="#" onclick="clear_linkDummyForm();document.forms['linkDummyForm'].elements['autoScroll'].value=getScrolling();document.forms['linkDummyForm'].elements['linkDummyForm:_link_hidden_'].value='_idJsp0';if(document.forms['linkDummyForm'].onsubmit){var result=document.forms['linkDummyForm'].onsubmit(); if( (typeof result == 'undefined') || result ) {document.forms['linkDummyForm'].submit();}}else

      {document.forms['linkDummyForm'].submit();}

      return false;" id="_idJsp0">ForgetPassword</a>

      </body>
      </html>

        Activity

        Hide
        Mario Ivankovits added a comment -

        Now its fixed on the share branch too.

        Could someone please test it.
        Thanks!

        Show
        Mario Ivankovits added a comment - Now its fixed on the share branch too. Could someone please test it. Thanks!
        Hide
        sean schofield added a comment -

        Mario, you marked the version fixed as 1.1.2-SNAPSHOT but its really 1.1.3-SNAPSHOT since you fixed on the trunk. I am reopening and marking the versions to be fixed as both 1.1.2-SNAPSHOT and 1.1.3-SNAPSHOT. Please close when you fix on the branch since that is one of two critical fixes we are waiting for.

        Show
        sean schofield added a comment - Mario, you marked the version fixed as 1.1.2-SNAPSHOT but its really 1.1.3-SNAPSHOT since you fixed on the trunk. I am reopening and marking the versions to be fixed as both 1.1.2-SNAPSHOT and 1.1.3-SNAPSHOT. Please close when you fix on the branch since that is one of two critical fixes we are waiting for.
        Hide
        Mike Kienenberger added a comment -

        Please checkout and build the latest svn snapshot and see if this works for you. We'd like to make sure that this fix gets into the 1.1.2 release.
        Thanks.

        Show
        Mike Kienenberger added a comment - Please checkout and build the latest svn snapshot and see if this works for you. We'd like to make sure that this fix gets into the 1.1.2 release. Thanks.
        Hide
        Mario Ivankovits added a comment -

        Please comment on this ticket if there are still problems

        Show
        Mario Ivankovits added a comment - Please comment on this ticket if there are still problems
        Hide
        Mario Ivankovits added a comment -

        Tomahawk features are automatically disabled now if tomahawk.jar is not available.

        Show
        Mario Ivankovits added a comment - Tomahawk features are automatically disabled now if tomahawk.jar is not available.
        Hide
        Mario Ivankovits added a comment -

        BTW: Dont forget you have to configure the ExtensionsFilter to cover your JSF mapping too

        e.g.

        <filter-mapping>
        <filter-name>MyFacesExtensionsFilter</filter-name>
        <url-pattern>*.jsf</url-pattern>
        </filter-mapping>

        Show
        Mario Ivankovits added a comment - BTW: Dont forget you have to configure the ExtensionsFilter to cover your JSF mapping too e.g. <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <url-pattern>*.jsf</url-pattern> </filter-mapping>
        Hide
        Mario Ivankovits added a comment -

        We need to update the documentation.
        I dont know when this changed and who it was, but the ExtensionsFilter is required to add the javascript required by myfaces e.g. to handle the scrolling stuff.

        Also we decided to move the dummyForm/ExtensionsFilter stuff out of shared to tomahawk.
        I think this is somewhat reasonable, "shared" IMHO wasnt the right place, and we had some headaches - remember the classCastException and wrongly
        named session/request parameters.
        With the move to tomahawk we also decided to use the renderer-replacement feature of JSF to make the extended commandLink/commandButon stuff work even
        after the move. This has been done only to be backward compatible - I am not sure about the scrolling, but at least the dummyForm worked with myfaces even if you used
        the h: components.

        Both are extensions of JSF brought by MyFaces, thus the move to tomahawk. Later we can discuss if the (new to be created) commons is the better place.

        I use myfaces head with success, dummyForm and scrolling works as expected. Also the samples of myfaces show no errors.

        Please double check there is no old myfaces library (e.g. the old commons) lie around somewhere.

        Show
        Mario Ivankovits added a comment - We need to update the documentation. I dont know when this changed and who it was, but the ExtensionsFilter is required to add the javascript required by myfaces e.g. to handle the scrolling stuff. Also we decided to move the dummyForm/ExtensionsFilter stuff out of shared to tomahawk. I think this is somewhat reasonable, "shared" IMHO wasnt the right place, and we had some headaches - remember the classCastException and wrongly named session/request parameters. With the move to tomahawk we also decided to use the renderer-replacement feature of JSF to make the extended commandLink/commandButon stuff work even after the move. This has been done only to be backward compatible - I am not sure about the scrolling, but at least the dummyForm worked with myfaces even if you used the h: components. Both are extensions of JSF brought by MyFaces, thus the move to tomahawk. Later we can discuss if the (new to be created) commons is the better place. I use myfaces head with success, dummyForm and scrolling works as expected. Also the samples of myfaces show no errors. Please double check there is no old myfaces library (e.g. the old commons) lie around somewhere.
        Hide
        Mike Kienenberger added a comment -

        This should be fixed (or the AUTOSCROLL default changed) in order to release 1.1.2.

        Show
        Mike Kienenberger added a comment - This should be fixed (or the AUTOSCROLL default changed) in order to release 1.1.2.
        Hide
        Holger Benl added a comment -

        OK, I reverted back to tomahawk-1.1.1 and set AUTO_SCROLL to false and now my setup works as desired

        Show
        Holger Benl added a comment - OK, I reverted back to tomahawk-1.1.1 and set AUTO_SCROLL to false and now my setup works as desired
        Hide
        Holger Benl added a comment -

        Just realized that the extensionsfilter is part of the tomahawk distribution which I hadn't updated from 1.1.1 because I thought I wouldn't need it since I'm not using any tomahawk components.
        After updating to tomahawk-1.1.2-SNAPSHOT.jar, however, I get the following exception when starting tomcat:

        java.lang.NoClassDefFoundError: org/apache/myfaces/custom/buffer/HtmlBufferResponseWriterWrapper

        and when I try to call my web application, I get another exception:

        java.lang.NoSuchMethodError: org.apache.myfaces.renderkit.html.util.DummyFormUtils.findNestingForm(Ljavax/faces/component/UIComponent;Ljavax/faces/context/FacesContext

        (oddly enough I can see that this last method DOES exist in the tomahawk-1.1.2-SNAPSHOT.jar !?)

        anyway: I shouldn't need the tomahawk.jar if I don't use its components. And the classname mentioned above sounds like MyFaces is trying to create a dummy form - which
        shouldn't be necessary, since all my components are inside an <h:form> tag.

        Show
        Holger Benl added a comment - Just realized that the extensionsfilter is part of the tomahawk distribution which I hadn't updated from 1.1.1 because I thought I wouldn't need it since I'm not using any tomahawk components. After updating to tomahawk-1.1.2-SNAPSHOT.jar, however, I get the following exception when starting tomcat: java.lang.NoClassDefFoundError: org/apache/myfaces/custom/buffer/HtmlBufferResponseWriterWrapper and when I try to call my web application, I get another exception: java.lang.NoSuchMethodError: org.apache.myfaces.renderkit.html.util.DummyFormUtils.findNestingForm(Ljavax/faces/component/UIComponent;Ljavax/faces/context/FacesContext (oddly enough I can see that this last method DOES exist in the tomahawk-1.1.2-SNAPSHOT.jar !?) anyway: I shouldn't need the tomahawk.jar if I don't use its components. And the classname mentioned above sounds like MyFaces is trying to create a dummy form - which shouldn't be necessary, since all my components are inside an <h:form> tag.
        Hide
        Chad Lyon added a comment -

        Do you also have in your deployment descriptor:

        <context-param>
        <param-name>org.apache.myfaces.AUTO_SCROLL</param-name>
        <param-value>true</param-value>
        </context-param>

        You must or you wouldn't get this part in your "onclick" event of your <a> tag:

        document.forms['_id20'].elements['autoScroll'].value=getScrolling();

        ...set that parameter to false and your links will start working again. This is just a work around. Something is missing. I had the same problem. I turned on the extensions filter and teh getScrolling() function started to get generated. Also, the following post to the dev list by Mike made me think it was what I described above:

        >Mario (or whoever else was involved with moving the autoscroll stuff into tomahawk recently),
        >
        >Could you take a look at http://issues.apache.org/jira/browse/MYFACES-1259?
        >
        >Doing so appears to have broken the generation of "getScrolling"
        >javascript, and command links are not working.

        I will look into it in a few and determine if it really is caused by the move and see if I can't come up with a patch or two (I have limited windows of time durring regular business hours).

        BTW the extensions filter is not required to use myfaces, only to use the myfaces extesions. Read here:

        http://myfaces.apache.org/tomahawk/extensionsFilter.html

        Show
        Chad Lyon added a comment - Do you also have in your deployment descriptor: <context-param> <param-name>org.apache.myfaces.AUTO_SCROLL</param-name> <param-value>true</param-value> </context-param> You must or you wouldn't get this part in your "onclick" event of your <a> tag: document.forms ['_id20'] .elements ['autoScroll'] .value=getScrolling(); ...set that parameter to false and your links will start working again. This is just a work around. Something is missing. I had the same problem. I turned on the extensions filter and teh getScrolling() function started to get generated. Also, the following post to the dev list by Mike made me think it was what I described above: >Mario (or whoever else was involved with moving the autoscroll stuff into tomahawk recently), > >Could you take a look at http://issues.apache.org/jira/browse/MYFACES-1259? > >Doing so appears to have broken the generation of "getScrolling" >javascript, and command links are not working. I will look into it in a few and determine if it really is caused by the move and see if I can't come up with a patch or two (I have limited windows of time durring regular business hours). BTW the extensions filter is not required to use myfaces, only to use the myfaces extesions. Read here: http://myfaces.apache.org/tomahawk/extensionsFilter.html
        Hide
        Holger Benl added a comment -

        The extensions filter is already enabled in my web.xml (which was autogenerated by Exadel Studio - I didn't even know it's possible to run MyFaces without this filter)
        Still the getScrolling() function doesn't show up.

        Show
        Holger Benl added a comment - The extensions filter is already enabled in my web.xml (which was autogenerated by Exadel Studio - I didn't even know it's possible to run MyFaces without this filter) Still the getScrolling() function doesn't show up.
        Hide
        Chad Lyon added a comment -

        You must turn on your extensions filter now in order for the getScrolling() function to get appended. Add the following to your deployment descriptor:

        <filter>
        <filter-name>
        MyFacesExtensionsFilter
        </filter-name>
        <filter-class>
        org.apache.myfaces.component.html.util.ExtensionsFilter
        </filter-class>
        <init-param>
        <param-name>maxFileSize</param-name>
        <param-value>20m</param-value>
        <description>Set the size limit for uploaded files.
        Format: 10 - 10 bytes
        10k - 10 KB
        10m - 10 MB
        1g - 1 GB
        </description>
        </init-param>
        </filter>

        <filter-mapping>
        <filter-name>MyFacesExtensionsFilter</filter-name>
        <servlet-name>Faces Servlet</servlet-name> </filter-mapping>
        <filter-mapping>
        <filter-name>MyFacesExtensionsFilter</filter-name>
        <url-pattern>/faces/myFacesExtensionResource/*</url-pattern>
        </filter-mapping>

        If seems the extensions filter is now appending that javascript function instead of the Faces Servlet as in 1.1.1. If this is the desired functionality then the Faces Servlet should not be adding the call to the function to the controls' onclick javascript events. It should be left up to the extensions filter which means that only the myfaces extended controls can utilize the auto-scrolling functionality.

        It seems to me like someone needs to decide which the desired functionality is:

        1. The use of regular (non-extended) commandLink and commandButton controls can take advantage of the auto-scroll feature. (therefore put auto-scroll back in the core and let the Faces Servlet handle this)

        2. Only Myfaces extended commnadLink and commandButton controls can take advantage of the auto-scroll feature (move all auto-scrolling javascript generation to the extensions filter). It looks like someone did a partial move.

        Show
        Chad Lyon added a comment - You must turn on your extensions filter now in order for the getScrolling() function to get appended. Add the following to your deployment descriptor: <filter> <filter-name> MyFacesExtensionsFilter </filter-name> <filter-class> org.apache.myfaces.component.html.util.ExtensionsFilter </filter-class> <init-param> <param-name>maxFileSize</param-name> <param-value>20m</param-value> <description>Set the size limit for uploaded files. Format: 10 - 10 bytes 10k - 10 KB 10m - 10 MB 1g - 1 GB </description> </init-param> </filter> <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <servlet-name>Faces Servlet</servlet-name> </filter-mapping> <filter-mapping> <filter-name>MyFacesExtensionsFilter</filter-name> <url-pattern>/faces/myFacesExtensionResource/*</url-pattern> </filter-mapping> If seems the extensions filter is now appending that javascript function instead of the Faces Servlet as in 1.1.1. If this is the desired functionality then the Faces Servlet should not be adding the call to the function to the controls' onclick javascript events. It should be left up to the extensions filter which means that only the myfaces extended controls can utilize the auto-scrolling functionality. It seems to me like someone needs to decide which the desired functionality is: 1. The use of regular (non-extended) commandLink and commandButton controls can take advantage of the auto-scroll feature. (therefore put auto-scroll back in the core and let the Faces Servlet handle this) 2. Only Myfaces extended commnadLink and commandButton controls can take advantage of the auto-scroll feature (move all auto-scrolling javascript generation to the extensions filter). It looks like someone did a partial move.
        Hide
        Holger Benl added a comment -

        ... and when I attach that javascript myself, the <h:commandLink>s work the way they should.

        Show
        Holger Benl added a comment - ... and when I attach that javascript myself, the <h:commandLink>s work the way they should.
        Hide
        Holger Benl added a comment -

        I have to correct myself: Firefox does react when clicking the link:
        it gives the error message "getScrolling is not defined". And indeed
        in Myfaces 1.1.1 there is a javascript appended at the end, but not
        in 1.1.2.
        Here's the javascript that 1.1.1 appends at the end:

        <script type="text/javascript"><!--
        function getScrolling() {
        var x = 0; var y = 0;
        if (self.pageXOffset)

        { x = self.pageXOffset; y = self.pageYOffset; }

        else if (document.documentElement && document.documentElement.scrollLeft)

        { x = document.documentElement.scrollLeft; y = document.documentElement.scrollTop; }

        else if (document.body)

        { x = document.body.scrollLeft; y = document.body.scrollTop; }

        return x + "," + y;
        }

        //--></script>

        Show
        Holger Benl added a comment - I have to correct myself: Firefox does react when clicking the link: it gives the error message "getScrolling is not defined". And indeed in Myfaces 1.1.1 there is a javascript appended at the end, but not in 1.1.2. Here's the javascript that 1.1.1 appends at the end: <script type="text/javascript"><!-- function getScrolling() { var x = 0; var y = 0; if (self.pageXOffset) { x = self.pageXOffset; y = self.pageYOffset; } else if (document.documentElement && document.documentElement.scrollLeft) { x = document.documentElement.scrollLeft; y = document.documentElement.scrollTop; } else if (document.body) { x = document.body.scrollLeft; y = document.body.scrollTop; } return x + "," + y; } //--></script>
        Hide
        Mike Kienenberger added a comment -

        Reported to affect proposed 1.1.2 release candidate.

        Show
        Mike Kienenberger added a comment - Reported to affect proposed 1.1.2 release candidate.
        Hide
        Holger Benl added a comment -

        Forgot to mention: I'm running this on Tomcat 5.5.15

        Show
        Holger Benl added a comment - Forgot to mention: I'm running this on Tomcat 5.5.15
        Hide
        Holger Benl added a comment -

        I have exactly the same problem. I'm using MyFaces snapshots and facelets 1.1.4. I've tried with IE, Firefox and Opera.
        When clicking on the link, IE shows an error (as described by the original poster) and firefox and opera don't react at
        all (except for putting "#" at the end of the URL) .
        More importantly, the issue also comes up with the 1.1.2 snapshot I tried! I tried the 04/07 snapshot of 1.1.3 and the 04/09
        snapshot of 1.1.2

        Here's my facelets test page:
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
        <html xmlns="http://www.w3.org/1999/xhtml"
        xmlns:h="http://java.sun.com/jsf/html"
        xmlns:f="http://java.sun.com/jsf/core">
        <body>
        <f:view>
        <h:form>
        <h:commandLink action="#

        {testBean.test}

        " value="Click me" />
        </h:form>
        </f:view>
        </body>
        </html>

        and here's the generated HTML (it's the same for 1.1.2 and 1.1.3 except for the auto-generated IDs):
        <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" >
        <html xmlns="http://www.w3.org/1999/xhtml">
        <body><form id="id20" name="_id20" method="post" action="/MyJSF/cmdlink.jsf" enctype="application/x-www-form-urlencoded"><a href="#" onclick="clear_5Fid20();document.forms['_id20'].elements['autoScroll'].value=getScrolling();document.forms['_id20'].elements['_id20:_link_hidden_'].value='_id20:_id21';if(document.forms['_id20'].onsubmit){var result=document.forms['_id20'].onsubmit(); if( (typeof result == 'undefined') || result ) {document.forms['_id20'].submit();}}else

        {document.forms['_id20'].submit();}

        return false;" id="_id20:_id21">Click me</a><input type="hidden" name="_id20_SUBMIT" value="1" />
        <input type="hidden" name="autoScroll" />
        <input type="hidden" name="jsf_sequence" value="12" /><input type="hidden" name="id20:_link_hidden" /><script type="text/javascript"><!--
        function clear__5Fid20()

        { var f = document.forms['_id20']; f.elements['_id20:_link_hidden_'].value=''; f.target=''; }

        clear__5Fid20();
        //--></script></form>
        </body>
        </html>

        Show
        Holger Benl added a comment - I have exactly the same problem. I'm using MyFaces snapshots and facelets 1.1.4. I've tried with IE, Firefox and Opera. When clicking on the link, IE shows an error (as described by the original poster) and firefox and opera don't react at all (except for putting "#" at the end of the URL) . More importantly, the issue also comes up with the 1.1.2 snapshot I tried! I tried the 04/07 snapshot of 1.1.3 and the 04/09 snapshot of 1.1.2 Here's my facelets test page: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://java.sun.com/jsf/html" xmlns:f="http://java.sun.com/jsf/core"> <body> <f:view> <h:form> <h:commandLink action="# {testBean.test} " value="Click me" /> </h:form> </f:view> </body> </html> and here's the generated HTML (it's the same for 1.1.2 and 1.1.3 except for the auto-generated IDs): <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > <html xmlns="http://www.w3.org/1999/xhtml"> <body><form id=" id20" name="_id20" method="post" action="/MyJSF/cmdlink.jsf" enctype="application/x-www-form-urlencoded"><a href="#" onclick="clear _5Fid20();document.forms ['_id20'] .elements ['autoScroll'] .value=getScrolling();document.forms ['_id20'] .elements ['_id20:_link_hidden_'] .value='_id20:_id21';if(document.forms ['_id20'] .onsubmit){var result=document.forms ['_id20'] .onsubmit(); if( (typeof result == 'undefined') || result ) {document.forms ['_id20'] .submit();}}else {document.forms['_id20'].submit();} return false;" id="_id20:_id21">Click me</a><input type="hidden" name="_id20_SUBMIT" value="1" /> <input type="hidden" name="autoScroll" /> <input type="hidden" name="jsf_sequence" value="12" /><input type="hidden" name=" id20:_link_hidden " /><script type="text/javascript"><!-- function clear__5Fid20() { var f = document.forms['_id20']; f.elements['_id20:_link_hidden_'].value=''; f.target=''; } clear__5Fid20(); //--></script></form> </body> </html>
        Hide
        Dave added a comment -

        JBoss 4.0.4RC1 + MyFaces 1/16/06: Works Fine.
        JBoss 4.0.4RC1 + MyFaces 4/4/06: CommandLink in login.jsp, "Error On Page" still exists.

        Show
        Dave added a comment - JBoss 4.0.4RC1 + MyFaces 1/16/06: Works Fine. JBoss 4.0.4RC1 + MyFaces 4/4/06: CommandLink in login.jsp, "Error On Page" still exists.
        Hide
        Dennis Byrne added a comment -

        So can it be closed then ?

        Show
        Dennis Byrne added a comment - So can it be closed then ?
        Hide
        Dave added a comment -

        After going backing to MYFaces 1/16/06, tried with JBoss 4.0.4 RC1, everything worked fine. The "Error on Page" issue was gone.

        After I upgraded to JBoss 4.0.4RC1, there was an assue with FacesContext that was null when user login.
        Today I went back to 1/16/06, the issue was gone. I could not reproduce. Magic !

        Show
        Dave added a comment - After going backing to MYFaces 1/16/06, tried with JBoss 4.0.4 RC1, everything worked fine. The "Error on Page" issue was gone. After I upgraded to JBoss 4.0.4RC1, there was an assue with FacesContext that was null when user login. Today I went back to 1/16/06, the issue was gone. I could not reproduce. Magic !
        Hide
        Mike Kienenberger added a comment -

        Make sure you don't have an old version of MyFaces in your JBoss classpath.
        Somewhere around this version, JBoss began to distribute MyFaces as part of the container.

        If at all possible, please try with your original JBoss 4.0.3 RC1 setup and MyFaces 4/4/06 night build.
        If that's not possible, try with JBoss 4.0.4RC1 and MyFaces 1/16/06 so we can rule out either MyFaces or JBoss as the problem.

        Show
        Mike Kienenberger added a comment - Make sure you don't have an old version of MyFaces in your JBoss classpath. Somewhere around this version, JBoss began to distribute MyFaces as part of the container. If at all possible, please try with your original JBoss 4.0.3 RC1 setup and MyFaces 4/4/06 night build. If that's not possible, try with JBoss 4.0.4RC1 and MyFaces 1/16/06 so we can rule out either MyFaces or JBoss as the problem.

          People

          • Assignee:
            Mario Ivankovits
            Reporter:
            Dave
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development