SeaMonkey and Ghostery

[Lemon Juice]

Well that's the theory anyway. Whether those particular modules are really SeaMonkey compatible is another question. But we do try to implement the more important Firefox APIs (Australis excepted).

Sounds good enough!

[neophil]

Though, is there a patch or something to add/modify somewhere to get back Ghostery work with SM 2.29/2.29.1 ??

[Philip Chee]

Though, is there a patch or something to add/modify somewhere to get back Ghostery work with SM 2.29/2.29.1 ??

There is a patch in Bug 1071048 - Addon SDK changes to allow Ghostery to work in SeaMonkey.
http://logs.glob.uno/?c=mozilla%23seamonkey&s=24+Sep+2014&e=24+Sep+2014#c626150

Code: Select all

19:03   RattyAway   IRIXuser: well once I fixed the SDK the toolbar button problem went away
19:03   IRIXuser   i'm also having trouble finding where seamonkey puts the SDK
19:04   IRIXuser   as I only see a copy of SDK stuff in the RES XPI
19:06   RattyAway   IRIXuser: It's inside the omni.ja
19:07   RattyAway   in /modules/commonjs/sdk/
19:11   IRIXuser   now i just need to find a way to open that
19:12   IRIXuser   how long ago was the SDK integrated? as in 2.26.1 at least I made manual changes to the SDK contained in the RES XPI to make things work right
19:12   IRIXuser   speciifically to "loader/cuddlefish.js"
19:21   bmcdermott   RattyAway: so everything in Ghostery works?
19:22   RattyAway   IRIXuser: 2013-02-01 13:17:34 -0800 (19 months ago)

Phil

[neophil]

Not sure to understand what yo mean ...
Well, any link to download this patch and install it ?

Thanks in advance

[Lemon Juice]

Not sure to understand what yo mean ...
Well, any link to download this patch and install it ?

As I understand it this is not a patch to Ghostery but to SM source code. In other words, you either have to wait for a new SM release with this patch or you would have to patch the source code yourself and then compile SM.

[Philip Chee]

Not sure to understand what yo mean ...
Well, any link to download this patch and install it ?

As I understand it this is not a patch to Ghostery but to SM source code. In other words, you either have to wait for a new SM release with this patch or you would have to path the source code yourself and then compile SM.

Ha! no compile needed. Unpack the omni.jar file. Fix three files (use your favourite text editor). Repack omni.jar. And Bob's your uncle.

Phil

[neophil]

Humf ? omni.ja file found here (i returned to SM 2.26.1)
Which three files are to be modified for 2.29 / 2.29.1 ??

[Lemon Juice]

Unpack the omni.jar file. Fix three files (use your favourite text editor). Repack omni.jar. And Bob's your uncle.

Interesting, I've never tinkered with omni.jar so I decided to give it a try. I applied the 3 patches from that bug report and indeed Ghostery worked! There were some deprecated errors in the console but perhaps they are harmless, I don't know.

However, one thing is troubling - when I tried removing the engines attribute, like the reviewer wanted you to do, then this did not work. Leaving empty engines object also failed. Only adding "SeaMonkey": "*" did indeed cause the modules to work in SM. Some solution must be found since the reviewer doesn't want to accept the literal addition of SeaMonkey

As a separate experiment I added SM compatibility in the same way to modules context-menu.js, selection.js and panel.js - and the result was I was able to install and run QrCodeR - an extension that normally won't install in SM. I'm wondering - even if these modules are not tested in SM then enabling them opens the door to compatibility of many Fx extensions that couldn't be ported to SM otherwise. If the SDK developers won't accept the SeaMonkey entry in engines then perhaps a "patched" SDK could be shipped with SM, meaning with the added engines entry?

[patrickjdempsey]

However, one thing is troubling - when I tried removing the engines attribute, like the reviewer wanted you to do, then this did not work. Leaving empty engines object also failed. Only adding "SeaMonkey": "*" did indeed cause the modules to work in SM. Some solution must be found since the reviewer doesn't want to accept the literal addition of SeaMonkey

So why have an enumerated list of supported applications if it's not allowed to be modified? Seems like that bit just needs to go away altogether. Especially since it totally breaks with the Open Source objective of this stuff.

[Lemon Juice]

However, one thing is troubling - when I tried removing the engines attribute, like the reviewer wanted you to do, then this did not work. Leaving empty engines object also failed. Only adding "SeaMonkey": "*" did indeed cause the modules to work in SM. Some solution must be found since the reviewer doesn't want to accept the literal addition of SeaMonkey

So why have an enumerated list of supported applications if it's not allowed to be modified? Seems like that bit just needs to go away altogether. Especially since it totally breaks with the Open Source objective of this stuff.

Sorry, it was my mistake - yesterday I made a typo in applying the patch and left one curly bracket that shouldn't be there. So after removing the engines correctly Ghostery works fine in SM. The patch seems to be pushed already: Bug 1071048 (if mozilla35 means SeaMonkey 2.32 then it will not be soon in a stable release).

Ghostery seems to be fine now. Now how do we go about other extensions and enabling other sdk modules? Philip, what do you think about it? Submit another bug? I think it would be a worthwhile change that would automatically turn on compatibility with many other Fx extensions based on sdk - see my experiment two posts above.

[Philip Chee]

Ghostery seems to be fine now. Now how do we go about other extensions and enabling other sdk modules? Philip, what do you think about it? Submit another bug? I think it would be a worthwhile change that would automatically turn on compatibility with many other Fx extensions based on sdk - see my experiment two posts above.

I'm being conservative, I've only turned on the modules that I definitely know works in SeaMonkey by testing against an extension. With Ghostery things work (without any noticeable problems) by "turning on" tabs.js, tabs/tab.js, and /windows.js

As a separate experiment I added SM compatibility in the same way to modules context-menu.js, selection.js and panel.js - and the result was I was able to install and run QrCodeR - an extension that normally won't install in SM.

So now we know these modules do work without errors (by testing against QrCodeR) we can file another bug.

I'm wondering - even if these modules are not tested in SM then enabling them opens the door to compatibility of many Fx extensions that couldn't be ported to SM otherwise. If the SDK developers won't accept the SeaMonkey entry in engines then perhaps a "patched" SDK could be shipped with SM, meaning with the added engines entry?

Their focus is Firefox - that's what their paid to do. My analysis of the situation is that they don't want people to think that SeaMonkey support is official. They know nothing about SeaMonkey and really don't want to answer support questions. They are not averse to SeaMonkey compatibility patches and they have accepted at least one (to my knowledge) SeaMonkey tweak before Ghostery. They are more likely to accept patches if we can say "yeah we tested these changes against [name of SDK extension] and everything works without errors".

When we ship a new SeaMonkey release we create a release branch (relbranch) on both comm-central, and mozilla-central. MoCo doesn't care what we put in our release branch. So going forward, the worst case scenario is that we apply some patches against the SeaMonkey release branch on mozilla-central. But then someone will have to remember to do this every time, so I hope we don't have to resort to this.

Phil

Notes: Also grepping through the source code there are small bits of code that are there to explicitly support SeaMonkey and/or Thunderbird. I think these date back to when the SDK wasn't included in Firefox and instead had to be packed into the XPI.

[Philip Chee]

I've done a quick grep for "Firefox" against the addon-SDK excluding comments and other trivia.

Code: Select all

clipboard.js
context-menu.js
panel.js
events.js
selection.js
widget.js

These are very likely to work in SeaMonkey. With the exception of context-menu.js none of the other modules are application specific. There should be no problems with context-menu.js as we closely match the API with Firefox to make it easier to port Firefox extensions to SeaMonkey.

Code: Select all

places/events.js
places/favicon.js
places/history.js
places/*/*

Most likely to work without problems in SeaMonkey. But I prefer to confirm this by running a SDK based extension to exercise those code paths.

Code: Select all

private-browsing/utils.js

// checks that per-window private browsing is implemented
let isWindowPBSupported = exports.isWindowPBSupported =
                          !!PrivateBrowsingUtils && is('Firefox');
.......................................................^^^^^^^^^
// checks that per-tab private browsing is implemented
let isTabPBSupported = exports.isTabPBSupported =
                       !!PrivateBrowsingUtils && is('Fennec');

SeaMonkey has per-window private browsing and the above should work except for that silly check. We could do something like:

Code: Select all

!!PrivateBrowsingUtils && ! is('Fennec');

or

Code: Select all

!!PrivateBrowsingUtils && isOneOf(['Firefox', 'SeaMonkey'])

Australis:

Code: Select all

ui.js <-- looks like Australis which SeaMonkey has no plans to support.
ui/*/*

module.metadata = {
  'stability': 'experimental',
  'engines': {
    'Firefox': '> 28' <-- looks like Australis
  }
};

Phil

[Philip Chee]

Australis:

Code: Select all

ui.js <-- looks like Australis which SeaMonkey has no plans to support.
ui/*/*

module.metadata = {
  'stability': 'experimental',
  'engines': {
    'Firefox': '> 28' <-- looks like Australis
  }
};

I'd have to talk to the addon-SDK people but it should be possible to revive the pre-Australis code and bracket it in a notAustralis section.

Phil

[Lemon Juice]

As a separate experiment I added SM compatibility in the same way to modules context-menu.js, selection.js and panel.js - and the result was I was able to install and run QrCodeR - an extension that normally won't install in SM.

So now we know these modules do work without errors (by testing against QrCodeR) we can file another bug.

Ok, I'll try testing some other sdk extensions within the next few days so probably we could consolidate more patches into a single bug. I've only tested QrCodeR to see if this procedure has any chance of success but I'm sure more modules could be enabled for SM.

I'm wondering - even if these modules are not tested in SM then enabling them opens the door to compatibility of many Fx extensions that couldn't be ported to SM otherwise. If the SDK developers won't accept the SeaMonkey entry in engines then perhaps a "patched" SDK could be shipped with SM, meaning with the added engines entry?

Their focus is Firefox - that's what their paid to do. My analysis of the situation is that they don't want people to think that SeaMonkey support is official. They know nothing about SeaMonkey and really don't want to answer support questions. They are not averse to SeaMonkey compatibility patches and they have accepted at least one (to my knowledge) SeaMonkey tweak before Ghostery. They are more likely to accept patches if we can say "yeah we tested these changes against [name of SDK extension] and everything works without errors".

OK, this should be good enough, however I think removing the "engines" object will not always be possible like in the case of Ghostery, for example context-menu.js is not intended for Fennec:

Code: Select all

module.metadata = {
  "stability": "stable",
  "engines": {
    // TODO Fennec support Bug 788334
    "Firefox": "*"
  }
};

So maybe this could be acceptable for the sdk reviewers:

Code: Select all

module.metadata = {
  "stability": "stable",
  "engines": {
    // TODO Fennec support Bug 788334
    "Firefox": "*",
    "SeaMonkey" : "*" // SeaMonkey is not officially supported
  }
};

When we ship a new SeaMonkey release we create a release branch (relbranch) on both comm-central, and mozilla-central. MoCo doesn't care what we put in our release branch. So going forward, the worst case scenario is that we apply some patches against the SeaMonkey release branch on mozilla-central. But then someone will have to remember to do this every time, so I hope we don't have to resort to this.

Sure. Although adding SeaMonkey to "engines" could be easily (I suppose) automated during building SM it's always best to avoid having to do this.

[Lemon Juice]

I've done a quick grep for "Firefox" against the addon-SDK excluding comments and other trivia.
[...]

Thanks, this should make my testing easier if I stumble upon an extension that uses any of these modules.