395857 - Add support for updateInfoUrl

Status: VERIFIED FIXED

(addons.mozilla.org Graveyard :: Public Pages, defect)

Description

[Alfred Kayser]

Gecko 1.9/Firefox 3.0 now supports updateInfoURL to pass a URL to a page containing version info about Addons updates. 
For Addons hosted at AMO, it would be useful if the version info managed at AMO (by the submitter) could be used as source for this new updateInfoURL feature.

Probably several ways to implement:
* Let Gecko, like updateURL, default updateInfoURL to AMO somewhere when it is empty.
* Let Addons developers add the updateInfoURL pointing to the AMO version info.

Of course, developers could also add their own version update page on their own host, but the whole purpose of AMO is to provide Addons hosting, including the QA process (review/sandbox/etc). Also one would want to verify that the version update info is in agreement with the actual version posted at AMO.

Comment 1

[Alfred Kayser]

See the URL above for information about 'updateInfoURL'

Comment 2

[Basil Hashem [:baz]]

I've added this to the API specification for the upcoming AMO v3.3 (http://wiki.mozilla.org/Update:RequirementsV33#Add-Ons_Details)

Comment 3

[Michael Morgan [:morgamic]]

This is actually a metabug since there are subsequent changes that have to happen for full support:
- database modification
- developer control panel additem change to parse updateinfourl
- update service changed to deliver this data

Comment 4

[Justin Scott [:fligtar]]

This new field actually seems to be in the update.rdf, not install.rdf. So, there are no parser changes needed. We just need to create a page like addons.mozilla.org/updatenotes/{version_id} that outputs the Version Notes field for that version, and then in the update script add updateInfoURL with that new URL.

This can all be done server side.

Comment 5

[Michael Morgan [:morgamic]]

Do we know if we want users to be able to define their own updateInfoURL or will it always be on AMO?  If so we can scratch the DB part... but need to decide one way or the other.

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

If we make it always be AMO, we'll have much better version info on the site, though we'll probably want to fix the limited-HTML bug sooner rather than later.

Comment 7

[Justin Scott [:fligtar]]

Mossop, how does localization of the update info work? Is there a %LOCALE% or something that can be inserted into the URL?

That would definitely be one advantage of having it on AMO.

Comment 8

[Dave Townsend [:mossop]]

(In reply to comment #7)
> Mossop, how does localization of the update info work? Is there a %LOCALE% or
> something that can be inserted into the URL?
> 
> That would definitely be one advantage of having it on AMO.
> 

I was under the impression that the locale was included in the default amo update url but it turns out not. Must have been thinking of app update. Filed bug 399932 to get a usable locale into the url.

Comment 9

[Justin Scott [:fligtar]]

Laura's been working on this, I think.

Comment 11

[Justin Scott [:fligtar]]

Moving to public pages, as the two things needed for this bug are a new public pages URL and a tiny modification to the VersionCheck script.

Comment 12

[Justin Scott [:fligtar]]

morgamic, I finished my other 3.4.2 bugs and can take this if needed.

Comment 13

[Justin Scott [:fligtar]]

Attachment: patch, v1

Stealing.

Comment 14

[Michael Morgan [:morgamic]]

Comment on attachment 320380 [details] [diff] [review]
patch, v1

346     $updateInfoURL = "<em:updateInfoURL>".SITE_URL."/versions/updateInfo/{$update['version_id']}/%APP_LOCALE%/</em:updateInfoURL>";

Pretty sure we don't want %APP_LOCALE% in there.

Comment 15

[Justin Scott [:fligtar]]

(In reply to comment #14)
> Pretty sure we don't want %APP_LOCALE% in there.
> 

Why not?

Comment 16

[Michael Morgan [:morgamic]]

My fault, I tested this wrong.  %APP_LOCALE% is sent back to fx and gets substituted before the "Show Information" link is created.

So my question is reduced to why reparse it and do the substitution if the locale will always be the same as the locale passed to versioncheck?

That is however a minor detail.

Comment 17

[Justin Scott [:fligtar]]

Firefox parses the URL for variables and does the replace regardless (http://mxr.mozilla.org/mozilla/source/toolkit/mozapps/extensions/src/nsExtensionManager.js.in#8455), so I don't see why we should do this work on the server when the client's going to do the "work" anyway.

Comment 18

[Michael Morgan [:morgamic]]

Comment on attachment 320380 [details] [diff] [review]
patch, v1

Ok, works for me.

Comment 19

[Justin Scott [:fligtar]]

Checked in r13031.

Comment 20

[Stephen Donner [:stephend] Not actively reading bugmail]

afaict, nothing's exposed on the AMO website for this, right?  It's client-side only, and would show up in the unzipped XPI's XML?

(How do I verify this?)

Comment 21

[Michael Morgan [:morgamic]]

You'd have to change your extensions.update.url to point to previews:
https://previews.addons.mozilla.org/services/update.php?restofthestuff

From there, you'd want to download an old extension then update it.  You could use NNT as an example.  When updating, you should have the option of showing more info, and if you click the button you'll see the more info text in the side pane of the extensions manager.

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED by changing extensions.update.url to https://preview.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE% and following morgamic's instructions in comment 21 with an older version of the Mozilla QA Companion; see screenshot, above.

Comment 24

[kitchin]

Is this supposed to be working in the new Minefield AOM?

Comment 25

[Dave Garrett]

(In reply to comment #24)
> Is this supposed to be working in the new Minefield AOM?

I would think so, if not file a new bug if needed. This is for the AMO server side part of things for this anyway, and is old at that.