Verified the behaviour as specific to MyFaces. I tried updating the MyFaces libs to the more recent ones on the trunk but that didn't help.

From what I can tell in testing this issue, it doesn't appear to have ever worked with MyFaces so it's not a regression.

The problem can most accurately described as every second drag of the ajax slider doesn't work. Other sliders on the page work and every second drag of the ajax slider works but the follow up drag fails to move along the rail (although the event fires).

• I tested with both the latest from the maintenance branch and from the trunk with the same results. The only difference of note is that sometimes the first drag is the working one and sometimes the second. In either case, following that, subsequent drags alternate between working and not working.

• I went back and tested -r27602 (which is the revision the maintenance branch was created) and the same issue manifests there as well.

• Non of the other sliders on the test page show the problem.

At this point, it simply seems like a bug related to MyFaces and I can only assume that it's somehow related to the sliderStart event which is the difference with that slider when compared to the others.

This problem seems very sensitive to browser caching but when I retested the latest maintenance branch and trunk using Mojarra. I actually saw that it has the same issue. So does not appear to be a regression or MyFaces specific. It manifests on both JSF runtimes. The only thing to watch out for is that the first drag may or may not work. After that drags will work on alternate drags. So it may appear to work initially but you have to try multiple times to ensure every drag is working.

From what I can tell, it appears that drags that work only update the changed inputText and outputText values of the drag events and values inside the form. Clicking on the slider button for the next drag appears to update the entire form, which triggers the evaluation and recreation of the JavaScript for creating the slider widget and binding the various configuration values and events. I think this prevents it from working until the next drag is attempted.

To easily recreate the problem using the showcase:

• edit the slider-async-input.xhtml file
• change the event from slideEnd to slideStart like so

<ace:ajax event="slideStart" execute="@this" render="@form" />

• open the ace:sliderEntry Input example and try dragging the slider multiple times

I might need to pass this back to the component guys as I'm not sure exactly how the "slideStart" event is supposed to operate. What I think is happening is that:

1) The first time you click to start to drag the thumb of the slider, because it's the slideStart event, the request is sent right away upon clicking. This is before any movement has actually taken place. So the response that comes back is basically empty because nothing has really changed. When you release the thumb of the slider, no new request is sent (as it would be with slideEnd for instance) to ensure that things are back in sync.

2) The next time you click to drag, the request is again sent right away but it's now sending the information from the slider as it ended up on the previous drag. That information was never sent originally so now you have this valid change to the DOM that gets applied while you are still trying to drag the slider. The update is the whole form that contains the slider (not sure if this is intentional but the sliderEnd example does the same thing) which ends up re-evaluating the script widget code. This update while the drag is in progress looks like it causes the problem.

3) Since the update applied has now brought things in sync, the next drag takes you back to step 1.

My guess is that request needs to be sent at the end of the drag as well to ensure the client and server are sync with regards to the current state of the slider. It may be that the update of the whole form is too broad but the other sliders seem to handle it without a problem.

To test this hypothesis I added a second ajax facet to the slider:

<h:panelGroup>
<h:form id="form1e">
<ace:sliderEntry id="sliderEntry">
<ace:ajax event="slideStart" listener="$

" />
</ace:sliderEntry>
</h:form>
</h:panelGroup>

With Mojarra, this allows the slider to work normally but it does send 2 Ajax request at the beginning and end of each slide. With MyFaces, the first click still has a an issue of some kind but after that it appears to work normally as well.

Some more testing shows that, with a clean cache etc and the workaround of registering two ace:ajax event listeners, the first click can still fail. After that the slider seems to work fine but the very first click still has a problem where the initial update causes the focus to be lost or something similar and dragging fails.

The other thing that's probably the recommended thing to do anyway is to better target the execute and render targets. Changing the test so that the initial update isn't so broad allows the slider to work more as it's intended. I think it's fair to adjust the test to do this as the slideStart event is a bit of a outlier compared to the others and some of them do the same thing:

<ace:sliderEntry id="sliderEntry">
<ace:ajax execute="@this" render="statusMsg" event="slideStart" listener="$

" />
</ace:sliderEntry>

I've adjusted the test to reflect the code above.

Adding a work around.

Resolving as Won't Fix as we simply adjusted the test.

Committed a fix to the trunk at revision 31191. The fix consists in separating the script into two different script tags. The first one simply initializes the slider, without setting a value. The second one simply updates the value of the slider, without having to recreate the whole slider. The reason why this problem was occurring was that whenever the user started to move the slider, a request was made and since the value changed, the script to initialize the slider was updated because it contained the new value, and the whole slider had to be recreated.