Le 25/02/2012 07:25, lkcl luke a écrit : > On Sat, Feb 25, 2012 at 2:09 AM, Peter Bittner<[email protected]> wrote: >> 2012/2/24 lkcl luke<[email protected]>: >>> when you remember who you were, could you kindly take a look at this? >> I think that was Pascal? > ahh. thanks. > > ok - the problem is this: in pyjs, History notification is done via a > hidden iframe, with a timer loop running every 250ms. the recursive > loop however is *still* there. > > thus, once a tab is clicked on, what will happen is that a history > token will be stored in the iframe, the timer loop will pick it up, > change the history, which will cause onHistoryChanged to be called, > which will call setTab, which will cause the onTabChange notify to be > called, which will set a history token to be stored in the hidden > iframe, where the timer loop will pick it up, change the history, > which will cause onHistoryChanged to be called, which will call > setTab.... > > ... and on, and on, and on. > > so it won't cause infinite recursion, but it _will_ increase CPU > usage... permanently. and if there's any bugs in memory handling in > the browser's implementation, eventually the browser will run out of > memory. > > in the case of pyjd, there's no such hidden iframe: the setting of the > history token is called directly, and that's how you end up with the > infinite recursion. > > so - someone needs to stop this from happening! reading the history > token and not calling the history change if it's not needed would do > the trick. > > l. I'll look at it asap.
++ pascal
