Closed Bug 910972 Opened 11 years ago Closed 11 years ago

Page mod script to content script communication not working

Categories

(Add-on SDK Graveyard :: General, defect)

Product:
Add-on SDK Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: brettz9, Assigned: jsantell)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130826142034

Steps to reproduce:

1. Install the simple test case at https://builder.addons.mozilla.org/package/201155/latest/
2. Visit http://brett-zamir.me/tests/webappfind-test2.html and confirm that the page should be sending a postMessage properly--i.e., with targetOrigin set to "window.location.href" (or visit http://brett-zamir.me/tests/webappfind2.html for a postMessage call with the targetOrigin set to "*").
3. Look at the Error console

(Question also asked on http://stackoverflow.com/questions/18444548/ff-addon-sdk-page-mod-script-to-content-script-communication-not-working#comment27120011_18444548 )


Actual results:

It only reports the message "it gets here at least"


Expected results:

It should have also reported "would be good if it got here:webappfind" (since as per https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/guides/content-scripts/communicating-with-other-scripts.html#Using%20the%20DOM%20postMessage%20API , communications should be allowed in the manner I used in the test add-on).
I should mention that http://brett-zamir.me/tests/webappfind3.html works (need to enable popup windows) as does http://brett-zamir.me/tests/webappfind-iframeHolder.html (if you click "This Frame->Reload Frame").

Also, the custom event approach mentioned at https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/guides/content-scripts/communicating-with-other-scripts.html#Using%20Custom%20DOM%20Events is also not working according to my test at https://builder.addons.mozilla.org/package/201688/latest/ . This appears to be the case whether using the new syntax as used at http://brett-zamir.me/tests/webappfind-customEvent.html or the older syntax as demonstrated in the SDK docs and used at http://brett-zamir.me/tests/webappfind-createCustomEvent.html
And yet another thing...I'm not able to get communication in the other direction (content script to a page), and I can prepare a test case for that as well (though I'd appreciate it if someone could first confirm whether postMessage is indeed supposed to work between a worker returned by tab.attach and the page located at tab.url or only between page mod workers and their pages)...
Jordan, can you take a look at this?
Assignee: nobody → jsantell
Brett, I am able to communicate in both directions, as per the dev guide here: https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/guides/content-scripts/communicating-with-other-scripts.html#Using%20the%20DOM%20postMessage%20API

I'm guessing the issue you're seeing in the first comment is because the page fires a postMessage immediately before the page-mod is attached (it's firing within the <head> tag, so it's even before it's own DOM is loaded), whereas in the example, it's based off of a button click -- you could also have the page-mod script communicate to the mainpage when it's ready to communicate with. Both directions work for me (even using "*" or my own host name) once the page-mod is loaded -- see if that fixes this issue, and if not, let me know
Flags: needinfo?(brettz9)
Sheesh--I guess that was it--maybe I thought contentScriptWhen's default was "start" or something... Yes, it does appear to be working now, thank you very much....
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Flags: needinfo?(brettz9)
Resolution: --- → INVALID
Great!
You need to log in before you can comment on or make changes to this bug.