Closed Bug 1145026 Opened 9 years ago Closed 8 years ago

AMO Add-On-Descriptions: Add link function leading to SeaMonkey add-on-converter and filling URL input pane

Categories

(SeaMonkey :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: RainerBielefeldNG, Assigned: michal-ok)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

User Story

Latest Converter-add-on version for testing can be found here:
<https://github.com/lemon-juice/AMO-Browsing-for-SeaMonkey/releases/>

Current Status of add-on-testing is:
Trunk (0.9.8 since 2015-10-03): no issues so far (:tonymec)

Current status of bundling the add-on with SeaMonkey is: ?

AMO upload status for "AMO Browsing for SeaMonkey": see Bug 1224520

Attachments

(2 files, 2 obsolete files)

Currently the great addon-converter <http://forums.mozillazine.org/viewtopic.php?f=40&t=2834855> is more or less an insider's tip, "hidden gem for budget travellers".

To change this unsatisfying situation one approach is mentioned in "Bug 1143276 -  Repository with Add-Ons converted for SeaMonkey might be required"

Much more promising would be links in the add-on descriptions (for add-ons what can be converted) what leads to converter and automatically adds the download link URL of the add-on to the URL input line at <http://addonconverter.fotokraina.com/>. That should be possible with some small javascript mabic or similar.

As a first step I could ask add-on-developers to add such a link to their add-on descriptions.

Preconditions for a final solution:

a) We find someone with editing permissions for AMO who can add such 
   links to add-on-descriptions. I think to all addons listed as
   "works fine" on
  <http://forums.mozillazine.org/viewtopic.php?f=40&t=2834855> should
  get such a link.
b) We get Add-on Compatibility Reporter 2.0.5 working with SeaMonkey, so 
   that we immediately get knowledge if an add-on will no longer work
   with SM
c) We find some volunteers supporting these efforts
d) We find a way to add that magic conversion link automatically
  to new versions of add-ons. As long as that will not work
  (may be forever) we need volunteers who watch those add-ons
  and trigger action if magic link needs to be added to new
  add-on version.
Blocks: 1138883
See Also: → 1143276
In the SeaMonkey about:addons we could overlay the Discovery Pane and add a banner pointing to the SM addon converter site.
(In reply to Philip Chee from comment #1)
> In the SeaMonkey about:addons we could overlay the Discovery Pane 

Yes, that's a good first step.

But If FF, TB and SM add-ons stay together on AMO (I haven't a clue how far the "signed addons only" activity is and what consequences that might have), the final goal should remain to have a one click solution:

If 
   Browser Sniffer recognizes SM 
AND 
   add-on is not compatible 
(AND may be
   if there is a flag that converter has been tested for that add-on successfully)

1 Click should lead to converter and fill URL input pane with add-on-download URL
I think Philip' suggestion should be handled with a separate Bug report (can be fixed faster than this one): "Bug 1151227 - Add-on Manager discovery pane: add Banner with link to Add-on-converter"
See Also: → 1151227
Summary: Add link to SeaMonkey add-on-converter to add-on descriptions → Add-On-Descriptions:Add link leading to SeaMonkey add-on-converter and filling URL input pane
The converter already accepts a URL as a parameter, which results in the URL field being pre-filled and the user is offered a button for direct installation. Example:

http://addonconverter.fotokraina.com/?url=https://addons.mozilla.org/en-US/firefox/addon/undo-closed-tabs-button/

This should be good for publishing links for extensions which are known to work.
(In reply to lemon_juice from comment #4)
Your Example exactly shows what I would like to see in add-onn dexcription in AMO.
For a test I added some html
--- code ---
For a test I add this link to <a
href="http://addonconverter.fotokraina.com/?url=https://addons.mozilla.org/de/seamonkey/addon/remote-xul-manager-sm/">converter</a>, please do not use!
--- code ---

to an add-on description <https://addons.mozilla.org/de/seamonkey/addon/remote-xul-manager-sm/>, and as expected it works. So as a first step we might ask add-on developers to add such links to the descriptions. But that causes much work, an the limited number of characters in the add-on-descriptions dos not allow buttons or explications concerning the converter. 

Do we know people with permissions to add such a link to the AMO functions?
Flags: needinfo?(michal-ok)
(In reply to Rainer Bielefeld from comment #6)
> <https://addons.mozilla.org/de/seamonkey/addon/remote-xul-manager-sm/>, and
> as expected it works. So as a first step we might ask add-on developers to
> add such links to the descriptions. 

I missed the link the first time but now the page is gone. But anyway, a link is just cosmetics...
 
> Do we know people with permissions to add such a link to the AMO functions?

I have no idea, maybe some of the SM developers know anything more? If not then I think asking on the official Mozilla forum would be a good step: https://forums.mozilla.org/ - the only thing I know is that AMO is coded in python so we would need to have someone knowledgeable in that language.

I don't know how difficult it would be to make any changes on AMO but I think we would need a plan so at least we know what we want. Simply adding a link leading to the converter on all Firefox add-on pages is not a good idea because many extensions simply don't work and offering broken extensions to users is not a good thing so we need to have a mechanism of marking extensions as SeaMonkey-convertible.

Let me share my proposal of how the system could work and I'll leave it open to discussion:

1. It would be a good idea to make a single listing of working extensions. Currently, these is my forum post at http://forums.mozillazine.org/viewtopic.php?f=40&t=2834855 but if we manage to get the system to AMO then we would end up with two separate databases of working extensions to maintain. Therefore, I would suggest two things:

  1A. Create a semi-official page of working extensions that will substitute the current forums listing, for example on Mozilla wiki or on SeaMonkey web site, if not possible I could even create such a page on the converter's site. I imagine it would be a simple table listing working extensions and a few people would have access to it in order to keep it updated (so I am not the only one doing this).

  1B. The system on AMO could make use of this page and could simply read the listing periodically (once a day or so) and according to this would mark appropriate extensions as convertible. Such a scraper would be quite easy to do since it would be enough to load the listing page's HTML code and find all occurrences of links beginning with http://addonconverter.fotokraina.com/?url=https://addons.mozilla.org/ - then getting the add-on ID based on such a link would be trivial and then the database should be updated accordingly. So in effect every day the AMO database would be updated with information about working extensions and the links would appear on appropriate extension pages. And we would have only one single place to update - our listing page.

2. We need to decide whom the links to the converter should be shown on AMO. There are a few combinations possible:
 - a user viewing add-on page in the SeaMonkey section - it's obvious the link should be shown in such cases
 - a user viewing add-on page in the Firefox section - if viewing in SM then the link should be shown, but what if he views it in Firefox or with another browser? Maybe show the link but in a more discreet or greyed-out fashion?

3. Physical location of the link or button on the page. I think this is cosmetics - not that it is not important but I'm sure we'll be able to deal with it when we get to that stage.

The most important thing is to know if we can push any changes to AMO, whether the people in charge of the code would accept any proposals from us or at least pull requests of patches. And we also need someone who codes in python who would be willing to write the patches (I don't have any experience in python).
Flags: needinfo?(michal-ok)
(In reply to lemon_juice from comment #7)
Great clarification of my own thoughts. Indeed we still need some thoughts concerning our needs and wishes before we can start to think about ways how to do that in AMO.
@lemon_juice 
I transferred all Lists to Wiki 
<https://wiki.mozilla.org/SeaMonkey/AddonCompat>
with Revision as of 21:58, 12 April 2015. Was easy work with an OOo HTML -> Mediawiki Macro. I recommend to add all new information there in the wiki because common editing is much more easy there.
But we should not invest too much work before we know how a "data base" for AMO use should look. I think I will find some time for necessary clarifications in 2 weeks or so.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Add-On-Descriptions:Add link leading to SeaMonkey add-on-converter and filling URL input pane → AMO Add-On-Descriptions: Add link function leading to SeaMonkey add-on-converter and filling URL input pane
Great, It's good that the page is coming alive. Two suggestions:

1. Could you update the "Recent Changes to This Page" section? It shows there were no updates since 2 years ago, which can discourage people from reading it altogether.

2. Maybe it would be good to change the "►" character to something more descriptive? I know you have explained its meaning but hardly anyone reads all the texts and by quickly scrolling down and glancing at the list it may be unclear what this means. Maybe links like "Convert ►"?
I am not very optimistic concerning AMO modifications for SeaMonkey.
but may be the same technique add-ons like Youtube MP3 Podcaster and similar ones use to add a button into the YouTube page view would also be possible here?
If nobody has a better idea I will ask some Add-On developers whether they are willing to do the job.
Add-on "YouTube mp3" <https://sourceforge.net/projects/seamonkeyaddons/files/YouTube-mp3-Converter/> more or less exactly does what we need: Transfers current page URL to a different web page URL input line.
(In reply to Rainer Bielefeld from comment #12)
> Add-on "YouTube mp3"
> <https://sourceforge.net/projects/seamonkeyaddons/files/YouTube-mp3-
> Converter/> more or less exactly does what we need: Transfers current page
> URL to a different web page URL input line.

Actually, I was thinking about the idea of creating an extension for browsing AMO with SM which would add such buttons and fix other problems, etc. That could work very well but I'm not sure if this would have enough of an impact - a user would first have to know such an extension exists and be willing to install it. I think most non-tech savvy users depend on AMO and on the browser's add-ons manager to discover extensions.
(In reply to lemon_juice from comment #13)
> a user would first have to know such an extension exists and be
> willing to install it. 

Such an "AMO browsing with SM" extension would not be for individual download. It would be shipped and installed by default with the Seamonkey package - after a transitional period of testing.

It would be really really great if you could contribute such an extension.
(In reply to Rainer Bielefeld from comment #14)

> Such an "AMO browsing with SM" extension would not be for individual
> download. It would be shipped and installed by default with the Seamonkey
> package - after a transitional period of testing.

That's clever, I haven't thought of that. That would work well, indeed. I could start working on such an extension, maybe not very quickly but I could be making some progress from time to time. But then I have a few questions mainly to SeaMonkey developers:

1. Is this idea of bundling an AMO browsing extension acceptable? This is the most important question so that I know that this work makes sense and that the developers will accept and integrate the extension with SeaMonkey releases.

2. Where do I store the repository of this extension? Is there some Mozilla account suitable for this? If not, I can create a github repo at my account and then give the SeaMonkey developers collaborator access to it. I would prefer some other people to also have full access to the repository in case I have less time to work on this or maintain.

3. What extension type would be best for this - based on traditional XUL overlays or restartless? I would think an overlay extension might be slightly better performance-wise if it is going to be bundled and enabled by the majority of users - however, I'm not really certain.

This is for a start, once we get the green light from the developers I will lay out more specific ideas of how this extension would work so we can discuss it and have a clear plan.
(In reply to lemon_juice from comment #15)
> 1. Is this idea of bundling an AMO browsing extension acceptable? 

AFAIK ChatZilla is a bundled add-on, so there should not be general concerns ;-)
But of course, there should be a "GO", may be after a a more general discussion whether that might be a way how to handle also some Enhancement Requests. I recommend to discuss that on the next SeaMonkey Status Meeting - Tuesday, 12 May 2015. What do you think?
Yes, we can wait with this for the status meeting. For now I'll describe a general idea of how this extension could work without going into details:

1. There would be a central page that would serve as a database of working extensions. I think the current wiki page is fine, the important thing is that its location is unlikely to change.

2. The extension would periodically contact this page and pull the list of working extensions into its local database (once a day, once a week?).

3. When browsing AMO the extension would activate itself and use the info from its database to make changes to AMO:
  a) add buttons to the converter to extension pages.
  b) add buttons to the converter to extension list pages.
  c) add proper info that an extension is compatible with SM after conversion.
  d) un-grey-out SeaMonkey-convertible Firefox extensions that normally appear as hardly visible in SeaMonkey due to incompatibility.
  e) and possibly some other enhancements in the future.

I think we could even allow the buttons on AMO created by this extension to lead to conversion and install directly without the current step of only filling out the URL. Since these buttons will not be live on AMO there should be no danger of any bots triggering unwanted conversions.

Potential risks:

 - AMO redesigns its pages and the extension will stop working and in a worst case scenario even make things worse. However, this seems very unlikely.

Of course, the proper way would be to simply change AMO itself to accommodate these features. But I suspect its very unlikely to find anyone to co-operate and implement it there on our behalf.
Flags: needinfo?(rsx11m.pub)
Flags: needinfo?(philip.chee)
I created a descriptions page for this idea in the wiki at <https://wiki.mozilla.org/SeaMonkey:Tasks_%26_Projects/Add-On_Converter_Button>, because in Bugzilla discussion often becomes complex, it' more or less impossible to keep overview what already has been decided. 

That wiki page should represent latest state of considerations and decisions, possible problems and so on. Please feel free to add your thoughts.
Not directly related, but showing how AMO problems also might cause problems for download add-ons for SeaMonkey: "Bug 1162374 - Impossible to download particular add-on versions from AMO"
See Also: → 1162374
Do we have any decision from the devs whether the AMO browsing extension will be accepted into SM releases once it's ready and tested? I've read in the notes from the status meeting that Ratty and rsx11m like this idea but I'm not sure if we can treat it as an official enough statement.
(In reply to lemon_juice from comment #20)
> Do we have any decision from the devs whether the AMO browsing extension
> will be accepted into SM releases once it's ready and tested? I've read in
> the notes from the status meeting that Ratty and rsx11m like this idea but
> I'm not sure if we can treat it as an official enough statement.
IanN liked it too. Nobody objected. Let's call it a go.
Flags: needinfo?(philip.chee)
(In reply to Philip Chee from comment #21)
> (In reply to lemon_juice from comment #20)
> > Do we have any decision from the devs whether the AMO browsing extension
> > will be accepted into SM releases once it's ready and tested? I've read in
> > the notes from the status meeting that Ratty and rsx11m like this idea but
> > I'm not sure if we can treat it as an official enough statement.
> IanN liked it too. Nobody objected. Let's call it a go.

Great! I think we can begin taking small steps in that direction, then.

Rainer, I would like to change the format of the list of extensions compatible with the converter at https://wiki.mozilla.org/SeaMonkey/AddonCompat. Since you have done all the work there I want to first discuss it with you so let me know if this is okay or you have some other suggestions. Basically, I'd like to do the following:


1. Convert the list of extensions to tables. At the moment we would have the same information as we are presenting now but in a tabular form. I see two reasons for doing that:
   a) A table would be easier to read for users
   b) For the AMO browsing extension in the future it will be much easier to extract data from a table than from a list with non structured text.

We could have the following columns now:
   a) Extension name - linked to the extension's original URL
   b) Link to the converter ("Convert ►")
   c) Extension versions that were found to work (tested). There could be multiple versions, comma-delimited.
   d) Compatibility comments (e.g. extension working partially, which features may not work in SM, etc.)
   e) (new) Short description - 1 or 2 sentences describing what the extension does.

All these columns except a) would be optional so there would be no pressure to complete them all. In the future all these columns would be read by the AMO browsing extension (probably except e) ) and presented to the user when browsing AMO so that apart from the converter button they would also see any relevant compatibility information.


2. Get rid of the list "Converted Versions still need review" and simply combine it with the main list of working extensions. Reason: we probably don't have enough man power to be able to test all those extensions thoroughly. Actually, all those extensions have been tested to a certain extent either by me or by other users and while these tests were not always complete I think they should be good enough and we can rely on user reports if something is not correct. I'm afraid that the section "Converted Versions still need review" might remain there forever, discouraging users from actually using the converter.

So we would end up with 4 tables:
  a) Fx extensions working
  b) Fx extensions not working
  c) TB extensions working
  d) TB extensions not working


It would also be great to have these tables localized but I'm afraid it's too complicated at the moment and would require too much work to maintain the extensions lists in multiple languages in the wiki. We would need a specially made database driven page so that it is easy to maintain it in multiple languages - something we don't have. So my suggestion is to keep it in English for now.

Let me know what you think about these points. I might use some semi-automated way to convert the lists to tables so I could take care of that - hopefully not in some distant future.
(In reply to lemon_juice from comment #22)
> Rainer, I would like to change the format of the list of extensions

Yes, of course. the current page is not suitable for automated processing
(In reply to lemon_juice from comment #22)
> So we would end up with 4 tables:


May be we will need additionally:
e) FF Extensions working without conversion, although SM (or current SM
   version) not approved in AMO
   (Currently conversion might cause a warning "Already approved for SM" in
   converter)
f) FF Extensions what will need conversion although SM approved in AMO?
   I think normally no converter link button should appear for
   Extensions what already work with SM
g-h) Same for TB extensions

@lemon_juice: What do you think?
Can you create a short table due to your needs for some first experiments? I think I can do a mass change if we have some first results, but this Wiki editing is really really time consuming, and I would like to avoid unnecessary work what would be necessary if your tests show that table structure would need some amendments.
(In reply to Rainer Bielefeld from comment #24)
> May be we will need additionally:
> e) FF Extensions working without conversion, although SM (or current SM
>    version) not approved in AMO
>    (Currently conversion might cause a warning "Already approved for SM" in
>    converter)

We might have such a table but how many cases like that do we have? I can only think of Firebug at the moment. I would suggest using one table for both TB and Fx extensions because the number will be very small and we don't need the distinction for any technical reason - I split the tables to TB and Fx only for readability.

> f) FF Extensions what will need conversion although SM approved in AMO?
>    I think normally no converter link button should appear for
>    Extensions what already work with SM
> g-h) Same for TB extensions

I thought we could put those extensions in the main table of extensions working after conversion. There will not be many of them and I can't think of any problems with such a solution. In the comment column we might write that conversion is recommended and this info would appear in AMO. If we include a SM extension in the table then the converter button will appear - just like for Fx extesions. If the button is not meant to appear then we don't need to include that extension in any table.

> @lemon_juice: What do you think?

I'm trying to think of a solution that is the most simple that's why I suggested fewer tables. If you can see any problems with that let me know in case I overlooked something.

> Can you create a short table due to your needs for some first experiments? I
> think I can do a mass change if we have some first results, but this Wiki
> editing is really really time consuming, and I would like to avoid
> unnecessary work what would be necessary if your tests show that table
> structure would need some amendments.

Sure, but I'll need a couple of days for it since I'm very busy at the moment.
(In reply to lemon_juice from comment #25)

> We might have such a table but how many cases like that do we have?
Very few. I mainly want to collect possible problems with the hope that that will help you to design the concept flexible enough and with some reserves so that unexpected special cases can be integrated without bigger problems and "fractures".


> I thought we could put those extensions in the main table of extensions
> working after conversion.
Yes, if the add-on will be able to recognize and handle these cases we will not need extra tables.

> I'm trying to think of a solution that is the most simple that's why I
> suggested fewer tables.
Yes, I hope we will be able to keep the wiki part simpe - manual maintenance will be difficult enough.

It would be great if you could leave some notes concerning the concept, so that it will stay understandable what ideas finally made it into the add-on.
(In reply to Rainer Bielefeld from comment #26)
> (In reply to lemon_juice from comment #25)
> 
> > We might have such a table but how many cases like that do we have?
> Very few. I mainly want to collect possible problems with the hope that that
> will help you to design the concept flexible enough and with some reserves
> so that unexpected special cases can be integrated without bigger problems
> and "fractures".
I know what you mean. But in this case it will be more like extending the structure with new features as opposed to rewriting the structure so I don't expect any problems :). I can see there is a *lot* to be done to improve AMO for SM but I don't want to do it all now because I think it's better to start with the most important stuff and build on it later if we have resources.

> > I thought we could put those extensions in the main table of extensions
> > working after conversion.
> Yes, if the add-on will be able to recognize and handle these cases we will
> not need extra tables.
My idea is that the add-on will not have to recognize any cases like that because it will treat all of them the same - whether it's a Fx, TB or SM add-on, or any combination of those, it will work the same - it will put the converter button on AMO if it is listed in our table.
 
> > I'm trying to think of a solution that is the most simple that's why I
> > suggested fewer tables.
> Yes, I hope we will be able to keep the wiki part simpe - manual maintenance
> will be difficult enough.
It shouldn't be more difficult than it is now - however, I think table editing must be done in html in the wiki. Hopefully, we may get some volunteers to help.

> It would be great if you could leave some notes concerning the concept, so
> that it will stay understandable what ideas finally made it into the add-on.
Yes, I will keep the add-on documented.
I have one concern about the extension tables being in the Mozilla wiki: the editing of the tables is pretty laborious and uncomfortable because there is no visual editor and we have to edit the html code or the weird wiki code by hand. When the tables get large then it's tedious to hunt in the code for the right spot to edit/add stuff and then switching between the preview and the code back and forth to verify the changes.

I would be great to have a page editable with a visual editor like TinyMCE (http://www.tinymce.com/tryit/basic.php) where editing tables is much easier. As a bonus it would be possible to add custom buttons to such an editor that would ease adding extensions to the tables (for example, having a form with fields like extension name, url, version, comment, etc. and then auto-creating new table row with the data). This would need to be a simple CMS with the ability to create access accounts for potential volunteer editors.

Do we have any chance of getting access to an ftp account, preferably with PHP support, somewhere within the Mozilla or SeaMonkey infrastructure for this purpose? The added benefit would be much less strain on the server - the AMO browsing add-on used by many users will periodically contact the listing page. If we have our custom mini-CMS for that then we could avoid running the Mozilla wiki engine with every request - we could serve the content from a generated static html file instead.

If not, is there a free service where we could host such a utility? Some fairly stable place that we won't get kicked out of in a reasonably foreseeable future?

Do you think this is a good idea? I'm trying to come up with a system that would be easiest to maintain in the long run so that adding or editing extensions in the list can be done with least effort.
(In reply to lemon_juice from comment #28)
That's my concern, too!  My Ideas:
The "database" should be editable as easy and effective as possible for few experts, because I doubt that users will help by deiting the Wiki tables in foreseeable future.
Idea for user feedback in the Wiki <https://wiki.mozilla.org/SeaMonkey:Tasks_%26_Projects/Add-On_Converter_Button#Ideas> (Standard User Fededback email)
(In reply to Rainer Bielefeld from comment #29)
> The "database" should be editable as easy and effective as possible for few
> experts, because I doubt that users will help by deiting the Wiki tables in
> foreseeable future.
Yes, by "users" I actually meant "experts" who will be able to handle this task. It looks like the wiki cannot offer us a convenient way to edit the compatibility tables.

I have added our search for an official place to host the Add-on Converter compatibility tables to the agenda of the next status meeting: https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2015-05-26#Extensions_and_Plugins_Compatibility_Tracking. Hopefully, the developers may be more in a position to investigate if we can host it somewhere in the SM/Mozilla infrastructure. Otherwise, we'll have to find some 3rd party host but it would be better to have this on the official SM server if this extension is going to be bundled by default.
In today's Status Meeting, it was pointed out that "the reason we have a blank space in the [Add-ons Manager's] discovery pane is that our carousel is empty." Thus, it should be possible to prominently display a link to the converter and related resources in that carousel:

> http://logs.glob.uno/?c=mozilla%23seamonkey&s=23+Jun+2015&e=23+Jun+2015#c644752

With regard to the add-on proposed here, that would imply some consideration which functions and features can be satisfied by the carousel mechanism (depending on how smart its API is) and which additional functionality needs to be provided by a distributed extension overlaying the Toolkit Add-ons Manager implementation. It seems that the less we mess with the actual manager code and the more can be done using already available Toolkit/AMO mechanisms the better.
Flags: needinfo?(rsx11m.pub)
Blocks: 1178164
See Also: → 1178164
*Project* *Status*

Hi lemon_juice,

did you already find the time to do some work here? A demo button in the AMO add-on description as a first module would be great.

Concerning the compatibility ratings database I still see many problems. Email feedback implementation would be easy, but manual analysis is not acceptable. A Crazy idea was to create a newsgroup and the Converter (only subscriber with write permissions would send postings with Summaries like

Show Address Only [converted] 0.1.9 /+/
for positive compatibility rating or
Show Address Only [converted] 0.1.9 /-/
for negative compatibility rating for this add-on. Users could count or estimate relation +/-

But that would be a rather exotic solution.

I still think that the best solution would be to get Add-on Compatibility Reporter <https://addons.mozilla.org/de/firefox/addon/add-on-compatibility-reporter/> working for us - or may be an alternative user satisfaction rating too,. but I do not know any.
Sorry, I was quite busy during the holiday time. I haven't started with the add-on yet but I've almost finished creating the new compatibility tables page with an admin panel to easily edit extensions. Now adding a new extension from AMO will be as easy as pasting its URL into the tool and all information will be fetched automatically. I will still need a few days to fix a few glitches and put it online. My intention is for this new page to replace the current compatible extensions listing at mozillazine and in the Mozilla wiki and potentially in the future to serve as the database source for the AMO browsing extension.

Rainer, will you be able to help me out in completing the extension list in the beginning? I think I'll manage to move the extensions from the mozillazine thread but I know you had some new additions in the wiki as well. There will be a possibility to add accounts for other people who would be willing to help with maintaining the list. I know all this needs time and resources but there is no pressure - the list will be as good as we will be able to make it and that's fine.

As the next step I was thinking of adding to the tables a possibility to leave feedback about the extensions and to submit new extensions - that feedback would be both visible on the page and be automatically sent to all database maintainers. But we can discuss this after I put up the page. I think this would work better than a separate newsgroup since I think newgroups are pretty exotic nowadays, anyway.
(In reply to lemon_juice from comment #33)
> Rainer, will you be able to help me out in completing the extension list in
> the beginning? 

Hi, I'll try.

> There will be a possibility to add accounts for other people who would
> be willing to help with maintaining the list.

My experience is that that will not work. With 3 ... 5 people (I doubt that so many can be found) such a list can be kept up to date, but without feedback of much more users the "data base" will be too small. 

> As the next step I was thinking of adding to the tables a possibility to ...

We can try that. But I am pretty sure that nearby nobody will leave some feedback without a reminder. Do you see a possibility to ask for e-mail-address on converter page so that the downloader will get a reminder e-mail after 3 days, what will lead him to a page where he will generate an e-mail with a single click what contains some questions, and then user has to send the completed e-mail to the list maintainers:

---   Mail body   ---   

Please 1 X per line:        true    1   2   3   4   5   false 
Installation worked fine           [ ] [ ] [ ] [ ] [ ]  
add-on function works perfectly    [ ] [ ] [ ] [ ] [ ]  

[ ] I agree with contact by add-on-compatibility-list-maintainers
My comment concerning observed problems: ....................

---   End Mail body   ---   

Or similar

OS and SM-Version will be visible from e-mail-header
(In reply to Rainer Bielefeld from comment #34)
> > There will be a possibility to add accounts for other people who would
> > be willing to help with maintaining the list.
> 
> My experience is that that will not work. With 3 ... 5 people (I doubt that
> so many can be found) such a list can be kept up to date, but without
> feedback of much more users the "data base" will be too small.

Yes, I have the same doubts and I am aware we might have difficulties in getting enough people to maintain the list. But we don't need to test all available extensions and put them on the list - if the list is as small as the current one and evolving slowly, it's still better than nothing.

I also thought maybe about opening the registration to the editing area for everyone so the list gets maintained in a wiki-style. This way we may have more people contributing to the list if they don't need to have our permission to get an admin account. Sure, this may result in some extensions not being tested well enough but maybe at this stage we shouldn't worry about this and engaging people might be more important than being strict about who can manage the list. What do you think?

> > As the next step I was thinking of adding to the tables a possibility to ...
> 
> We can try that. But I am pretty sure that nearby nobody will leave some
> feedback without a reminder. Do you see a possibility to ask for
> e-mail-address on converter page so that the downloader will get a reminder
> e-mail after 3 days

That would be a good idea, I think. But I would need some more time to implement this so this is possible at a later stage. Meanwhile, let's see if anyone has other ideas as well.
I have made the first experimental version of the AMO browsing extension. Currently, it add/modifies some information on AMO add-on pages:

1. If an extension has outdated maxVersion it informs about it:

http://addonconverter.fotokraina.com/amo-browsing/page-max-version.png

2. If an extension has outdated maxVersion and requires strict version check then it provides a link to the converter:

http://addonconverter.fotokraina.com/amo-browsing/page-strict-comp.png

3. If we are browsing a Firefox add-on page, the big ugly button "Only with Firefox — Get Firefox Now!" is replaced with an option to check for SeaMonkey version and offers a link to the converter:

http://addonconverter.fotokraina.com/amo-browsing/page-firefox.png

Here is the installer:
http://addonconverter.fotokraina.com/amo-browsing/amo-browsing-0.9.0.xpi

Source code on github:
https://github.com/lemon-juice/AMO-Browsing-for-SeaMonkey

Please check it out, test it and leave feedback!
I tested <https://addons.mozilla.org/en-US/firefox/addon/default-fullzoom-level/?src=search>, looks promising.
Assignee: nobody → michal-ok
Version 0.9.1:
 - changes in add-on listings: no more greyed-out add-ons, no more information about "not available for SeaMonkey" - instead a welcoming text "See add-on page for SeaMonkey compatibility information.". Example: https://addons.mozilla.org/en-US/seamonkey/extensions/?sort=users

 - improvements and fixes on various types of add-on pages

Installer: http://addonconverter.fotokraina.com/amo-browsing/amo-browsing-0.9.1.xpi
(In reply to lemon_juice from comment #38)
> Version 0.9.1:
>  - changes in add-on listings: no more greyed-out add-ons, no more
> information about "not available for SeaMonkey" - instead a welcoming text
> "See add-on page for SeaMonkey compatibility information.". Example:
> https://addons.mozilla.org/en-US/seamonkey/extensions/?sort=users
> 
>  - improvements and fixes on various types of add-on pages
> 
> Installer:
> http://addonconverter.fotokraina.com/amo-browsing/amo-browsing-0.9.1.xpi

• Ah, nice: it is restartless. I agree with Rainer: it looks promising. Hopefully no more of these annoying "You need Firefox 10.0 or later" popups in current SeaMonkey 2.?? builds.
• I just opened a github issue for the broken link on its Details pane (which I noticed in 0.9.0 but it persists in 0.9.1).
• A "Release Notes" item (like what many addons have, tersely listing enhancements and bugfixes compared with previous release, and accessible via the List pane of about:addons) would be welcome.
P.S. On the AMO page mentioned in comment #38, after upgrading to 0.9.1 I still have a lot of greyed-out items: Adblock Plus (at the top) is accessible, the rest are "Not available for SeaMonkey 2.41a1" and greyed-out but clickable.

Clicking the first one after Adblock Plus (Lightning 4.0.2.1) I get an amber "Add to SeaMonkey" button with under it the following red text:

Maximum officially supported SeaMonkey version for this add-on is 2.35.*. It will probably not install because the author opted for strict version compatibility check. You can try using the Add-on Converter to bump the maxVersion and see if the add-on will work. Click here to convert this add-on.

which is much better than what I used to see without your addon. However, Lightning will indeed not work with the "wrong" version of the mailer because it is a binary extension which depends on the exact corresponding XPCOM version.
See Also: → 1208942
> I still have a lot of greyed-out items: Adblock Plus (at the top) is accessible,
> the rest are "Not available for SeaMonkey 2.41a1" and greyed-out but clickable.

I think you are talking about the AMO home page? This is yet to be done!

(In reply to Tony Mechelynck [:tonymec] from comment #39)
> • A "Release Notes" item (like what many addons have, tersely listing
> enhancements and bugfixes compared with previous release, and accessible via
> the List pane of about:addons) would be welcome.

I've never seen a "Release Notes" pane list in about:addons - where can I find this? You can see what has changed at https://github.com/lemon-juice/AMO-Browsing-for-SeaMonkey/commits/master

(In reply to Tony Mechelynck [:tonymec] from comment #40)
> However,
> Lightning will indeed not work with the "wrong" version of the mailer
> because it is a binary extension which depends on the exact corresponding
> XPCOM version.

Yes, I am aware of that. Actually, I don't know what to do about it now because there are also extensions with strict compatibility checking that will work fine in newer SM versions, for example https://addons.mozilla.org/en-US/seamonkey/addon/fireshot/. The add-on would need to have a way to recognize add-ons which are not safe for version bumping like Lightning. The only solution I can think of is hard-code Lightning to be recognized and display a different warning there without the link to the converter. What do you think?
(In reply to lemon_juice from comment #41)
> (In reply to Tony Mechelynck [:tonymec] from comment #39)
> > • A "Release Notes" item (like what many addons have, tersely listing
> > enhancements and bugfixes compared with previous release, and accessible via
> > the List pane of about:addons) would be welcome.
> 
> I've never seen a "Release Notes" pane list in about:addons - where can I
> find this? You can see what has changed at
> https://github.com/lemon-juice/AMO-Browsing-for-SeaMonkey/commits/master

It comes from something set in the extension, which makes a line "Show Release Notes" appear at the bottom of the list-pane entry for that extension on the "Recent Updates" pane of about:addons. Click that line, and after a few seconds the release notes fold out, with a heading "Release Notes" above them and a line "Hide Release Notes" at bottom.

I don't know how it is done but I know that it can be done; I imagine that it comes from some optional entry in install.rdf. Of the extensions installed in my SeaMonkey profile, the following ones have it:

Remote XUL Manager 1.3
Open With 6.1.2
Adlock Plus 2.6.11
It's All Text! 1.9.2
Add-ons Manager - Version Number 1.0.4
Facebook Share Button 40.0
Flagfox 5.1.3
Saved Password Editor 2.9.2
Forecastfox (fix version) 2.3.2
ColorZilla 2.8.2
Element Hiding Helper for Adblock Plus 1.3.4

Many others lack it. Of the add-ons listed above, you probably have one or more on your system too. As an example, the release notes for Adblock Plus 2.6.11 say the following:

* Fixed: Findbar in Filter Preferences was slightly broken when using Firefox 42 and above.
* Fixed: Notification popup shouldn't disappear if somebody clicks outside it.
* Fixed: Toolbar icon broken in SeaMonkey 2.40 and above.
* Added promotional message for Adblock Browser to the first-run page.

Hm... Adblock Plus is a big extension, and somehow I cannot find that text in extensions/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi in my profile. I wonder where it comes from.
(In reply to Tony Mechelynck [:tonymec] from comment #42)
> It comes from something set in the extension, which makes a line "Show
> Release Notes" appear at the bottom of the list-pane entry for that
> extension on the "Recent Updates" pane of about:addons.

I remember now I've seen this pane a few times but it doesn't show up very often for me. Anyway, this list comes from AMO, not from the add-on so we don't have that because this add-on is not hosted on AMO.

A new version 0.9.3 http://addonconverter.fotokraina.com/amo-browsing/amo-browsing-0.9.3.xpi:

 - apply compatibility info changes on AMO home page and on add-on pages in mouseover popups
 - apply compatibility info changes on collection listings
 - Ability to hard-code add-ons that should not be given converter links because they require specific SM versions. Added Lightning to the list.
 - fixes and improvements in add-on detection

This version should be almost feature complete, the only place still lacking any added improvements are add-on version details - but I think those areas are not visited often so this should not be a priority. Please test it and let me know it it works well.

P.S. After looking clearly at the details of how the compatibility information is handled and presented for SeaMonkey add-ons at AMO all I can say is that it is a big mess and it's not such a simple thing to correct it all. Therefore, my prediction is that this will never be fixed on Mozilla's end since it's not a question of a quick fix - there would need to be a coder at AMO who is dedicated to SM and decides to fix these things - quite unlikely, I would say!
Version 0.9.4 released which applies changes to search result pages.

Also, there is another unusual extension - Firebug - which is not offered for SM at AMO, although it works without conversion. Therefore, I hard coded its ID and now page https://addons.mozilla.org/en-US/firefox/addon/firebug/ offers normal install button with info "Official SeaMonkey support is not offered by this add-on, however it should work fine. Feel free to install it!".

As far as I know Lightning and Firebug are the only extensions that need special treatment, let me know if you know of others.
(In reply to lemon_juice from comment #45)
> Version 0.9.4 released which applies changes to search result pages.

This works: now nothing is greyed-out, and the red "Incompatible with SeaMonkey 2.41a1" has been replaced by a grey "See add-on page for SeaMonkey compatibility information". :-)

Lurkers: Version 0.9.4 is of course found at http://addonconverter.fotokraina.com/amo-browsing/amo-browsing-0.9.4.xpi — or _all_ versions of this awesome addon can be found at http://addonconverter.fotokraina.com/amo-browsing/ which I'm pasting into the "URL" field near the top of this bug page.

> 
> Also, there is another unusual extension - Firebug - which is not offered
> for SM at AMO, although it works without conversion. Therefore, I hard coded
> its ID and now page https://addons.mozilla.org/en-US/firefox/addon/firebug/
> offers normal install button with info "Official SeaMonkey support is not
> offered by this add-on, however it should work fine. Feel free to install
> it!".
> 
> As far as I know Lightning and Firebug are the only extensions that need
> special treatment, let me know if you know of others.

"Incompatible with SeaMonkey 2.41a1" remains in grey in the "Version Information" foldout, just below the amber "Add to SeaMonkey" button, but I believe it can stay that way. Maybe make the button red rather than amber (both at the top of the add-on page, and at the bottom in the version foldout; and wherever else that button appears) when a "strict checking" setting makes us believe that this particular addon will probably not work with the current browser, but this is a low-priority cosmetic enhancement.

Your talking of Firebug reminds me that Venkman (which used to be distributed with SeaMonkey, at least as part of trunk builds) has been retired, and that a replacement is being searched; see bug 1133723. No compatibility problems expected, of course.
Version 0.9.5 released. I had to make a change on add-on pages as I think it's not always good to remove the official AMO's compatibility info like "Not available for SeaMonkey x.xx" (even though often inaccurate), for example https://addons.mozilla.org/en-us/seamonkey/addon/disable-ctrl-q-shortcut/ is an add-on with maxVersion 2.36 so in SM 2.38 an amber install button shows up, however this extension is only for Linux so Windows users would see the button and text saying it will work but in fact it will not. So I kept the original AMO info in pale font under "Official Status" label below so that people will know why they may have problems installing. Unfortunately, I can't see an easy way to distinguish between "Not available for your platform" and "Not available for SeaMonkey x.xx" so I think we can show it in all cases. I tried to make the fonts and colours so that it is not too obtrusive.

Other than that:
 - add-ons for SM lower than 2.1 are not compatible by default so this extension now detects them and offers running them through the converter
 - preparation for potential localizations (if anyone would volunteer)

(In reply to Tony Mechelynck [:tonymec] from comment #46)
> "Incompatible with SeaMonkey 2.41a1" remains in grey in the "Version
> Information" foldout, just below the amber "Add to SeaMonkey" button, but I
> believe it can stay that way. Maybe make the button red rather than amber
> (both at the top of the add-on page

Indeed, amber looks too encouraging. For strict compatibility cases I've now made the button grey since this appears to be the standard for incompatible add-ons.
(In reply to lemon_juice from comment #47)
> Version 0.9.5 released. I had to make a change on add-on pages as I think
> it's not always good to remove the official AMO's compatibility info like
> "Not available for SeaMonkey x.xx" (even though often inaccurate), for
> example
> https://addons.mozilla.org/en-us/seamonkey/addon/disable-ctrl-q-shortcut/ is
> an add-on with maxVersion 2.36 so in SM 2.38 an amber install button shows
> up, however this extension is only for Linux so Windows users would see the
> button and text saying it will work but in fact it will not. So I kept the
> original AMO info in pale font under "Official Status" label below so that
> people will know why they may have problems installing. Unfortunately, I
> can't see an easy way to distinguish between "Not available for your
> platform" and "Not available for SeaMonkey x.xx" so I think we can show it
> in all cases. I tried to make the fonts and colours so that it is not too
> obtrusive.
[...]
> Indeed, amber looks too encouraging. For strict compatibility cases I've now
> made the button grey since this appears to be the standard for incompatible
> add-ons.

I don't see these changes, not even after:
1. Install add-on version 0.9.5
2. Go → Recently Closed Tabs → Lightning
3. Shift+Ctrl+R

I'll attach a screenshot of about:addons taken after step 1, showing I have the correct version, and two more (top and bottom of the page) taken after step 2, showing I see neither a grey button nor an "Official Status" label. I am using the following build of SeaMonkey:

UA "Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 SeaMonkey/2.41a1" ID:20150930003001 c-c:3ddf3a3eaf07d5e6c1a98bfbe184dab32841ed03 m-c:891ee0d0ba3ec42b6484cf0205b3c95e21c58f74
My bad. They both appear after restarting SeaMonkey, which I had thought would not be needed for a restartless extension.
Comment on attachment 8668162 [details]
Bottom of Lightning page after comment #48 step 3

The bottom button also becomes grey after a restart.
Attachment #8668162 - Attachment is obsolete: true
Please consider "Bug 1210345 - SeaMonkey Add-On-Converter might cause copyright/License issues"
See Also: → 1210345
(In reply to Tony Mechelynck [:tonymec] from comment #52)
> My bad. They both appear after restarting SeaMonkey, which I had thought
> would not be needed for a restartless extension.

Yes, a restart should not be necessary, however it turns out that the upgrade mechanism for restartless extensions (inherited from Firefox) is broken out of the box and special hacks are needed to make it work properly. Should be fixed in 0.9.6.
(In reply to lemon_juice from comment #56)
> (In reply to Tony Mechelynck [:tonymec] from comment #52)
> > My bad. They both appear after restarting SeaMonkey, which I had thought
> > would not be needed for a restartless extension.
> 
> Yes, a restart should not be necessary, however it turns out that the
> upgrade mechanism for restartless extensions (inherited from Firefox) is
> broken out of the box and special hacks are needed to make it work properly.
> Should be fixed in 0.9.6.

Thanks! I'm not going to test it, because AFAIK the only obvious way to test it would be to downgrade to 0.9.4, restart, check that the page is displayed wrong, upgrade to 0.9.6, and check that the page is displayed the right way even without a restart. I guess I'm too lazy.
Version 0.9.7 with some final touches: added info on Thunderbird add-on pages:

"Check if SeaMonkey version is available. If no SeaMonkey version exists you will be redirected back to this page – in that case you may try using the Add-on Converter. Warning: not all converted add-ons will work properly in SeaMonkey!

Convert this add-on here – use only if no SeaMonkey version exists."
(In reply to lemon_juice from comment #58)
> Version 0.9.7 with some final touches: added info on Thunderbird add-on
> pages:
> 
> "Check if SeaMonkey version is available. If no SeaMonkey version exists you
> will be redirected back to this page – in that case you may try using the
> Add-on Converter. Warning: not all converted add-ons will work properly in
> SeaMonkey!
> 
> Convert this add-on here – use only if no SeaMonkey version exists."

ah, nice touch :-)
One more enhancement (please): For add-ons which have a "development" version, i.e. a "Development Channel" foldout at bottom, the "Add to SeaMonkey" button there is still greyed-out and not clickable if appVersion > maxVersion, even for non-strict-checking extensions which are in range for the Toolkit autocompatibility feature. The same applies to the versions in the "version history" pages for the extension.

Case in point: Nightly Tester Tools
- Extension page: https://addons.mozilla.org/en-US/seamonkey/addon/nightly-tester-tools/ (unfold the "Development Channel" foldout at the bottom)
- Release history: https://addons.mozilla.org/en-US/seamonkey/addon/nightly-tester-tools/versions/
- Development channel history: https://addons.mozilla.org/en-US/seamonkey/addon/nightly-tester-tools/versions/beta

I hope I'm not driving you too hard. :-)

In this case Nightly Tester Tools 3.7pre20131013 has an IMHO useful feature which the release version lacks: when used in SeaMonkey or Thunderbird, it can get not only the comm-central (or comm-<something>) changeset but also the mozilla-central (or mozilla-<something>) one and, after customization, display them both in the window title and/or in a textarea being filled (or if none, in the clipboard). The following is how I have customized the latter:

nightly.templates.buildid    user set    string    UA "${UserAgent}" ID:${AppBuildID}${Flags} c-c:${Changeset} m-c:${PlatformChangeset}

which gives (in the SeaMonkey build I'm using at the moment)

UA "Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Firefox/44.0 SeaMonkey/2.41a1" ID:20151002003002 c-c:180bafc8f18cc4bae161fa14b192d356b9284bd8 m-c:2c1fb007137dcb68b1862a79553b53f1a34c99c3
Flags: needinfo?(michal-ok)
Yes, I was aware that sometimes there were unclickable install buttons in versions. Version 0.9.8 makes them accessible again, the same in the Development Channel. However, I didn't add any descriptions or other modifications there but I think it can stay that way for now.

There are still a few areas where this extension can be improved (among them is the plan to integrate it with the database of known working extensions) but those things can be done at a later time and for now I think the most important things are covered. I think it would be good to start integrating this extension with SeaMonkey so that it is shipped and enabled out of the box.

Therefore, there are a few questions to the SM developers like
 - is this extension is its current form okay, the code is fine, anything needs to be changed, etc.?
 - where do we host the source code - leave it where it is, a new github repository for SeaMonkey, or elsewhere? A place where the devs will have full access to it.
 - do we put the extension up on AMO? Generally, we wouldn't need to, however this would make updates handled easily. 

In short - how do we proceed now?
Flags: needinfo?(michal-ok)
(In reply to lemon_juice from comment #61)
> Yes, I was aware that sometimes there were unclickable install buttons in
> versions. Version 0.9.8 makes them accessible again, the same in the
> Development Channel. However, I didn't add any descriptions or other
> modifications there but I think it can stay that way for now.

Great! Yes, I think so too.
> 
> There are still a few areas where this extension can be improved (among them
> is the plan to integrate it with the database of known working extensions)
> but those things can be done at a later time and for now I think the most
> important things are covered. I think it would be good to start integrating
> this extension with SeaMonkey so that it is shipped and enabled out of the
> box.
> 
> Therefore, there are a few questions to the SM developers like
>  - is this extension is its current form okay, the code is fine, anything
> needs to be changed, etc.?
>  - where do we host the source code - leave it where it is, a new github
> repository for SeaMonkey, or elsewhere? A place where the devs will have
> full access to it.
>  - do we put the extension up on AMO? Generally, we wouldn't need to,
> however this would make updates handled easily. 
> 
> In short - how do we proceed now?

Can you attend the next SeaMonkey Status Meeting, on October 13, starting at 14:00 continental Europe time on IRC channel #seamonkey on moznet? It will be announced on newsgroup mozilla.dev.apps.seamonkey a few days before, and about at the same time the meeting page will be put up at https://wiki.mozilla.org/wiki/SeaMonkey/StatusMeetings/2015-10-13 — you can then add at the appropriate place on that page that you have developed this extension, that I have been testing successive versions of it, that we propose it for inclusion into SeaMonkey, and that you're asking for recommendations about how to proceed from now on. See the minutes of the latest meeting at https://wiki.mozilla.org/SeaMonkey/StatusMeetings/2015-09-29 to see how this page is written. Anyone with an interest in developing SeaMonkey and a Mozwiki account can edit this page. I trust you not to vandalize it. :-)

Yes, for a built-in extension it's better if it's available at AMO, though for a SeaMonkey-only extension it is less necessary than for an all-toolkit extension like ChatZilla. Try to find out what Philip Chee thinks about this extension, I think he would be interested: extension porting is one of his hobbies (if I can call it that).
P.S. The code is already on github; unless Philip Chee has a better idea I think you can leave it there and just extend the necessary privileges to whoever will help you develop it further. If the code is ever included into SeaMonkey, we can request an additional Bugzilla "Component" for it under the SeaMonkey "Product", with you as module owner and Philip Chee (and/or some other(s)) as peer(s).
Comment on attachment 8668168 [details]
top of Lightning page after restarting SeaMonkey

The idea of adding this feedback request to this attachment is a little bogus, but I haven't yet understood the philosophy of attachments of type MozReview.

Philip, please read comment #61 et seq. and tell us what you think about them.
Attachment #8668168 - Flags: feedback?(philip.chee)
@lemon_juice: I mentioned your extension at the fortnightly SeaMonkey Status Meeting, which just ended at #seamonkey on moznet. There was some interest but the main question raised was: "What if AMO changes again?" You really ought to have been there to publicly commit yourself to keep the extension up-to-date (I trust you to, but apparently not everyone does). Next meeting is on November 10, 14:00 continental Europe time (13:00 UTC) and both Europe and North America will be off DST again (so it's 8am Eastern, 5am Pacific, etc.)
Hi Tony, I was at the previous status meeting and no one had any concerns about this extension and it was agreed to ship the extension with a next beta build, there were also concerns about where to host the source code but this decision doesn't belong to me. Anyway, I didn't have time for today's meeting and I thought everything was settled more or less.

There is always some risk that AMO changes and the extension will stop working properly or in extreme cases causes some harm but I think it's important to weight pros and cons - and in my opinion the likelihood of AMO changing in such a way that this extension will break things is very minimal and at worst it will stop working. From my experience watching the AMO's html code (while working with the add-on converter) in the last 2 years there have been no significant changes that would break this kind of extension and as far as I know there are no plans on Mozilla's part to redesign AMO in the near future.

Nothing is certain here and nor is my participation in the next few years in the development of the extension, although I plan to take care of it, even though I cannot predict how available I will be for any immediate fixes. That's why I'd like the source code to be accessible by other devs as well so in an emergency event they can either make necessary changes or least turn it off (if they happen to have no time for fixing). However, my plans are to at least maintain the add-on.

This is just an extension and with an update mechanism it's possible to push an update immediately that will fix or turn off potentially problematic features. And it can be withdrawn from new SM versions at any time. I don't see any real risks here, if we don't go for this we will never know how it will play out.
(In reply to lemon_juice from comment #66)
> Hi Tony, I was at the previous status meeting and no one had any concerns
> about this extension and it was agreed to ship the extension with a next
> beta build, there were also concerns about where to host the source code but
> this decision doesn't belong to me. Anyway, I didn't have time for today's
> meeting and I thought everything was settled more or less.

If ever this extension is shipped together with SeaMonkey the way ChatZilla is, I suppose the easiest would be to put the source (or a mirror to it) somewhere on hg.mozilla.org so that the client.py (or whatever is now used in its stead) could pull it the way it does ChatZilla (and LDAP and DOMi and of course mozilla-something, all of which are grafted at various points on the comm-central tree, though IIUC it is, or will be, possible to graft c-c on m-c rather that the other way round. Ah well...).
> 
> There is always some risk that AMO changes and the extension will stop
> working properly or in extreme cases causes some harm but I think it's
> important to weight pros and cons - and in my opinion the likelihood of AMO
> changing in such a way that this extension will break things is very minimal
> and at worst it will stop working. From my experience watching the AMO's
> html code (while working with the add-on converter) in the last 2 years
> there have been no significant changes that would break this kind of
> extension and as far as I know there are no plans on Mozilla's part to
> redesign AMO in the near future.
> 
> Nothing is certain here and nor is my participation in the next few years in
> the development of the extension, although I plan to take care of it, even
> though I cannot predict how available I will be for any immediate fixes.
> That's why I'd like the source code to be accessible by other devs as well
> so in an emergency event they can either make necessary changes or least
> turn it off (if they happen to have no time for fixing). However, my plans
> are to at least maintain the add-on.

This was my understanding too. "Nothing is certain" should be emphasised: more than once in the past it has happen than the Core or Toolkit developers took far-reaching decision without making sure that SeaMonkey didn't break. I suppose that from the AMO owners' point of view, an extension like yours is in the "use at your own risk" category, especially as long as it doesn't live at AMO.
> 
> This is just an extension and with an update mechanism it's possible to push
> an update immediately that will fix or turn off potentially problematic
> features. And it can be withdrawn from new SM versions at any time. I don't
> see any real risks here, if we don't go for this we will never know how it
> will play out.

When (and if) it is shipped with SeaMonkey like ChatZilla, it will be copied into the user's profile whenever a SeaMonkey version change is detected, but only if there isn't already there an extension by the same add-on ID with an equal or higher version number. So the user will be allowed to install a "development version" (if and when there is one) with a higher version than the one shipped with SeaMonkey, but he won't be stranded once the shipped one catches up. If the extension is upgraded on a trunk or aurora build, that will be detected at the latest at the next merge event (within 6 weeks) or the add-on can be manually reinstalled from <appdir>/distribution/extensions/amobrowsing@seamonkey.mozilla.org.xpi

When I told Mc (who is interested in Lightning) that this add-on has special code for Lightning, which because it is a binary add-on requires strict XPCOM versioning, he answered "nice" so you can see that at least some of the opinion is in your favour. (I'm enthusiastic.) Of course, the more testing the better, but hopefully not to the point of getting into the vicious circle of "it isn't official because it isn't tested enough" vs. "it isn't tested much because it isn't official" the way it happens with linux-x86_64 builds of SeaMonkey.

And yes, if ever the add-on starts to behave unacceptably for some user, he can always disable it from the add-ons manager and get the (IMHO SeaMonkey-unfriendly) vanilla-AMO behaviour.
Discussion has become rather long, can we get very few essentials updated in "user story"?
User Story: (updated)
User Story: (updated)
"Bug 1222327 - Add-on "AMO Browsing for SeaMonkey" needs handler for add-on-updates" is concerning function enhancement needed for future.
See Also: → 1222327
Fix for "Bug 1151227 - Add-on Manager discovery pane: add Banner with link to Add-on-converter" needs fix for "Bug 1224520 - Upload "AMO Browsing for SeaMonkey" to AMO".
User Story: (updated)
See Also: → 1224520
(In reply to Tony Mechelynck [:tonymec] from comment #67)
> If ever this extension is shipped together with SeaMonkey the way ChatZilla
> is, I suppose the easiest would be to put the source (or a mirror to it)
> somewhere on hg.mozilla.org so that the client.py (or whatever is now used
> in its stead) could pull it the way it does ChatZilla (and LDAP and DOMi and
> of course mozilla-something, all of which are grafted at various points on
> the comm-central tree, though IIUC it is, or will be, possible to graft c-c
> on m-c rather that the other way round. Ah well...).

This sounds fine. Even putting this extension on AMO would not be a bad idea - at least any updates could be handled easily and independently of SM releases. But I'm not sure if this wouldn't complicate things when building SM releases with the extension. Therefore, let the developers decide where to put it.

> This was my understanding too. "Nothing is certain" should be emphasised:
> more than once in the past it has happen than the Core or Toolkit developers
> took far-reaching decision without making sure that SeaMonkey didn't break.
> I suppose that from the AMO owners' point of view, an extension like yours
> is in the "use at your own risk" category, especially as long as it doesn't
> live at AMO.

Yes, but on the other hand I think it doesn't make sense to be too cautious about it and go with it as soon as possible because given the questionable future of Fx changes (killing XUL, etc.) we are not sure what will happen to SM and to AMO in the near future and if we hold off for too long this extension may become useless with time.

We need now some action from the devs to:

1. Decide about where to host the source code so that I can also update it when needed.
2. Test the extension, verify the code - let me know if anything needs changing.
3. Bundle it with SM.

> When I told Mc (who is interested in Lightning) that this add-on has special
> code for Lightning, which because it is a binary add-on requires strict
> XPCOM versioning, he answered "nice" so you can see that at least some of
> the opinion is in your favour. (I'm enthusiastic.) Of course, the more
> testing the better, but hopefully not to the point of getting into the
> vicious circle of "it isn't official because it isn't tested enough" vs. "it
> isn't tested much because it isn't official" the way it happens with
> linux-x86_64 builds of SeaMonkey.

As the things currently stand, since many months now all SM releases can be considered beta and unofficial versions (because of not enough devs) - bug come and go at random - so in comparison this extension poses very little risk. We should go with it now and give more priority to useful features than to perfect testing because we simply don't have enough man power to make everything perfect!
Depends on: 1230722
See Also: → 1230806
See Also: → 1249072
I think this one is fixed with "AMO Browsing for SeaMonkey"?
Yes, it looks like it's fixed.
Fixed by creation of "AMO-Browsing-for-SeaMonkey" tool.
Status: NEW → RESOLVED
Closed: 8 years ago
User Story: (updated)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.