Closed Bug 781233 Opened 12 years ago Closed 12 years ago

B2G Updates: Expose Gecko update detailsURL

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-kilimanjaro:?, blocking-basecamp:-)

RESOLVED FIXED
blocking-kilimanjaro ?
blocking-basecamp -

People

(Reporter: marshall, Assigned: marshall)

References

Details

After a major update has been applied, Firefox will open the detailsURL from the update XML (see the wiki: https://wiki.mozilla.org/Software_Update:updates.xml_Format). We might need to expose this URL up to Javascript somehow, so we can: - Allow the end user to click on it in Settings > About Phone so they can read about new features - Maybe even show a system notification about the new update, that opens the browser app w/ the detailsURL
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
Josh, we'd like UX input here.
Keywords: uiwanted
Whiteboard: [blocked-on-input Josh Carpenter]
I recommend we keep this simple, but not block on this. Go to About in Settings, and offer 'relnotes' based on the latest Gecko update. We can keep the content pretty text based to begin with. Concerns with this approach?
I think it's a good idea, but also the least important part of the Gecko+Gaia update process. Agree with Chris; we can start by providing details in Settings > Device > Device Information. Not a blocker.
AFAIK, the detailsURL isn't tied to any specific format. HTML is used for Fx releases, but there's no reason we couldn't use plain text (or something else) for FxOS initially. The main point of this bug is to cover exposing that property up to Gaia. My current patch is sending the detailsURL directly along with the update-prompt chrome event, so we may be able to close this soon anyway
I've incorporated Update Details into my Updates flows, available here: * App Update specs: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT
Keywords: uiwanted
Whiteboard: [blocked-on-input Josh Carpenter]
Marshall says this isn't a v1 blocker.
blocking-basecamp: ? → -
FWIW, what Firefox desktop does * specify a detailsURL in the update.xml that points to the release notes for that release * in the default UX the update is downloaded in the background, and after some hours without a restart there is a dialog that prompts the user to a restart. There is a Details link on this dialog which uses detailsURL * after the update has been successfully applied the default is to open detailsURL in a new tab. This can be suppressed by including |actions="silent"| in the update.xml. We've been doing this unless there is something specifically to tell the user about, in the interests of making updates as silent as possible There is another mode that may be of use - the idea of a major update, which was used this when we had long-lived branches (eg 3.6 to 4.0 or higher. The UX is to prompt with a dialog showing a billbaord listing some incentives, and buttons for Later/Never/Install. This is controlled by billboardURL and showPrompt definitions in the xml, and possibly also type="major".
Marking as FIXED, detailsURL has been included in the update chrome events for a little while now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.