[
https://issues.apache.org/jira/browse/DELTASPIKE-1074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153781#comment-15153781
]
Sean Flanigan commented on DELTASPIKE-1074:
-------------------------------------------
Sorry, I can't test this properly due to lack of time, and because I've had to
give up on CLIENTWINDOW mode in my application. (I don't have time for a proper
reproducible bug report, but it involves RichFaces' a4j:jsFunction, partial
submits which lack dspwid parameters, and errors like
org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active
contexts for scope type org.apache.deltaspike.core.api.scope.ViewAccessScoped,
perhaps related to DELTASPIKE-446.)
However, trying to switch back to CLIENTWINDOW for a test, using DeltaSpike
1.5.4-SNAPSHOT, I can report that I get infinite client-side redirects when
navigating to the URL {{http://localhost:8180/zanata/?dswid=-3453}} in a tab
with window.name=-3453. (I did force windowhandler.js to refresh). The browser
bounces between {{http://localhost:8180/zanata/?dswid=-3453}} and
{{http://localhost:8180/zanata/javax.faces.resource/deltaspike/windowhandler.js.xhtml}}
I see similar behaviour with the URL
{{http://localhost:8180/zanata/account/sign_in?continue=%252Fzanata%252F%253Fdsrid%253D135}}
(again, bouncing to windowhandler.js.xhtml).
Sorry I can't be more helpful.
> Severe problem in setUrlParam() (windowhandler.js)
> --------------------------------------------------
>
> Key: DELTASPIKE-1074
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1074
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
> Affects Versions: 1.5.3
> Reporter: Sean Flanigan
> Assignee: Thomas Andraschko
> Fix For: 1.5.4
>
>
> I noticed a potential problem with the URI manipulation while reviewing
> https://github.com/apache/deltaspike/commit/323c7d38e9d949385eb9d90c47e8971548ab5ed4
> :
> > {{a.href = uri.replace('?&', '?').replace('&&', '&');}}
> I think it's only safe to coalesce multiple '&'s in the query part (after
> '?), not in the path path (before '?'). In the path part, '&'s are just
> characters, not parameter delimiters.
> Also, it's possible that the URI could be like this:
> {{?&&&dswid=1234&&&}}
> with more than two ampersands in a row, perhaps at the beginning of the query
> string.
> (Attn: [~tandraschko])
> EDIT: It looks like [this
> commit|https://github.com/apache/deltaspike/commit/323c7d38e9d949385eb9d90c47e8971548ab5ed4]
> has totally broken {{setUrlParam()}}, because
> {{dswh.utils.generateRequestToken()}} generates {{requestToken}} as a number,
> but {{setUrlParam()}} now assumes that {{parameterValue}} is a string, and
> tries to call {{replace()}} on it. This leads to errors like this:
> http://localhost:49178/zanata/javax.faces.resource/deltaspike/windowhandler.js.seam
> 10:413 Uncaught TypeError: b.replace is not a function
> I think this wasn't discovered in earlier testing because
> {{windowhandler.js}} seems to be aggressively cached. I had some trouble
> convincing Chrome to reload {{windowhandler.js}}.
> If possible, I would suggest including a hash value in the URL generated by
> {{<ds:windowId/>}} and {{windowhandler.html}}, eg something like {{<script
> type="text/javascript"
> src="/javax.faces.resource/windowhandler.js?hash=871623874619283469"></script>}},
> where the hash is generated from the contents of {{windowhandler.js}}, to
> allow aggressive caching without risk of missing changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
