You're right, I suspected something like that and then when I switched browsers from Firefox to IE I saw it happening. For my app, using history and Frames is still a good solution, but instead of changing the URL of the Frame I instead now have multiple frames and just set the display of the ones not needed to hidden within the onHistoryChanged function.
As to why the original post is having trouble I can not provide any insight as I don't see where additional history tokens could be being written. On Feb 18, 7:24 am, Thomas Broyer <[email protected]> wrote: > On Feb 17, 4:50 pm, PKolenic <[email protected]> wrote: > > > I am getting similiar behaviour using GWT 2.0. > > In my case I use buttons to switch between an inner I-Frame. > > I put a check in the onClick methods to not write a newItem to History > > if the the old token matches the new token. > > > As a result I only have to push the back button twice now instead of > > three times. > > I think what is happening is that when a button is pressed, and the > > new I-Frame is > > loaded, the token is written twice to the stack. So the first time > > you press the back > > button there is no change in the token value so the onValueChanged (or > > onHistoryChanged) > > does not get called. > > Actually, your newItem is adding an entry to the browser's history, > then the frame adds one (but it doesn't show in the URL), and if you > call newItem once more it might then add yet another entry. > > The rule of thumb is: do not use iframes and History at the same time > (on the same app), iframes (and frames, for that matters) don't play > well with history. -- 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.
