Hello. I am an engineer at Yahoo! and I work on Yahoo! Axis. Yahoo! Axis facilities some layers of communication between the extension client (created using Jetpack) and the code we inject in page (and it's child <iframe>s) by using custom events, created using simple DOM event calls like:
var evt= document.createEvent("Event");
evt.initEvent("NanoBridgeEvt", true, true);
On FF16 Beta, this code does not work anymore. The call to initEvent throws an exception, and the exception is malformed (the object is empty).
We found that initEvent calls do not throw from <iframes> created within the injection region. It only throws from the same level as the document itself. Even in this case, the recipient of the call sees a malformed event object.
I was able to work around this by using a CustomEvent() object as documented at https://developer.mozilla.org/en-US/docs/DOM/Event/CustomEvent?redirectlocale=en-US&redirectslug=DOM%2FcustomEvent. However, even then the recipient of the event gets a malformed event object (object is empty, no members).
This is a high priority issue for Yahoo! as this bug breaks our Yahoo! Axis extension which we are heavily promoting. We have a workaround for the issue but we would prefer to see Mozilla fix what we believe to be a bug in FF16 beta before you guys push it live for autoupdates.
cc'ing mossop and gavin: Do do guys know someone who could help here? Thanks!
Created attachment 670436 [details]
Pull request 603
Here is a testcase that can help diging into this.
I wasn't able to see it failing on Nightly nor current Firefox beta.
(In reply to Alexandre Poirot (:ochameau) from comment #2)
> Created attachment 670436 [details]
> Pull request 603
> Here is a testcase that can help diging into this.
> I wasn't able to see it failing on Nightly nor current Firefox beta.
Is this a content-proxy issue? Those are enabled in Fx 16 and disabled in Fx 17 (beta)
(In reply to Paul Broman from comment #0)
> This is a high priority issue for Yahoo! as this bug breaks our Yahoo! Axis
> extension which we are heavily promoting. We have a workaround for the
> issue but we would prefer to see Mozilla fix what we believe to be a bug in
> FF16 beta before you guys push it live for autoupdates.
I agree this is a high priority issue, however we are having some issues reproducing the problem. What would help us most is if you could provide a reduced test case that exhibits the problem? If you need to, feel free to contact me directly.
I contacted you directly, Jeff.
Is there some reason you can't add the relevant info to the bug? Re-adding needinfo flag until we have a public testcase.
I've got the info and am looking into it, will report back as events warrant.
We need to know if this is a regression that only affects the SDK, or if it is a regression in Firefox that could have an impact on other add-ons.
We'll remain on the lookout for other add-on regressions.
After some investigation by Kris, it looks like this is an issue related to using an older version of the SDK, although I would like to get confirmation from Paul or someone from his team before we close this bug.
Will not track for 17 in that case, please renominate if comment 10 is incorrect.
Since this appears to be an old SDK problem and the developer has worked around it anyway, I don't think there's any reason to keep this open. Please reopen if the problem turns out to be anything else.
Just FYI, this bug did not repro once I repacked our extension with Jetpack 1.10.
Comment on attachment 670436 [details]
Pull request 603
Another test patch landed.