MozillaZine

SeaMonkey and Ghostery

User Help for Seamonkey and Mozilla Suite
Lemon Juice
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 23rd, 2014, 2:48 pm

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!
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

neophil

User avatar
 
Posts: 35
Joined: August 28th, 2014, 8:00 am

Post Posted September 25th, 2014, 5:03 am

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

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted September 25th, 2014, 8:17 am

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 ??
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

User avatar
 
Posts: 35
Joined: August 28th, 2014, 8:00 am

Post Posted September 25th, 2014, 8:39 am

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

Thanks in advance

Lemon Juice
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 25th, 2014, 9:34 am

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 patch the source code yourself and then compile SM.
Last edited by Lemon Juice on October 1st, 2014, 7:40 am, edited 1 time in total.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted September 25th, 2014, 9:58 am

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.
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

User avatar
 
Posts: 35
Joined: August 28th, 2014, 8:00 am

Post Posted September 25th, 2014, 12:41 pm

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
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 25th, 2014, 2:11 pm

Philip Chee wrote: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 :-k :?:

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?
Last edited by Lemon Juice on September 26th, 2014, 3:39 am, edited 1 time in total.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

patrickjdempsey

User avatar
 
Posts: 23734
Joined: October 23rd, 2008, 11:43 am
Location: Asheville NC

Post Posted September 25th, 2014, 5:18 pm

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 :-k :?:


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.
Tip of the day: If it has "toolbar" in the name, it's crap.
What my avatar is about: https://addons.mozilla.org/en-US/seamonkey/addon/sea-fox/

Lemon Juice
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 26th, 2014, 3:35 am

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 :-k :?:


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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Philip Chee

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted September 29th, 2014, 8:23 am

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.

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
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.
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?
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

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted September 29th, 2014, 8:44 am

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: :x :x :x
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

User avatar
 
Posts: 6475
Joined: March 1st, 2005, 3:03 pm

Post Posted September 29th, 2014, 8:53 am

Australis: :x :x :x
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
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 29th, 2014, 8:59 am

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.

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.

Philip Chee wrote:
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?
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
  }
};


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.

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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Lemon Juice
 
Posts: 788
Joined: June 1st, 2006, 9:41 am

Post Posted September 29th, 2014, 9:17 am

Philip Chee wrote: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.
*** SeaMonkey — weird name, sane interface, modern bowels ***
Mouse Gestures for SeaMonkey/Firefox
Convert Fx and TB extensions to SeaMonkey

Return to SeaMonkey Support


Who is online

Users browsing this forum: No registered users and 1 guest