If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Add support for updateInfoUrl

VERIFIED FIXED in 3.4.2

Status

addons.mozilla.org Graveyard
Public Pages
VERIFIED FIXED
10 years ago
2 years ago

People

(Reporter: Alfred Kayser, Assigned: fligtar)

Tracking

unspecified
3.4.2
Dependency tree / graph

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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.
(Reporter)

Comment 1

10 years ago
See the URL above for information about 'updateInfoURL'

Comment 2

10 years ago
I've added this to the API specification for the upcoming AMO v3.3 (http://wiki.mozilla.org/Update:RequirementsV33#Add-Ons_Details)
Component: Add-ons → Administration
QA Contact: add-ons → administration
Summary: Gecko 1.9/Firefox 3.0 supports updateInfoURL, but AMO doesn't → Add support for updateInfoUrl in update service
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
Summary: Add support for updateInfoUrl in update service → Add support for updateInfoUrl
(Assignee)

Comment 4

10 years ago
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.
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.
Depends on: 399890
Depends on: 399904
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.
(Assignee)

Comment 7

10 years ago
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.
(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.
(Assignee)

Comment 9

10 years ago
Laura's been working on this, I think.
Assignee: nobody → laura
Blocks: 408146
(Assignee)

Updated

10 years ago
Duplicate of this bug: 303719

Updated

10 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → 3.3
Target Milestone: 3.3 → 3.4

Updated

10 years ago
Assignee: laura → nobody
Status: ASSIGNED → NEW
Component: Administration → Developer Pages
QA Contact: administration → developers

Updated

10 years ago
Assignee: nobody → laura
(Assignee)

Comment 11

10 years ago
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.
Component: Developer Pages → Public Pages
QA Contact: developers → web-ui

Updated

10 years ago
Target Milestone: 3.4 → 3.4.2
Assignee: laura → morgamic
(Assignee)

Comment 12

10 years ago
morgamic, I finished my other 3.4.2 bugs and can take this if needed.
(Assignee)

Comment 13

10 years ago
Created attachment 320380 [details] [diff] [review]
patch, v1

Stealing.
Assignee: morgamic → fligtar
Status: NEW → ASSIGNED
Attachment #320380 - Flags: review?(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.
Attachment #320380 - Flags: review?(morgamic) → review-
(Assignee)

Comment 15

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

Why not?
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.
(Assignee)

Comment 17

10 years ago
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 on attachment 320380 [details] [diff] [review]
patch, v1

Ok, works for me.
Attachment #320380 - Flags: review- → review+
(Assignee)

Comment 19

10 years ago
Checked in r13031.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: push-needed
Resolution: --- → FIXED
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?)
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.
Created attachment 320867 [details]
Screenshot
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.
Status: RESOLVED → VERIFIED

Updated

10 years ago
Keywords: push-needed

Comment 24

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

Comment 25

8 years ago
(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.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.