[
https://issues.apache.org/jira/browse/TRINIDAD-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192310#comment-13192310
]
Venkata Guddanti commented on TRINIDAD-2194:
--------------------------------------------
Please commit escalatedCustPPRBlocking.patch to
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/2.0.0.1-branch
branch as well
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>
> Key: TRINIDAD-2194
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2194
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Infrastructure
> Reporter: Venkata Guddanti
> Assignee: Blake Sullivan
> Fix For: 2.0.0-core
>
> Attachments: escalatedCustPPRBlocking.patch,
> escalatedCustPPRBlocking1.2.12.3.patch,
> escalatedCustPPRBlocking1.2.12.6.2.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> n IE the blocking is initiated on the very first click that happens after a
> ppr request is sent to server. This is done via "onclick" attachEvent
> handler(_pprConsumeFirstClick) on the document. The problem is that
> attachEvent is invoked only in the bubble phase. In IE7/IE8 there is no way
> to set up an event handler at the capture phase. In this case the AJAX
> requests are initiated by the "onclick" event handler on the link. Since the
> click event listener is at target phase, it is always invoked first. So here
> is what happens when the user clicks on the Next link 2 times:
> 1) AJAX Request initiated on "onclick" handler
> 2) Set up the "onclick" attachEvent on the document (_pprConsumeFirstClick)
> 3) User clicks on link again
> 4) Since there is already an "onclick" handler, another AJAX request is
> queued.
> 5) the _pprConsumeFirstClick "onclick" document handler kicks in, which
> setups event capture. It is now too late.
> We believe because of TRINIDAD-952 we do not need to start blocking after the
> second click. We can start immediately since we are letting the first event
> pass through because of a timeout:
> if (_agent.isIE)
> {
> // see TRINIDAD-952 - IE does not update the activeElement in time before
> // blocking starts. Use a timeout to allow the update.
> win._pprTimeoutFunc = win.setTimeout("_doPprStartBlocking(window);",
> 1);
> return;
> }
> The second part of the fix is to restore the scroll location after we set
> focus on the blocking div.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
