You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (Commented) (JIRA)" <ji...@apache.org> on 2012/01/30 16:56:10 UTC

[jira] [Commented] (WICKET-4371) Timer problems with Internet Explorer

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

Martin Grigorov commented on WICKET-4371:
-----------------------------------------

The problem is wicket-ajax.js, stateChangeCallback, line 996:

// In case the page isn't really redirected. For example say the redirect is to an octet-stream.
// A file download popup will appear but the page in the browser won't change.
this.done();
this.successHandler();

this code executes the scheduled actions in the channel (i.e. the timer behavior).
I tried to solve the problem by moving these lines after "window.location=..." calls but they are executed again.

Anyone ideas how to solve this ?
I can it only as an additional setting for Wicket.Ajax.Request that decides whether to call those or not.
                
> Timer problems with Internet Explorer
> -------------------------------------
>
>                 Key: WICKET-4371
>                 URL: https://issues.apache.org/jira/browse/WICKET-4371
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket
>    Affects Versions: 1.5.3, 1.5.4
>         Environment: Jetty/Apache Tomcat & Internet Explorer
>            Reporter: Mikko Pukki
>         Attachments: TimerProblem.zip
>
>
> Hi,
> We are encountering problems on all pages that have timers for updating/polling new data.
> It seems that if new page is rendering, timer's request can mess things up. Problem can be
> reproduced with Wicket 1.5.3 and 1.5.4
> An example situation:
> 1) Page (id1) has a timer and user presses link (Request1) that forwards to a new Page (future id2).
> 2) Request is being processed at server and page with id2 is rendered
> 3) While still in render phase timer makes new request to a server
> Timer's request is handled even if there is a new rendered page. Timer's request is now last request
> handled and page that contained timer is last page stored at PageTable. This causes weird problems with
> our applications.
> I'm wondering that why any request that is meant for previous versions of pages are processed?
> In quickstart rendering is slowed down with Thread.sleep, but network latencies can and will create similar problems.
> In the quickstart there is PageB -link. Pressing that invokes this behavior
> There is also custom store in quickstart that provider simple debug logging. 

--
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