Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.2.1
-
None
Description
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 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.