Community
Participate
Working Groups
Build Identifier: 20111122 nightly build Dojo widget event with remote dojo runtime can not triggered in VE by XULRunner Tested XULRunner 1.9.1.19/3.6.23 in eclise 3.6/3.7 on three different machines. Two of them got this bug. Reproducible: Always Steps to Reproduce: 1. Create a new workspace, config the XULRunner 2. Set the EGL->Rich UI->Appearance to "Mozila" 3. Create a Web Client project and a RUIHandler 4. Open RUIHandler in VE, drag&drop some dojo widget into it. 5. Set event for dojo widget, and it can not be triggered in preview.
Create the Web Client project with Dojo widget version(1.6.1 remote)
Root cause updated: the event works well, only syslib.writestdout with remote dojo runtime doesn't work in VE by XULRunner.
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.
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
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.
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 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
If this fix is ready, please commit it to CVS. If it is not ready, let's set this to 8 I2.
Commit the fix
Blocked by JS Gen bug 368789, will verify this when the blocking issue resolved.
Verified in build 0.8.0.v201201172212
