MyFaces Tomahawk
  1. MyFaces Tomahawk
  2. TOMAHAWK-713

Auto Scroll silently fails on Core 1.1.4 and Tomahawk nightly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.4-SNAPSHOT
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      MyFaces Core 1.1.4 and Tomahawk nightlies (dated 2006-09-26 or 2006-09-27)
      Tested in Firefox and Internet Explorer browsers

      Description

      When using MyFaces Core 1.1.4 and the latest Tomahawk nightlies (dated 2006-09-26 or 2006-09-27), the Auto Scroll functionality fails. There is no error message in the application logs nor in javascript console. This is presumably related to the javascript changes made to ensure compatibility with the RI. This is a major bug, since latest Tomahawk should be compatible with the Core 1.1.4 release.

      This breakage can be observed simply by taking the latest tomahawk-examples nightly download, and substituting in the Core 1.1.4 jars. I will attach such an example.

      1. simple.war
        3.53 MB
        Jeff Bischoff
      2. simple2.war
        3.53 MB
        Jeff Bischoff

        Activity

        Hide
        Jeff Bischoff added a comment -

        This is only the simple.war from tomahawk-examples nightly, with the Core 1.1.4 jars subsituted in. Notice how autoscrolling fails with these jars present.

        Show
        Jeff Bischoff added a comment - This is only the simple.war from tomahawk-examples nightly, with the Core 1.1.4 jars subsituted in. Notice how autoscrolling fails with these jars present.
        Hide
        Jeff Bischoff added a comment -

        Just tested the Tomahawk 2006-10-04 nightly build against Core 1.1.4, and the problem persists.

        Show
        Jeff Bischoff added a comment - Just tested the Tomahawk 2006-10-04 nightly build against Core 1.1.4, and the problem persists.
        Hide
        Wendy Smoak added a comment -

        I'm under the (possibly mistaken) impression that the "javascript changes made to ensure compatibility with the RI" went into Core, not into Tomahawk. If so, they are in Core 1.1.5-SNAPSHOT and should be unrelated to this problem.

        Show
        Wendy Smoak added a comment - I'm under the (possibly mistaken) impression that the "javascript changes made to ensure compatibility with the RI" went into Core, not into Tomahawk. If so, they are in Core 1.1.5-SNAPSHOT and should be unrelated to this problem.
        Hide
        Jeff Bischoff added a comment -

        Wendy, I'm not entirely sure. Perhaps I'm mistaken about the reason for the javascript changes.

        Regardless, a quick look at the generated source for just about any example page reveals dramatically different javascript between Tomahawk 1.1.3 and Tomahawk 1.1.5 (nightly). There are new functions, like "oamSetHiddenInput" and "oamSubmitForm." These were not present in earlier versions. There seems to be some sort of javascript disconnect between Tomahawk 1.1.5 and Core 1.1.4 that affects autoscrolling.

        I think Martin would know about this stuff?

        Show
        Jeff Bischoff added a comment - Wendy, I'm not entirely sure. Perhaps I'm mistaken about the reason for the javascript changes. Regardless, a quick look at the generated source for just about any example page reveals dramatically different javascript between Tomahawk 1.1.3 and Tomahawk 1.1.5 (nightly). There are new functions, like "oamSetHiddenInput" and "oamSubmitForm." These were not present in earlier versions. There seems to be some sort of javascript disconnect between Tomahawk 1.1.5 and Core 1.1.4 that affects autoscrolling. I think Martin would know about this stuff?
        Hide
        Wendy Smoak added a comment -

        I'm building from source with:
        $ cd tomahawk/examples/simple
        $ mvn clean
        $ mvn package -Dmyfaces=1.1.4 cargo:start

        In web.xml, org.apache.myfaces.AUTO_SCROLL is true

        When I visit http://localhost:8080/myfaces-example-simple/autoscroll.jsf , scroll down, and click number 94 or 95, nothing happens. I believe this is the correct behavior. (The message at the top of the page says, "The init parameter org.apache.myfaces.AUTO_SCROLL is set to true. In this case, the page shouldn't move when a link is clicked.")

        (It could be argued that this is backwards, that AUTO_SCROLL=true should mean that the page will scroll. But that's not how it is documented.)

        If I edit web.xml and change AUTO_SCROLL to false, then clicking number 94 causes the page to jump back to the top.

        Jeff, what behavior are you seeing?

        Show
        Wendy Smoak added a comment - I'm building from source with: $ cd tomahawk/examples/simple $ mvn clean $ mvn package -Dmyfaces=1.1.4 cargo:start In web.xml, org.apache.myfaces.AUTO_SCROLL is true When I visit http://localhost:8080/myfaces-example-simple/autoscroll.jsf , scroll down, and click number 94 or 95, nothing happens. I believe this is the correct behavior. (The message at the top of the page says, "The init parameter org.apache.myfaces.AUTO_SCROLL is set to true. In this case, the page shouldn't move when a link is clicked.") (It could be argued that this is backwards, that AUTO_SCROLL=true should mean that the page will scroll. But that's not how it is documented.) If I edit web.xml and change AUTO_SCROLL to false, then clicking number 94 causes the page to jump back to the top. Jeff, what behavior are you seeing?
        Hide
        Jeff Bischoff added a comment -

        Wendy, thanks for looking into this. Can't believe I didn't notice that "autoscroll.jsf" page! I was just randomly testing on the other pages. The problem is still there, but you've narrowed it down a bit. When I go to autoscroll.jsf, it behaves as expected (it down not scroll back to the top). However, those are all h:commandLink. If I change the source to contain a t:commandLink instead, autoscroll breaks on that page (The browser scrolls to the top of the page, when I click on any link). I tried it also with t:commandButton, and this fails to autoscroll also.

        This leads to two conclusions:

        • The mere presence of tomahawk 1.1.5 jar does not interfere with the correct autoscrolling of Core components.
        • When tomahawk 1.1.5 is used on top of Core 1.1.4, autoscrolling is broken for t:commandButton, t:commandLink, and any components that rely on t:commandLink (e.g. datascroller).

        From looking at the generated javascript, there is definately a new submission mechanism being used by these components. That's where the new "oam" javascript functions come into play...

        Show
        Jeff Bischoff added a comment - Wendy, thanks for looking into this. Can't believe I didn't notice that "autoscroll.jsf" page! I was just randomly testing on the other pages. The problem is still there, but you've narrowed it down a bit. When I go to autoscroll.jsf, it behaves as expected (it down not scroll back to the top). However , those are all h:commandLink. If I change the source to contain a t:commandLink instead, autoscroll breaks on that page (The browser scrolls to the top of the page, when I click on any link). I tried it also with t:commandButton, and this fails to autoscroll also. This leads to two conclusions: The mere presence of tomahawk 1.1.5 jar does not interfere with the correct autoscrolling of Core components. When tomahawk 1.1.5 is used on top of Core 1.1.4, autoscrolling is broken for t:commandButton, t:commandLink, and any components that rely on t:commandLink (e.g. datascroller). From looking at the generated javascript, there is definately a new submission mechanism being used by these components. That's where the new "oam" javascript functions come into play...
        Hide
        Jeff Bischoff added a comment -

        I have added a new sample application to better demonstrate this bug. Simple2.war is the Tomahawk example application from 2006-10-06, with the following changes:

        • Removed myfaces 1.1.5 nightlies and replaced with myfaces 1.1.4 release jars.
        • Modified the code for autoscroll.jsp to use t:commandLinks instead of h:commandLinks.

        Now you can easily see the problem occuring on the autoscroll page.

        There is no problem with core components; only tomahawk components are affected.

        Show
        Jeff Bischoff added a comment - I have added a new sample application to better demonstrate this bug. Simple2.war is the Tomahawk example application from 2006-10-06, with the following changes: Removed myfaces 1.1.5 nightlies and replaced with myfaces 1.1.4 release jars. Modified the code for autoscroll.jsp to use t:commandLinks instead of h:commandLinks. Now you can easily see the problem occuring on the autoscroll page. There is no problem with core components; only tomahawk components are affected.
        Hide
        Wendy Smoak added a comment -

        I started a thread [1] on the development list to get feedback on this, and updated the compatibility matrix on the wiki [2].

        I think we've given up on the idea that any version of Tomahawk can be used with any version of MyFaces Core. Right now, the latest released versions are compatible: MyFaces 1.1.4 and Tomahawk 1.1.3.

        [1] http://www.nabble.com/Javascript-changes-and-Core-Tomahawk-compatibility-t2396176.html
        [2] http://wiki.apache.org/myfaces/CompatibilityMatrix

        Show
        Wendy Smoak added a comment - I started a thread [1] on the development list to get feedback on this, and updated the compatibility matrix on the wiki [2] . I think we've given up on the idea that any version of Tomahawk can be used with any version of MyFaces Core. Right now, the latest released versions are compatible: MyFaces 1.1.4 and Tomahawk 1.1.3. [1] http://www.nabble.com/Javascript-changes-and-Core-Tomahawk-compatibility-t2396176.html [2] http://wiki.apache.org/myfaces/CompatibilityMatrix
        Hide
        Jeff Bischoff added a comment -

        Well, I spent the last few hours looking at this bug. I think I've identified two issues which are preventing the 1.1.5 tomahawk components from using AUTO_SCROLL on myfaces 1.1.4, and one of those issues also breaks AUTO_SCROLL for any core commandlinks that are in the same form.

        Issue #1
        ------------
        This probably only affects the tomahawk components. Most of the onclick javascript has been moved to functions which are declared just before the first commandlink. The following code was moved into this function:

        if(window.getScrolling!=undefined)

        { document.forms[formName].elements['autoScroll'].value=getScrolling(); }

        This code looks intended to maintain backwards compatibility for auto scrolling. It works fine for the core components, who use it in the onclick. Unfortunately, when it is used inside this function, the if statement will always return false. The getScrolling() function will never be defined for this javascript block, as it is defined in a separate javascript block at the end of the form.

        To verify this, I inserted some custom javascript into the page, containing this code without the "if" statement. The result when I used the line in a function in the same part of the page was a javascript error in the console "getScrolling() is not defined." But when I used it in an onclick, there was no error.

        Issue #2
        ------------
        I think this issue breaks auto scrolling for all components in the same form as a tomahawk commandLink, regardless of whether they are core or tomahawk components.

        <input type="hidden" name="autoScroll" />

        This hidden input is generated to support auto scrolling. In Myfaces 1.1.4, it is generated at the end of the form. In Myfaces/Tomahawk 1.1.5, it is generated just after the first commandLink. When you mix Myfaces 1.1.4 with Tomahawk 1.1.5, you get two of these inputs per form in any form containing a t:commandLink. Such forms have autoscroll broken for both core components and tomahawk components.

        Show
        Jeff Bischoff added a comment - Well, I spent the last few hours looking at this bug. I think I've identified two issues which are preventing the 1.1.5 tomahawk components from using AUTO_SCROLL on myfaces 1.1.4, and one of those issues also breaks AUTO_SCROLL for any core commandlinks that are in the same form . Issue #1 ------------ This probably only affects the tomahawk components. Most of the onclick javascript has been moved to functions which are declared just before the first commandlink. The following code was moved into this function: if(window.getScrolling!=undefined) { document.forms[formName].elements['autoScroll'].value=getScrolling(); } This code looks intended to maintain backwards compatibility for auto scrolling. It works fine for the core components, who use it in the onclick. Unfortunately, when it is used inside this function, the if statement will always return false. The getScrolling() function will never be defined for this javascript block, as it is defined in a separate javascript block at the end of the form. To verify this, I inserted some custom javascript into the page, containing this code without the "if" statement. The result when I used the line in a function in the same part of the page was a javascript error in the console "getScrolling() is not defined." But when I used it in an onclick, there was no error. Issue #2 ------------ I think this issue breaks auto scrolling for all components in the same form as a tomahawk commandLink, regardless of whether they are core or tomahawk components. <input type="hidden" name="autoScroll" /> This hidden input is generated to support auto scrolling. In Myfaces 1.1.4, it is generated at the end of the form. In Myfaces/Tomahawk 1.1.5, it is generated just after the first commandLink. When you mix Myfaces 1.1.4 with Tomahawk 1.1.5, you get two of these inputs per form in any form containing a t:commandLink. Such forms have autoscroll broken for both core components and tomahawk components.
        Hide
        Martin Marinschek added a comment -

        Hi Jeff,

        as for your issue 1 - the evaluation is not correct, as the onclick-event handler will only be called when the page has been fully processed, the getScrolling method is surely available (if it is rendered) at this point of time. The question is if it is rendered at all - but you said so, right?

        isse 2 - it's not true that rendering the form-input has been moved to before the first link, it's still before the end of the form...

        it must be something else that's breaking the compatibility - if you give me a hint into the right direction, I'm more than willing to fix it.

        regards,

        Martin

        Show
        Martin Marinschek added a comment - Hi Jeff, as for your issue 1 - the evaluation is not correct, as the onclick-event handler will only be called when the page has been fully processed, the getScrolling method is surely available (if it is rendered) at this point of time. The question is if it is rendered at all - but you said so, right? isse 2 - it's not true that rendering the form-input has been moved to before the first link, it's still before the end of the form... it must be something else that's breaking the compatibility - if you give me a hint into the right direction, I'm more than willing to fix it. regards, Martin
        Hide
        Martin Marinschek added a comment -

        By the way - the two of you were speculating about the reason for the javascript changes.

        the major reason was for compatibility with the RI - but while working on the javascript codebase, I was seeing that the javascript code base was rather bloated in the rendered markup. So with putting the javascript functionality in separate functions, I reduced this bloat and ensured better possibilities for debugging, which should help you right now - have you tried firebug or veenkman in your firefox browser to track the problem down further?

        regards,

        Martin

        Show
        Martin Marinschek added a comment - By the way - the two of you were speculating about the reason for the javascript changes. the major reason was for compatibility with the RI - but while working on the javascript codebase, I was seeing that the javascript code base was rather bloated in the rendered markup. So with putting the javascript functionality in separate functions, I reduced this bloat and ensured better possibilities for debugging, which should help you right now - have you tried firebug or veenkman in your firefox browser to track the problem down further? regards, Martin
        Hide
        Jeff Bischoff added a comment -

        Regarding Issue 1, you're right it's a non-issue. My mistake, my javascript test code was flawed. I have retested and confirmed that it is available at the time of the click. There is no javascript error message.

        > isse 2 - it's not true that rendering the form-input has been moved to before the first link, it's still before the end of the form...

        Well if it hasn't been moved, then I think perhaps something is going very wrong on this page. If you download simpe2.war above, and go to the autoscroll page, you are sure to see it. In the source, there are two instances of that autoScroll input: one near the first t:commandLink, and one at the end of the form. Even if I use an unmodified simple.war from the nightly download, I see the autoScroll input appear at the wrong place on this page (what I had assumed was the new place).

        I am using JBoss 4.0.4, and getting the same results on Firefox and IE.

        I'm downloading FireBug now. Still rather new to javascript land.

        Show
        Jeff Bischoff added a comment - Regarding Issue 1, you're right it's a non-issue. My mistake, my javascript test code was flawed. I have retested and confirmed that it is available at the time of the click. There is no javascript error message. > isse 2 - it's not true that rendering the form-input has been moved to before the first link, it's still before the end of the form... Well if it hasn't been moved, then I think perhaps something is going very wrong on this page. If you download simpe2.war above, and go to the autoscroll page, you are sure to see it. In the source, there are two instances of that autoScroll input: one near the first t:commandLink, and one at the end of the form. Even if I use an unmodified simple.war from the nightly download, I see the autoScroll input appear at the wrong place on this page (what I had assumed was the new place). I am using JBoss 4.0.4, and getting the same results on Firefox and IE. I'm downloading FireBug now. Still rather new to javascript land.
        Hide
        Martin Marinschek added a comment -

        Do you have any dummyForm-code generated on this page? dummyForm support has been deprecated...

        Do you use several forms on the page? Are all commandLinks nested in forms?

        regards,

        Martin

        Show
        Martin Marinschek added a comment - Do you have any dummyForm-code generated on this page? dummyForm support has been deprecated... Do you use several forms on the page? Are all commandLinks nested in forms? regards, Martin
        Hide
        Jeff Bischoff added a comment -

        I am doing all testing for this bug using the Tomahawk examples application (both modified and unmodified versions).

        There is no sign of any dummyForm code on the generated page.

        There is one form around everything inside the f:view. In the unmodified example, the form has no id which generates a warning when viewed. I have modified versions where I gave the form an id - there is no error then, but the broken behaviour remains. In both cases, all commandLinks are nested within the form.

        You're not able to reproduce this problem?

        Show
        Jeff Bischoff added a comment - I am doing all testing for this bug using the Tomahawk examples application (both modified and unmodified versions). There is no sign of any dummyForm code on the generated page. There is one form around everything inside the f:view. In the unmodified example, the form has no id which generates a warning when viewed. I have modified versions where I gave the form an id - there is no error then, but the broken behaviour remains. In both cases, all commandLinks are nested within the form. You're not able to reproduce this problem?
        Hide
        Jeff Bischoff added a comment -

        If the rendering of the form input is supposed to be at the end of the form, why is it showing up early? Even in the latest build it shows up in the wrong place.

        http://example.irian.at/example-simple-20061010/autoscroll.jsf

        View the generated source on that. You get the oam submit javascripts just before the first commandLInk, and the autoscroll just after:

        <tr><td><script type="text/javascript"><!--

        function oamSetHiddenInput(formname, name, value)

        { ... }

        function oamSubmitForm(formName, linkId, target, params)
        { ... }

        //--></script><a href="#" onclick="return oamSubmitForm('_idJsp0','_idJsp0:_idJsp5:0:_idJsp7');" id="_idJsp0:_idJsp5:0:_idJsp7">0. Click me!</a>
        <input type="hidden" name="autoScroll" />
        </td></tr>

        Show
        Jeff Bischoff added a comment - If the rendering of the form input is supposed to be at the end of the form, why is it showing up early? Even in the latest build it shows up in the wrong place. http://example.irian.at/example-simple-20061010/autoscroll.jsf View the generated source on that. You get the oam submit javascripts just before the first commandLInk, and the autoscroll just after: <tr><td><script type="text/javascript"><!-- function oamSetHiddenInput(formname, name, value) { ... } function oamSubmitForm(formName, linkId, target, params) { ... } //--></script><a href="#" onclick="return oamSubmitForm('_idJsp0','_idJsp0:_idJsp5:0:_idJsp7');" id="_idJsp0:_idJsp5:0:_idJsp7">0. Click me!</a> <input type="hidden" name="autoScroll" /> </td></tr>
        Hide
        Jeff Bischoff added a comment -

        Oh, and I got a chance to debug the javascript with FireBug (against MyFaces Core 1.1.4 and Tomahawk 1.1.5). Looks like the javascript runs correctly: getScrolling() gets called, and returns the right value. It's just that there are two autoscroll hidden input components on that page, and I don't think it is setting/retrieving from the right one. If we can figure out why this hidden input is showing up in the wrong place and prevent it, I think the javascript will work just fine.

        Show
        Jeff Bischoff added a comment - Oh, and I got a chance to debug the javascript with FireBug (against MyFaces Core 1.1.4 and Tomahawk 1.1.5). Looks like the javascript runs correctly: getScrolling() gets called, and returns the right value. It's just that there are two autoscroll hidden input components on that page, and I don't think it is setting/retrieving from the right one. If we can figure out why this hidden input is showing up in the wrong place and prevent it, I think the javascript will work just fine.
        Hide
        Leonardo Uribe added a comment -

        Fixed long time ago on 1.1.6

        Show
        Leonardo Uribe added a comment - Fixed long time ago on 1.1.6

          People

          • Assignee:
            Leonardo Uribe
            Reporter:
            Jeff Bischoff
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development