[jira] [Commented] (DELTASPIKE-832) Javascript assert windowId not resilient enough

["Nuno G. de M (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DELTASPIKE-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080965#comment-15080965 ] 

Nuno G. de M commented on DELTASPIKE-832:
-----------------------------------------

I'm adding a comment here as a note that may be relevant... I've recently detected a double page loading issue specific to IE, that did not happen either for Chrome or Firefox. The issue was the windowhandler.js during assertWindowID of LAZY mode considering that a new window had been opened due to the lack of window.name field in IE. The same field was set appropriately on Chrome and Firefox. The issue result of window navigation being trigged with a Iframe.src = newViewUrl. Apprently in IE - at least version 10 - when the SRC attribute of an iframe is swapped IE discards the contentWindow object. The delta spike windowhandler.js however did not have the same issue when it would temporarly set the window.name = 'tempWindowId', because delta spike is triggering the javascript reditect by doing a window.location. To fix the issue and make sure that the windowObject is not discarded out when doing the hacky javascript navigation the iframe.src code was swapped to be iframe.contentWindow.location. The src attribute navigation is not consitent accross all browsers. Regards.

> 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.4.0
>
>
> 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)