myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Sullivan (Commented) (JIRA)" <>
Subject [jira] [Commented] (TRINIDAD-2194) Trinidad PPR blocking does not work with 2 clicks that post
Date Tue, 17 Jan 2012 21:41:40 GMT


Blake Sullivan commented on TRINIDAD-2194:

Reverted changes to branch in  revision 1232592
> Trinidad PPR blocking does not work with 2 clicks that post
> -----------------------------------------------------------
>                 Key: TRINIDAD-2194
>                 URL:
>             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,
>   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:!default.jspa
For more information on JIRA, see:


View raw message