Hi Bryan, A potential workaround would be to create the Frame with a known token to indicate that the next history token pushed / popped from the browser history stack comes from the frame page? For example, you could place an #ad token to the URL to which you're sourcing the Frame, and inspect the token for the #ad identifier in your history listener and programmatiicaly go History.back() / History.forward() until you pop the token you were expecting in your application context. This might have the effect of additional click sounds when your user navigates back to the application and presses back / forward (specifically on IE), but I'm not sure if this is unavoidable since history events in a frame from a page will add tokens to the browser history stack.
Hope that helps, -Sumit Chandel On Mon, Aug 3, 2009 at 7:48 PM, Bryan <bwn...@gmail.com> wrote: > > The javadoc for frame says "Note that if you are using History, any > browser history items generated by the Frame will interleave with your > application's history." > > Really? It just breaks it and that's it? Are there any suggested > workarounds? This is a huge problem for sites that serve up ads in > iframes and it seems like there's got to be some way to not end up > with 4 history tokens per 'page' when you have one 'page' and 3 ads on > it. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
