2008/9/13 Thomas Broyer <[EMAIL PROTECTED]> > > It fires history events when the history changes, it also fires history > > listeners when the history *hasn't* changed > "refresh" case
Call it what you like: the history stack hasn't changed and the listeners get fired. > and it fails to fire history listeners when the history *does* change. when explicitly told and only when explicitly creating a new history > entry (newItem), to avoid workarounds where you keep track of the > token you're setting to ignore the subsequent history change event. And justify it in any way you like, it doesn't alter the fact that the token is getting changed and the history listeners aren't getting fired. I could justify the use of onHistoryChanged with: ...when explicity told to and only when explicity firing listeners to avoid workarounds where you have to use JSNI to replace the history token to ignore the previously created history item. You also say 'I wouldn't say then that it "used to be _OK_"' Come on, I keep asking, answer the question :-) Why was using it not OK? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
