New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draggable/Droppable: submits Ajax requests via the wrong form #3265
Comments
This issue was discovered thanks to this StackOverflow post: https://stackoverflow.com/questions/48258022/primefaces-drag-drop-not-working-if-other-portlets-contain-form-tags/48552329 |
@stiemannkj1 Excellent debugging. |
@stiemannkj1 I think that we should filter out forms without viewstate in our lookup. Should be fine for JSF and Liferay, right? |
@tandraschko, that still won't work because there could be two JSF portlets on the same page. |
Yep, i see. |
@tandraschko sounds good, as I said in the issue: this problem could affect other components as well (if they don't render any markup). But the workaround is very nice and simple and this problem doesn't seem to affect any extremely popular components, so I think the fix can be safely delayed. |
We could also render the script tag with the clientId instead of clientId + "_s" |
@tandraschko, that seems like a good solution. Can you check for other components that might suffer from this problem (meaning that they don't render any markup with their default client id) and apply the same solution for them? |
@stiemannkj1 Could you give it a try? |
Fuck, that doesn't work with MOVE_SCRIPTS_TO_BOTTOM |
We render a dummy markup now. |
@tandraschko, I'll check it tomorrow. Sorry, I've been busy with other tasks. |
@tandraschko, thanks for fixing this! It works correctly in Liferay now. Did you happen to check for other components (that render no markup) that might suffer from this problem? |
1) Environment
6.1
,6.2.RC1
,master
master
.2) Expected behavior
Draggable/Droppable components submit Ajax requests via the
h:form
component that they are contained in.3) Actual behavior
Draggable/Droppable components submit Ajax requests via the first
h:form
component on the page.Since Draggable/Droppable never actually renders an HTML element with its
clientId
, the following code incore.ajax.js
never finds the source element:Since the element is not found, the parent form cannot be found in the next line:
So the code grabs the first
form
on the page as a fallback:This causes serious problems in Liferay where this code may end up attempting to submit an Ajax request via a completely different portlet.
4) Workaround and Potential Solution(s)
There is a simple workaround that works in Liferay: specify the
id
of theform
you are using for the Ajax request:One potential solution would be to render an empty
span
with the correctid
for eachp:droppable
, but there may be other components that suffer from this problem and they would need to follow this solution too. However, this would add needless markup to the page.Alternatively, it might be possible to take the invalid
id
and extract a valid parentid
from it (insidecore.ajax.js
):Perhaps the best solution would be so simply encode the
form
id
for every Ajax behavior. That would fix this issue for all components that might be affected, however it does seem like a big fix for this problem.5) Steps to reproduce
Bean.java
to a webapp and navigate to the XHTML page.dataTable
into the first drop area.dataTable
into the second drop area.6) Sample XHTML
7) Sample bean
The text was updated successfully, but these errors were encountered: