Google Wave - Prism Issues

0 views
Skip to first unread message

Nathan Anderson

unread,
Nov 18, 2009, 2:48:15 PM11/18/09
to mozilla-labs-prism
After running the google "wave" for a little while in a prism
application it appears that the "window" variable is getting set/
corrupted to something else. Has anyone else seen anything like
this occurring in a prism application?


Jason Miller

unread,
Nov 18, 2009, 2:55:39 PM11/18/09
to mozilla-l...@googlegroups.com
Yes, there is an issue of this kind. Is Wave notifying you of an error, or are you running custom JavaScript code via webapp.js?

- Jason

Jason Miller
519.872.0797 // developIT // Jason Miller Design
Developer of amoebaOS, Shutterborg, Delitweet & more
--

You received this message because you are subscribed to the Google Groups "mozilla-labs-prism" group.
To post to this group, send email to mozilla-l...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-prism?hl=en.


Nathan Anderson

unread,
Nov 18, 2009, 3:15:18 PM11/18/09
to mozilla-labs-prism


On Nov 18, 1:55 pm, "Jason Miller" <ja...@developit.ca> wrote:
> Yes, there is an issue of this kind. Is Wave notifying you of an error, or are you running custom JavaScript code via webapp.js?

Custom webapp.js; Beau (a co-worker) posted below a early version of
the script we are running in a earlier thread and I've been battling
ever since the issue of why notification "breaks" randomly.
Initially I thought somehow gwave was disabling timer events somehow.
So the new version of the script actually no longer uses a timer to
check. But long story short; I'm like 99.9999% sure the window
variable is corrupted, as I can trigure a routine on demand and
"window.alert" fails to run. But other code that doesn't reference
the "window" variable works. My "current" version of this script I
have just tried today; creates a _myWindow variable and assigns it in
the load event and then references it throughout the code -- we shall
see if it will finally solve the issue.

But I figured I would check to see if window being corrupted in
Prism is a known issue. Google Wave does not report an error; and it
continues to run fine; but notification totally breaks since
"window".content.document.title is no longer valid.

Jason Miller

unread,
Nov 18, 2009, 4:15:18 PM11/18/09
to mozilla-l...@googlegroups.com
try wrapping your entire webapp.js code in a function and keeping a private reference to the original window object that was available from the load() function:

function wavePrismClient(window) {
  // just  copy and paste your script into this function
 
  // it will call your load function
  load();
}

function load() {
  wavePrismClient(window);

}


Jason Miller
519.872.0797 // developIT // Jason Miller Design
Developer of amoebaOS, Shutterborg, Delitweet & more

On Wed Nov 18 2009 15:15:18 GMT-0500 (EST), Nathan Anderson wrote:

Nathan Anderson

unread,
Nov 18, 2009, 6:39:52 PM11/18/09
to mozilla-labs-prism


On Nov 18, 3:15 pm, "Jason Miller" <ja...@developit.ca> wrote:
> try wrapping your entire webapp.js code in a function and keeping a private reference to the original window object that was available from the load() function:
>
> function wavePrismClient(window) {
>   // just  copy and paste your script into this function
>  
>   // it will call your load function
>   load();
>
> }
>
> function load() {
>   wavePrismClient(window);
>
> }

I'll try it, but I'm not sure how this would be any different then
"_myWindow = window;" in the load event and then using _myWindow
instead of window through out the rest of the code. My current
guess is that the actual window structure must be getting messed up;
as even _myWndow.alert('hi'); will fail once it decided it doesn't
like the window variable. I wonder if I actually link to the
"window.alert()" proc directly if that would continue to work later,
or if the heap/memory pointers are just being totally fubar'd.

Nathan

Jason Miller

unread,
Nov 18, 2009, 6:47:04 PM11/18/09
to mozilla-l...@googlegroups.com
The result would be the same, that is true. The usefulness of the method I described is that it does not require any rewriting of code. I have not personally come across methods or properties disappearing from the window object after time, only the object reference itself. I would be interested to see if your idea works.


Jason Miller
519.872.0797 // developIT // Jason Miller Design
Developer of amoebaOS, Shutterborg, Delitweet & more

On Wed Nov 18 2009 18:39:52 GMT-0500 (EST), Nathan Anderson wrote:
--

You received this message because you are subscribed to the Google Groups "mozilla-labs-prism" group.
To post to this group, send email to mozilla-l...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-prism?hl=.


Nathan Anderson

unread,
Nov 20, 2009, 6:38:12 PM11/20/09
to mozilla-labs-prism

Well, saving the "window" and "this" variables and using them did NOT
solve the issue. However, after a dozen or so "tests" that I could
run when xulrunner got the window variable messed up; one of the test
cases actually worked.

To get around the issue it appears that this works:


function load() {

// Assign the REALLY critical variables
_myWindowContent = window.content;
_myWindowPlatform = window.platform;

// Do rest of load routine.....
}

And then using _myWindowContent to access anything I would
normally have used "window.content". And for added safety I also saved
_myWindowPlatform to access anything under the platform object; since
the "window" variable seems to be completely suspect at this point.
I decided it would be safer to save and replace all "window.*" access
with my "_myWindow*" variables/calls.

Nathan.

Matthew Gertner

unread,
Dec 15, 2009, 11:14:58 AM12/15/09
to mozilla-l...@googlegroups.com
If you have a chance to file a bug about this, that would be great. I
really don't know what the cause is, but I'd like to look into it at
some point.
> --
>
> You received this message because you are subscribed to the Google Groups "mozilla-labs-prism" group.
> To post to this group, send email to mozilla-l...@googlegroups.com.
> To unsubscribe from this group, send email to mozilla-labs-pr...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages