1153088 - Panel SDK element can't communicate in FF38 beta

Status: RESOLVED INVALID

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

Description

[Paul Broman]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36

Steps to reproduce:

Hello.  I am a Yahoo engineer implementing the Yahoo NextGen Toolbar which uses Jetpack (1.16).  In FF37, I can create popups using the 'sdk/panel' element and then have the contentScript passed to the panel send messages back to the main extension using self.port.   In FF38 beta, this only works for about 1s after the popup is generated- after that, calls to self.port do NOT make it back to the main extension.


Actual results:

Calls from self.port in a contentScript for a Panel SDK element don't make it back to the main extension (panel.on callback) except calls made basically immediately after the popup initializes.  It is unclear what triggers the inability for these messages to go through after a certain time.  I can tell you this doesn't happen in FF37.


Expected results:

All calls from self.port in a contentScript for a Panel SDK element should go back to the panel.on callback, not just the first couple of calls within the first second of the popup being launched.

Comment 1

[Paul Broman]

I repro on both Windows + Mac BTW

Comment 2

[Dave Townsend [:mossop]]

Attachment: example code

I've looked at this a little today and been unable to reproduce so far. Attached is the example code I was testing with. It's a simple panel that emits a message once a second. I ran it for 30 seconds on Firefox 37, 38, 39, 40. In all cases messages kept coming until I quit the browser.

Do you have some example code that you should show us that demonstrates the problem?

Comment 3

[Paul Broman]

I'm trying to pare down the code to what is necessary to repro within our client.  It seems that calling 'show' stops the messages from flowing- they flow before the popup is shown (since we build our popups and then show them).  It may be that the popup messaging works if you show FIRST before you do any messaging... I'll try to narrow this down.

Comment 4

[Paul Broman]

Ok, it seems the issue is related to the use of our 'augmented' version of the panel object.  We modified the panel object for a few reasons (having to do with disabling autohide and sending extra events back to us).  Even if I replace the 'augmented' version with the 'plain vanilla' version from Jetpack 1.16 however, it still does not work, seemingly just because I am loading it from a different place.

I will attach sample code for this.

Comment 5

[Paul Broman]

Attachment: bug_1153088.zip

Sample code to repro the issue.  Place 'augment-panel.js' in the same folder with main.js.   augment-panel.js is identical to sdk/panel.js in Jetpack 1.16, EXCEPT for some of the relative paths to includes being fixed up at the top of the file.

Comment 6

[Dave Townsend [:mossop]]

Attachment: panel.js working in Firefox 37-40

So the problem here is that the panel code depends on some low-level SDK modules that change over time as we upgrade Firefox. Normally the panel code is modified to match as well but you're essentially forcing your add-on to use the old panel code with the newer low-level modules. There are a few different ways you could approach this.

One is to simply tell cfx to bundle all the 1.16 SDK modules with your add-on, that way you keep the same version of the low-level modules. That's likely to cause you many problems too though since the reason we often update them is to make them work with newer versions of Firefox.

Another is to switch to a newer version of the panel code to match the newer low-level modules in recent Firefox. I've attached a version that appears to work in Firefox 37-40, I haven't verified on other versions though. This is a stop-gap measure, you can still hit the same problem later on.

The best way to handle this is not to copy the panel code at all and instead extend it. The downside here is that you are more limited by what you can do, you don't have access to the full internals of the panel code but you can replace/extend individual functions and I've created an example that makes a panel that can't be hidden.

Incidentally 1.16 is an older version of the SDK. 1.17 is the most recent release which allows access to more of the available SDK modules and soon JPM will be replacing CFX entirely (

Comment 7

[Dave Townsend [:mossop]]

Attachment: extended panel

Comment 8

[Dave Townsend [:mossop]]

https://blog.mozilla.org/addons/2015/02/26/jpm-replaces-cfx-for-firefox-38/ is the link I meant to add earlier.

Comment 9

[Dave Townsend [:mossop]]

From the previous comments this is essentially invalid in that the code is using low-level modules that have changed.