It definitely appears to be the case that having multiple GWT window objects (as frames) is playing a role in the problem. The main window has two frames, and some GWT JSNI runs inside each of the two frames. When JSNI in one frame calls the other, the type information on the passed objects either is lost, or becomes inaccessible. So type comparisons across the window barrier don't work - even for JavaScriptObject.
I'm not sure how the second window for GWT is created. We have some JS that runs by being called from the GWT onModuleLoad() entry point, but other JS on the main page is triggered by scheduled timers. We aren't intentionally using iframes or creating any other window objects ourselves.
Does the new linker for GWT 2.7.0 handle this situation differently? Is the object inequality across the window barrier something GWT is doing, or something that is done by the browser? If the browser, why isn't it a problem in GWT 2.6.1?
-- I'm not sure how the second window for GWT is created. We have some JS that runs by being called from the GWT onModuleLoad() entry point, but other JS on the main page is triggered by scheduled timers. We aren't intentionally using iframes or creating any other window objects ourselves.
Does the new linker for GWT 2.7.0 handle this situation differently? Is the object inequality across the window barrier something GWT is doing, or something that is done by the browser? If the browser, why isn't it a problem in GWT 2.6.1?
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment