Bug 364540

Comment 1 Xin Wu 2011-11-23 03:23:42 EST

Create the Web Client project with Dojo widget version(1.6.1 remote)

Comment 2 Xin Wu 2011-11-23 04:02:42 EST

Root cause updated: the event works well, only syslib.writestdout with remote dojo runtime doesn't work in VE by XULRunner.

Comment 3 Tony Chen 2011-11-23 04:08:48 EST

Jiyong, please take a look to see if there's a obvious bug there. It looks significant to me. I always use writeStderr & writeStdout when developing. xulrunner is also the main render engine we are supporting. Google runtime might not be as popular as local runtime (since it's not the default), but without this problem being fixed, Google runtime users will hit problem quite easily. 

I'm wondering if this is a single issue just for writeStderr or may have wider impact.

Comment 4 Huang Ji Yong 2011-11-23 09:31:07 EST

Created attachment 207419 [details]
Fix

Reason:
The loading sequence is different between RBD and EDT. The Google runtime don't have to override the runtime function again.
egl.println is overrided and does not roll back to original state.
Risk:
It affects the application using Google runtime, may need more testing.
Customer Impact:
If it is not fixed, user cannot use syslib.writestdout/writestderror
Test:
Dojo Sample in Google Runtime, has a same defect before applying this fix

Comment 5 Jing Qian 2011-11-23 11:31:04 EST

Brian, I vote to defer this defect, based on the description below, seems there is bigger issue with using dojo runtime, I rather say we have known issues with dojo runtime than having the fix introduce other regressions.

Comment 6 Brian Svihovec 2011-11-23 22:02:36 EST

Changing to P3 and deferring to future.  

I am told that applications with Google Remote work, and that the issue is just with egl.println.  Changing the loading scheme for Google Remote at this point is too risky.  Users can avoid this issue by using Google Local for development.

Ji Yong, regarding the patch, can you explain why egl.println was being disabled before the patch?  It looks like it should have been reset if egl.localeInfo is not null, so I am guessing that egl.localeInfo is null?  At the same time, it also looks like the handler should not be constructed at all if egl.localeInfo is null, but the application still appears to run?

Comment 7 Huang Ji Yong 2011-11-25 02:24:11 EST

(In reply to comment #6)
> Changing to P3 and deferring to future.  
> 
> I am told that applications with Google Remote work, and that the issue is just
> with egl.println.  Changing the loading scheme for Google Remote at this point
> is too risky.  Users can avoid this issue by using Google Local for
> development.
> 
> Ji Yong, regarding the patch, can you explain why egl.println was being
> disabled before the patch?  It looks like it should have been reset if
> egl.localeInfo is not null, so I am guessing that egl.localeInfo is null?  At
> the same time, it also looks like the handler should not be constructed at all
> if egl.localeInfo is null, but the application still appears to run?

In EDT, when includeDojo.html is running, egl.println is undefined. It seems the google runtime in chrome is loaded after the runtime file is loaded. So this lines will be executed
if (egl.localeInfo) { // true in chrome, false in IE
   egl.println = egl.oldPrintln; //egl.oldPrintln is undefined

So the egl.println is set to undefined in chrome

Comment 8 Brian Svihovec 2012-01-12 16:23:40 EST

If this fix is ready, please commit it to CVS.  If it is not ready, let's set this to 8 I2.

Comment 9 Huang Ji Yong 2012-01-15 06:26:09 EST

Commit the fix

Comment 10 Xin Wu 2012-01-17 01:07:07 EST

Blocked by JS Gen bug 368789, will verify this when the blocking issue resolved.

Comment 11 Xin Wu 2012-01-18 03:29:04 EST

Verified in build 0.8.0.v201201172212