Philip Chee wrote: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!
Philip Chee wrote: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).
There is a patch in Bug 1071048 - Addon SDK changes to allow Ghostery to work in SeaMonkey.neophil wrote:Though, is there a patch or something to add/modify somewhere to get back Ghostery work with SM 2.29/2.29.1 ??
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)
neophil wrote:Not sure to understand what yo mean ...
Well, any link to download this patch and install it ?
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.Lemon Juice wrote:neophil wrote: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.
Philip Chee wrote:Unpack the omni.jar file. Fix three files (use your favourite text editor). Repack omni.jar. And Bob's your uncle.
Lemon Juice wrote: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
patrickjdempsey wrote:Lemon Juice wrote: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 wrote: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.
Lemon Juice wrote: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.
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".Lemon Juice wrote: 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?
Code: Select all
clipboard.js
context-menu.js
panel.js
events.js
selection.js
widget.js
Code: Select all
places/events.js
places/favicon.js
places/history.js
places/*/*
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');
Code: Select all
!!PrivateBrowsingUtils && ! is('Fennec');
Code: Select all
!!PrivateBrowsingUtils && isOneOf(['Firefox', 'SeaMonkey'])
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
}
};
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
}
};
Philip Chee wrote:Lemon Juice wrote: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.
Philip Chee wrote: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".Lemon Juice wrote: 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?
Code: Select all
module.metadata = {
"stability": "stable",
"engines": {
// TODO Fennec support Bug 788334
"Firefox": "*"
}
};
Code: Select all
module.metadata = {
"stability": "stable",
"engines": {
// TODO Fennec support Bug 788334
"Firefox": "*",
"SeaMonkey" : "*" // SeaMonkey is not officially supported
}
};
Philip Chee wrote: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.
Philip Chee wrote:I've done a quick grep for "Firefox" against the addon-SDK excluding comments and other trivia.
[...]