[
https://issues.apache.org/jira/browse/DELTASPIKE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385262#comment-14385262
]
Nuno G. de M commented on DELTASPIKE-832:
-----------------------------------------
Hi Thomas,
Sure please review the following test page:
https://drive.google.com/file/d/0B_dEiNBGUsxqZmlBNjlhSHNrOWc/view?usp=sharing
The page includes JQuery, but only to do:
jQuery( spanDomElement).text()
The funciton getUrlParameter(uri, key) provided in the document does not use
jQuery however.
The document is just a set of spans with different utls, and an input text box
in front of each span into which we kick in the result of the test.
Feel free to use, modify simply or discard.
Kindest regards,
Nuno.
> Javascript assert windowId not resilient enough
> -----------------------------------------------
>
> Key: DELTASPIKE-832
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-832
> Project: DeltaSpike
> Issue Type: Bug
> Components: JSF-Module
> Affects Versions: 1.2.1
> Reporter: Nuno G. de M
> Assignee: Thomas Andraschko
> Fix For: 1.3.1
>
>
> The issue is with the algorithm used by the delta spike LAZY mode to identify
> the dswid in the request parameter of a window.
> We have a use case scenario where we open a URL for a view in an iframe by
> doing something as iframe.src / iframe.contentwindow.location.href = url.
> As opposed to doing a standard JSF form postback, this creates a get request
> for the URL. One of the request parameters that we have in our GET request
> is itself a small url.
> Say that we do a get:
> ifram.src =
> '/pageToOpen/whateve.xhtml?param1=whatever&loginUrl=/pathToSomeOtherUrl,xhtml?dswid=56&dswid=78787'
> OK. If you use a browser to decompse the query params of this get request you
> would get:
> param1=whatever
> loginUrl=/pathToSomeOtherUrl,xhtml?dswid=56
> dswid=78787
> This means we have three request parameters, param1, loginUrl and dswid.
> The algorithm:
> function getUrlParameter(name) {
> var url = window.location.href;
> var vars = url.split(/&|\?/g);
> for (var i=0; vars != null && i < vars.length; i++) {
> var pair = vars[i].split("=");
> if (pair[0]==name) {
> return pair[1];
> }
> }
> return null;
> }
> Will wrongly detect the dswid=56 as the window id of the request URL, and it
> will decide that it is different from window.name of the iframe, which in
> this case would actually have been 78787.
> This triggers the page to be double loaded due to the incorrect window id
> determined by the assert window id.
> One possible way to fix this issue, may be to make use of the browser
> capabilities to parse URLs.
> If you were to create an <a> anchor object e.g.
> var a = jQuery('<a>', { href:uri } )[0];
> You then can use the anchor object properties such as a.path and a.search to
> get the diffenrent components from the wndow.location.href.
> After that, you can make an accurate loop over the query parameters by
> spliting the a.search by &.
> Careful that the first element of the search part of the anchor, when not
> empty alway carries the ?, so you might want to do a.search.substring(1).
> Finally on the spllitted array by (&) you can loop over the elements, split
> each by '=' and then you will be accurately be able to know if any of the
> query parameters actually was a dswid.
> The current algorithm is not 100% accurate and can lead to page double
> loading if incrrectly parsing the URL.
> If possible, could you enhance the ds:windowid component to optinally render
> the javascript without using the compressed javascript?
> In order to figre out what was happening with the double load I had to create
> a render extending your base render and with resource depdency on the
> uncompressed javascript.
> Many thanks for all the help.
> Kind regards.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
