You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Chris Chabot <ch...@xs4all.nl> on 2008/05/17 15:38:44 UTC

Broken RPC on Firefox 3.0RC1

I just upgraded from FF3b5 (which worked great) to FF3RC1 and i now  
get this message when a gadget attempts to RPC:

Exception... "Not enough arguments [nsIDOMWindowInternal.postMessage]"  
nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS  
frame :: <insert long iframe url>..

Seems there's some chatter about it in the patch that caused this:
https://bugzilla.mozilla.org/show_bug.cgi?id=430251#c18
which forinstance also broke facebook chat it seems:
https://bugzilla.mozilla.org/show_bug.cgi?id=433183

however from what i gather the RC1 behavior is 'correct' and what will  
make the 3.0 release, so it might be good to address this before to  
many people upgraded to RC1 :-)

Changing the trunk/config/container.js to use the legacy (ifpc)  
protocol doesn't help for me (wasn't this removed btw?), however if i  
(quick-and-dirty-workaround) change the rpc.js code to force 'rpc' (by  
doing a relayChannel='rpc' before the switch statement), it at least  
allows me to go back to work again :)

	-- Chris




Re: Broken RPC on Firefox 3.0RC1

Posted by Zhen Wang <wa...@google.com>.
Thank you guys for fixing this over the weekend!

On Sat, May 17, 2008 at 3:06 PM, Chris Chabot <ch...@xs4all.nl> wrote:
> Thanks, good suggestion Kevin. With both the post message and event listener
> modified it's working perfectly again.
>
> Want me to go ahead and commit this or does it need some more work first?
>
> Index: rpc.js
> ===================================================================
> --- rpc.js      (revision 657332)
> +++ rpc.js      (working copy)
> @@ -45,7 +45,7 @@
>                      typeof window.postMessage === 'function' ? 'wpm' :
>                      'ifpc';
>   if (relayChannel === 'dpm' || relayChannel === 'wpm') {
> -    document.addEventListener('message', function(packet) {
> +    window.addEventListener('message', function(packet) {
>       // TODO validate packet.domain for security reasons
>       process(gadgets.json.parse(packet.data));
>     }, false);
> @@ -299,7 +299,7 @@
>         break;
>       case 'wpm': // use window.postMessage
>         var targetWin = targetId === '..' ? parent : frames[targetId];
> -        targetWin.postMessage(rpcData);
> +        targetWin.postMessage(rpcData, "*");
>         break;
>       default: // use 'ifpc' as a fallback mechanism
>         var relay = gadgets.rpc.getRelayUrl(targetId);
>
> On May 17, 2008, at 9:12 PM, Kevin Brown wrote:
>
>> On Sat, May 17, 2008 at 11:26 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>>
>>> Yea i also read the spec page and tried the "*", that doesn't fix it
>>> unfortunately :)
>>
>>
>> This is a necessary change anyway, since the spec now requires it.
>>
>> Upon further inspection, I believe the problem is the event handler. We're
>> currently registering the message handler on document, but now the message
>> is dispatched to window instead of document, so document never sees it.
>>
>> To fix this, we should register the event on window instead of document.
>> window will catch it even if it's dispatched to document (due to
>> bubbling),
>> so this will work even for Opera (which still uses document.postMessage).
>>
>> Can you try this?
>
>

Re: Broken RPC on Firefox 3.0RC1

Posted by Kevin Brown <et...@google.com>.
Looks good to me. Nothing like vicarious debugging :).

On Sat, May 17, 2008 at 3:06 PM, Chris Chabot <ch...@xs4all.nl> wrote:

> Thanks, good suggestion Kevin. With both the post message and event
> listener modified it's working perfectly again.
>
> Want me to go ahead and commit this or does it need some more work first?
>
> Index: rpc.js
> ===================================================================
> --- rpc.js      (revision 657332)
> +++ rpc.js      (working copy)
> @@ -45,7 +45,7 @@
>                      typeof window.postMessage === 'function' ? 'wpm' :
>                      'ifpc';
>   if (relayChannel === 'dpm' || relayChannel === 'wpm') {
> -    document.addEventListener('message', function(packet) {
> +    window.addEventListener('message', function(packet) {
>       // TODO validate packet.domain for security reasons
>       process(gadgets.json.parse(packet.data));
>     }, false);
> @@ -299,7 +299,7 @@
>         break;
>       case 'wpm': // use window.postMessage
>         var targetWin = targetId === '..' ? parent : frames[targetId];
> -        targetWin.postMessage(rpcData);
> +        targetWin.postMessage(rpcData, "*");
>         break;
>       default: // use 'ifpc' as a fallback mechanism
>         var relay = gadgets.rpc.getRelayUrl(targetId);
>
>
> On May 17, 2008, at 9:12 PM, Kevin Brown wrote:
>
>  On Sat, May 17, 2008 at 11:26 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>>
>>  Yea i also read the spec page and tried the "*", that doesn't fix it
>>> unfortunately :)
>>>
>>
>>
>> This is a necessary change anyway, since the spec now requires it.
>>
>> Upon further inspection, I believe the problem is the event handler. We're
>> currently registering the message handler on document, but now the message
>> is dispatched to window instead of document, so document never sees it.
>>
>> To fix this, we should register the event on window instead of document.
>> window will catch it even if it's dispatched to document (due to
>> bubbling),
>> so this will work even for Opera (which still uses document.postMessage).
>>
>> Can you try this?
>>
>
>

Re: Broken RPC on Firefox 3.0RC1

Posted by Chris Chabot <ch...@xs4all.nl>.
Thanks, good suggestion Kevin. With both the post message and event  
listener modified it's working perfectly again.

Want me to go ahead and commit this or does it need some more work  
first?

Index: rpc.js
===================================================================
--- rpc.js      (revision 657332)
+++ rpc.js      (working copy)
@@ -45,7 +45,7 @@
                       typeof window.postMessage === 'function' ?  
'wpm' :
                       'ifpc';
    if (relayChannel === 'dpm' || relayChannel === 'wpm') {
-    document.addEventListener('message', function(packet) {
+    window.addEventListener('message', function(packet) {
        // TODO validate packet.domain for security reasons
        process(gadgets.json.parse(packet.data));
      }, false);
@@ -299,7 +299,7 @@
          break;
        case 'wpm': // use window.postMessage
          var targetWin = targetId === '..' ? parent : frames[targetId];
-        targetWin.postMessage(rpcData);
+        targetWin.postMessage(rpcData, "*");
          break;
        default: // use 'ifpc' as a fallback mechanism
          var relay = gadgets.rpc.getRelayUrl(targetId);

On May 17, 2008, at 9:12 PM, Kevin Brown wrote:

> On Sat, May 17, 2008 at 11:26 AM, Chris Chabot <ch...@xs4all.nl>  
> wrote:
>
>> Yea i also read the spec page and tried the "*", that doesn't fix it
>> unfortunately :)
>
>
> This is a necessary change anyway, since the spec now requires it.
>
> Upon further inspection, I believe the problem is the event handler.  
> We're
> currently registering the message handler on document, but now the  
> message
> is dispatched to window instead of document, so document never sees  
> it.
>
> To fix this, we should register the event on window instead of  
> document.
> window will catch it even if it's dispatched to document (due to  
> bubbling),
> so this will work even for Opera (which still uses  
> document.postMessage).
>
> Can you try this?


Re: Broken RPC on Firefox 3.0RC1

Posted by Kevin Brown <et...@google.com>.
On Sat, May 17, 2008 at 11:26 AM, Chris Chabot <ch...@xs4all.nl> wrote:

> Yea i also read the spec page and tried the "*", that doesn't fix it
> unfortunately :)


This is a necessary change anyway, since the spec now requires it.

Upon further inspection, I believe the problem is the event handler. We're
currently registering the message handler on document, but now the message
is dispatched to window instead of document, so document never sees it.

To fix this, we should register the event on window instead of document.
window will catch it even if it's dispatched to document (due to bubbling),
so this will work even for Opera (which still uses document.postMessage).

Can you try this?

Re: Broken RPC on Firefox 3.0RC1

Posted by Chris Chabot <ch...@xs4all.nl>.
Yea i also read the spec page and tried the "*", that doesn't fix it  
unfortunately :)

On May 17, 2008, at 8:24 PM, Kevin Brown wrote:

> Note: to be truly correct, it looks like targetUri should ideally be  
> the
> prefix of the actual target window. Something like: http://container- 
> host/*.
> I'll have to read the spec more thoroughly to see if this is correct.
>
> On Sat, May 17, 2008 at 11:21 AM, Kevin Brown <et...@google.com> wrote:
>
>> On Sat, May 17, 2008 at 6:38 AM, Chris Chabot <ch...@xs4all.nl>  
>> wrote:
>>
>>> I just upgraded from FF3b5 (which worked great) to FF3RC1 and i  
>>> now get
>>> this message when a gadget attempts to RPC:
>>>
>>> Exception... "Not enough arguments  
>>> [nsIDOMWindowInternal.postMessage]"
>>> nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location:  
>>> "JS frame ::
>>> <insert long iframe url>..
>>>
>>> Seems there's some chatter about it in the patch that caused this:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=430251#c18
>>> which forinstance also broke facebook chat it seems:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=433183
>>>
>>> however from what i gather the RC1 behavior is 'correct' and what  
>>> will
>>> make the 3.0 release, so it might be good to address this before  
>>> to many
>>> people upgraded to RC1 :-)
>>
>>
>> They actually just fixed it so that postMessage was async. Safari and
>> Opera's implementations were already async, so I'm surprised this  
>> worked in
>> one place but not the other.
>>
>> Changing the trunk/config/container.js to use the legacy (ifpc)  
>> protocol
>>> doesn't help for me (wasn't this removed btw?), however if i
>>
>>
>> useLegacyProtocol just changes the wire format for cases when ifpc  
>> needs to
>> be used instead of one of the more sophisticated techniques. The  
>> only reason
>> that this exists is to address cases where it needs to be forced to  
>> get
>> around bugs or the like -- such as this one. It should work after  
>> Zhen's
>> recent patch.
>>
>>
>>> (quick-and-dirty-workaround) change the rpc.js code to force  
>>> 'rpc' (by
>>> doing a relayChannel='rpc' before the switch statement), it at  
>>> least allows
>>> me to go back to work again :)
>>
>>
>> As near as I can tell, this is actually an unrelated change. The   
>> error
>> being thrown is indicating that there aren't enough arguments being  
>> passed
>> to postMessage. The current spec (recently updated) REQUIRES the  
>> second
>> parameter, targetUri. The older version of this spec did not  
>> require the
>> second parameter.
>>
>> The workaround here, I believe, is to pass "*" as the second  
>> parameter. I
>> can't seem to find an RC1 build that works on my machine (and  
>> compiling FF
>> from source is painful), so I'll leave it to someone who already  
>> has it
>> installed to give it a shot. If nobody else can verify that this  
>> works, I
>> can dig up a windows machine from somewhere and try it on monday.
>>
>>
>>>
>>>       -- Chris
>>>
>>>
>>>
>>>
>>


Re: Broken RPC on Firefox 3.0RC1

Posted by Kevin Brown <et...@google.com>.
Note: to be truly correct, it looks like targetUri should ideally be the
prefix of the actual target window. Something like: http://container-host/*.
I'll have to read the spec more thoroughly to see if this is correct.

On Sat, May 17, 2008 at 11:21 AM, Kevin Brown <et...@google.com> wrote:

> On Sat, May 17, 2008 at 6:38 AM, Chris Chabot <ch...@xs4all.nl> wrote:
>
>> I just upgraded from FF3b5 (which worked great) to FF3RC1 and i now get
>> this message when a gadget attempts to RPC:
>>
>> Exception... "Not enough arguments [nsIDOMWindowInternal.postMessage]"
>> nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame ::
>> <insert long iframe url>..
>>
>> Seems there's some chatter about it in the patch that caused this:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=430251#c18
>> which forinstance also broke facebook chat it seems:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=433183
>>
>> however from what i gather the RC1 behavior is 'correct' and what will
>> make the 3.0 release, so it might be good to address this before to many
>> people upgraded to RC1 :-)
>
>
> They actually just fixed it so that postMessage was async. Safari and
> Opera's implementations were already async, so I'm surprised this worked in
> one place but not the other.
>
> Changing the trunk/config/container.js to use the legacy (ifpc) protocol
>> doesn't help for me (wasn't this removed btw?), however if i
>
>
> useLegacyProtocol just changes the wire format for cases when ifpc needs to
> be used instead of one of the more sophisticated techniques. The only reason
> that this exists is to address cases where it needs to be forced to get
> around bugs or the like -- such as this one. It should work after Zhen's
> recent patch.
>
>
>> (quick-and-dirty-workaround) change the rpc.js code to force 'rpc' (by
>> doing a relayChannel='rpc' before the switch statement), it at least allows
>> me to go back to work again :)
>
>
> As near as I can tell, this is actually an unrelated change. The  error
> being thrown is indicating that there aren't enough arguments being passed
> to postMessage. The current spec (recently updated) REQUIRES the second
> parameter, targetUri. The older version of this spec did not require the
> second parameter.
>
> The workaround here, I believe, is to pass "*" as the second parameter. I
> can't seem to find an RC1 build that works on my machine (and compiling FF
> from source is painful), so I'll leave it to someone who already has it
> installed to give it a shot. If nobody else can verify that this works, I
> can dig up a windows machine from somewhere and try it on monday.
>
>
>>
>>        -- Chris
>>
>>
>>
>>
>

Re: Broken RPC on Firefox 3.0RC1

Posted by Kevin Brown <et...@google.com>.
On Sat, May 17, 2008 at 6:38 AM, Chris Chabot <ch...@xs4all.nl> wrote:

> I just upgraded from FF3b5 (which worked great) to FF3RC1 and i now get
> this message when a gadget attempts to RPC:
>
> Exception... "Not enough arguments [nsIDOMWindowInternal.postMessage]"
> nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame ::
> <insert long iframe url>..
>
> Seems there's some chatter about it in the patch that caused this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=430251#c18
> which forinstance also broke facebook chat it seems:
> https://bugzilla.mozilla.org/show_bug.cgi?id=433183
>
> however from what i gather the RC1 behavior is 'correct' and what will make
> the 3.0 release, so it might be good to address this before to many people
> upgraded to RC1 :-)


They actually just fixed it so that postMessage was async. Safari and
Opera's implementations were already async, so I'm surprised this worked in
one place but not the other.

Changing the trunk/config/container.js to use the legacy (ifpc) protocol
> doesn't help for me (wasn't this removed btw?), however if i


useLegacyProtocol just changes the wire format for cases when ifpc needs to
be used instead of one of the more sophisticated techniques. The only reason
that this exists is to address cases where it needs to be forced to get
around bugs or the like -- such as this one. It should work after Zhen's
recent patch.


> (quick-and-dirty-workaround) change the rpc.js code to force 'rpc' (by
> doing a relayChannel='rpc' before the switch statement), it at least allows
> me to go back to work again :)


As near as I can tell, this is actually an unrelated change. The  error
being thrown is indicating that there aren't enough arguments being passed
to postMessage. The current spec (recently updated) REQUIRES the second
parameter, targetUri. The older version of this spec did not require the
second parameter.

The workaround here, I believe, is to pass "*" as the second parameter. I
can't seem to find an RC1 build that works on my machine (and compiling FF
from source is painful), so I'll leave it to someone who already has it
installed to give it a shot. If nobody else can verify that this works, I
can dig up a windows machine from somewhere and try it on monday.


>
>        -- Chris
>
>
>
>