Closed Bug 834462 Opened 7 years ago Closed 4 years ago

There should be more information (e.g. build ID / version number, link to release notes) listed in the notification of a system update in Firefox OS

Categories

(Firefox OS Graveyard :: Gaia::System, enhancement)

All
Gonk (Firefox OS)
enhancement
Not set

Tracking

(feature-b2g:2.5+, b2g18-)

RESOLVED FIXED
FxOS-S8 (02Oct)
feature-b2g 2.5+
Tracking Status
b2g18 - ---

People

(Reporter: gkw, Assigned: gsvelto)

References

Details

(5 keywords, Whiteboard: ux-most-wanted-nov2014,)

User Story

IxD Spec:
https://mozilla.box.com/s/j9dsl6ilwvqvc9s1mt2dzw33xte87gpp

Attachments

(4 files, 4 obsolete files)

Build Identifier: 20130116230203
Git commit info: 3c84fa2b74b3dbe591f0d4fbedbac9aac...

When I check for updates and if there is an update, in the dropdown of the notification, it specifies "System update" and the size of the update.

Now that Firefox OS 1.0RC1 is sort-of ready, it will be nice to know *what* version / build I'm updating to.

Is it 1.0.0.0? Or 1.0.0.1? Or 1.0.1.0? or 1.1.0.0?
There is some additional information presented to gaia in the update-available notification.

I believe that the available information comes from the update.xml file. Our nightlies currently use:

http://update.boot2gecko.org/nightly/update.xml

which looks like (reformatted to make it look nicer here):

<?xml version="1.0"?>
<updates>
  <update
    type="minor"
    appVersion="18.0"
    version="18.0"
    extensionVersion="18.0"
    buildID="20130124070201" 
    licenseURL="http://www.mozilla.com/test/sample-eula.html" 
    detailsURL="http://www.mozilla.com/test/sample-details.html"
  >
    <patch
      type="complete" URL="http://update.boot2gecko.org/nightly/b2g_update_20130124070201.mar?build_id=20130124070201&amp;version=18.0"
      hashFunction="SHA512"
      hashValue="00...79"
      size="51209288"
    />
  </update>
</updates>

buildID seems to be the most useful piece. I'm not sure where the 1.0.0.0 stuff would fit in. There is a field called displayVersion that I see as one of the fields parsed.

The code sets displayVersion to version if displayVersion is missing.
So having both the version number and the release notes link present in that notification will likely also be useful, since we have those information seemingly readily available in http://update.boot2gecko.org/nightly/update.xml

Also guessing that this should be in the Gaia component.
Component: General → Gaia
Summary: There should be a version number listed in the notification of a system update in Firefox OS → There should be more information (e.g. build ID / version number, link to release notes) listed in the notification of a system update in Firefox OS
Component: Gaia → Gaia::System
Blocks: 950769
Keywords: feature
Blocks: fxos-papercuts
No longer blocks: 950769
QA Whiteboard: ux-most-wanted
Depends on: 1098041
Blocks: 1098041
No longer depends on: 1098041
Blocks: 994991
Whiteboard: ux-most-wanted-nov2014
Duplicate of this bug: 1115397
What is status of this ?
We can add info=" information about this update" in update.xml
and gaia should show content is info from update.xml
(In reply to dattaz from comment #4)
> What is status of this ?
> We can add info=" information about this update" in update.xml
> and gaia should show content is info from update.xml

Dattaz, before working on exposing strings to the user, maybe you can start by just exposing the versions/build infos when we get the update prompt ?
Gabriele and Kai, I think this is the kind of feature that partners may want to have.
Flags: needinfo?(kli)
Flags: needinfo?(gsvelto)
Yes, our partners discussed this kind of feature with me.
Flags: needinfo?(kli)
Clearing my NI, since Kai-Zhen already replied. BTW Kai-Zhen will you post a summary of what they might need here once you're done gathering their requirements?
Flags: needinfo?(gsvelto)
Including in polish. While working on bug 1102959 I've noticed that the mozChromeEvent sent by Gecko does indeed contains some (maybe all?) of the XML field. So we could easily augment the dialog.
Assignee: nobody → lissyx+mozillians
Keywords: polish
Whiteboard: ux-most-wanted-nov2014 → ux-most-wanted-nov2014, [systemsfe]
Stephany, what's your point of view regarding comment 9 ?
Flags: needinfo?(swilkes)
I'm the UX Program Manager and am not the UX person assigned to this area. Flagging Rob as he worked on this bug previously.
Flags: needinfo?(swilkes) → needinfo?(rmacdonald)
I'm going to start hacking a new dialog exposing those infos.
Attached image Capture du 2015-04-16 17:45:36.png (obsolete) —
Quickly hacked UI. We need to check with UX:
 - which properties do we want to display, and how
 - how can we display release notes

And also, can we make use of the detailsURL for those release notes?
Robert, I see you have a long history of hacking and reviewing the code in toolkit/mozapps/update/nsUpdateService.js so you can probably help me answer this question: can we make use of detailsURL field to link to and display some release notes for a build ?
Flags: needinfo?(robert.strong.bugs)
Definitely... it has been used for exactly that in the distant past.

Keep in mind that it can be specified in the update.xml and if it isn't specified there the app.update.url.details pref will be checked for a value.
Flags: needinfo?(robert.strong.bugs)
Attachment #8593431 - Attachment is obsolete: true
Blocks: 1157213
Adam, this is something that can be interesting for you. I'm also tagging this as foxfood this it might make a lot of sense in this context.
Flags: needinfo?(adam)
Keywords: foxfood
See Also: → 1180678
Blocks: 1180678
Duplicate of this bug: 1181915
(In reply to Stephany Wilkes from comment #11)
> I'm the UX Program Manager and am not the UX person assigned to this area.
> Flagging Rob as he worked on this bug previously.

This needinfo is pending for several months. Needinfo firefoxos-ux-bugzilla@mozilla.com here.
Flags: needinfo?(firefoxos-ux-bugzilla)
Harly/Rob,
Do we have UX resource assigned for the "update notification" ?
This feature is included in 2.5 scope.
feature-b2g: --- → 2.5+
Flags: needinfo?(hhsu)
Hi Jacqueline,
Are you on top of this?
Flags: needinfo?(jsavory)
Flags: needinfo?(hhsu)
Flags: needinfo?(firefoxos-ux-bugzilla)
Assignee: lissyx+mozillians → nobody
Whiteboard: ux-most-wanted-nov2014, [systemsfe] → ux-most-wanted-nov2014,
Hey Gregor, 
Could you find someone to take this bug?
Flags: needinfo?(anygregor)
As discussed via email, we don't have anyone that can take this bug atm.
Flags: needinfo?(anygregor)
I’ve provided a link to the latest OTA spec here as well as in the user story section. I believe that this bug should be covered in the system update dialog variations on page 10. 

Let me know if this covers all of the components we want to include in the update dialogue. If possible, it would be helpful to include a simplified list of features available in the update (screen 3 p.10) but this is only suggested if we can provide useful, concise information. 

Let me know if there is any feedback or concerns, here is the link:
https://mozilla.box.com/s/j9dsl6ilwvqvc9s1mt2dzw33xte87gpp
User Story: (updated)
Flags: needinfo?(rmacdonald)
Flags: needinfo?(jsavory)
Target Milestone: --- → FxOS-S8 (02Oct)
Flags: needinfo?(adam)
(In reply to Jacqueline Savory [:jsavory] UX from comment #25)
> I’ve provided a link to the latest OTA spec here as well as in the user
> story section. I believe that this bug should be covered in the system
> update dialog variations on page 10. 
> 
> Let me know if this covers all of the components we want to include in the
> update dialogue. If possible, it would be helpful to include a simplified
> list of features available in the update (screen 3 p.10) but this is only
> suggested if we can provide useful, concise information. 
> 
> Let me know if there is any feedback or concerns, here is the link:
> https://mozilla.box.com/s/j9dsl6ilwvqvc9s1mt2dzw33xte87gpp

Jacqueline, thanks for providing this. IMHO it fills parts of the needs. I don't really know how we can commit to a list of feature, either generate it automatically or by hand (meta bugs closed?) but this should be something workable and it's only a big deal in the case of dogfooders with frequent updates. It's less of a problem when we are talking about big releases, since we can easily prepare a nice changelog.

So I think the proposed spec just lacks build informations (version and ID). Thanks!
Flags: needinfo?(jsavory)
I'm working on this, taking Alexandre's patch as the starting point.
Assignee: nobody → gsvelto
Status: NEW → ASSIGNED
Attached image Mock of the update list (obsolete) —
After having studied the IxD doc a bit I've come up with a mock that doesn't use a separate panel but rather inserts the build ID (and optionally the link to the release notes) in the list. I'd like to have a visual design before proceeding further. In the mock I've just reused a lighter font weight for the build ID (with the same font size and box alignment) and the link has our usual cyanish color. Since I don't know if this is appropriate please feel free to correct it.
Attachment #8665391 - Flags: feedback?(padamczyk)
Comment on attachment 8665391 [details]
Mock of the update list

The fonts look fine. 
However the left and right margins should be even. It looks like the check boxes on the right are too far in, they should be aligned with the right edge of the "download" button.
Attachment #8665391 - Flags: feedback?(padamczyk) → feedback-
Thanks for the feedback Patryk, is the color of the link alright too? I haven't modified the check boxes, that's their current positioning you see in the screenshot. I can fix them as part of this bug or open another one if you prefer.
BTW I've just noticed another issue with the menu, the actual menu area is a slightly darker shade of grey than the background.
Attached image Mock of the update list v2 (obsolete) —
Here's a new screenshot with both sides of the list having the same padding. The right side had a different padding due to the RTL rules used for the start padding. Note that I didn't align the checkboxes with the right side of the "Download" button because the text on the left isn't aligned with the left edge of the "Later" button either and I think that was intended. Padding on both sides is now symmetric though.
Attachment #8665391 - Attachment is obsolete: true
Attachment #8666725 - Flags: ui-review?(padamczyk)
Comment on attachment 8666726 [details] [review]
[gaia] gabrielesvelto:bug-834462-update-dialog > mozilla-b2g:master

Here's a patch that adds the buildID and release news link to the list plus the necessary adjustments. A few remarks:

- I'm displaying a different string if there's only a system update available versus one or more regular app updates (as per the UX spec).

- The "View the full list of changes" link is not shown if there's no detailsURL field in the update manifest or if it points to about:blank (which apparently it does on some of our OTA servers).

- No tests yet, I'd like to finalize the approach before writing them.

- Besides doing the necessary CSS adjustments I've fixed a couple of issues that were introduced with the RTL changes. These correct the padding of the checkboxes on the right in LTR mode and fix the position of the labels in RTL mode (that float: "left" directive was messing up the whole layout in RTL mode). I'm not sure if that's the right way to handle the padding though, I'll have to check the RTL guidelines to see if there's a better one.

- The methods in the UpdateManager object are *huge* even without my changes, maybe it would be worth splitting them up a bit.
Attachment #8666726 - Flags: feedback?(etienne)
Comment on attachment 8666726 [details] [review]
[gaia] gabrielesvelto:bug-834462-update-dialog > mozilla-b2g:master

Wow that's pretty old code :)
But the changes look great! Ready for unit-testing.

And yes, the dom generation could be extracted quite nicely if you feel like doing the extra changes in this path (but can be a follow up too! would be a nice mentored bug).
Attachment #8666726 - Flags: feedback?(etienne) → feedback+
(In reply to Etienne Segonzac (:etienne) from comment #35)
> Wow that's pretty old code :)
> But the changes look great! Ready for unit-testing.

Great, I'll put up the tests ASAP.

> And yes, the dom generation could be extracted quite nicely if you feel like
> doing the extra changes in this path (but can be a follow up too! would be a
> nice mentored bug).

My thought exactly :)
Attachment #8593422 - Attachment is obsolete: true
Comment on attachment 8666726 [details] [review]
[gaia] gabrielesvelto:bug-834462-update-dialog > mozilla-b2g:master

Now with unit-tests added. I've noticed another thing which would be worthy of a follow-up: the UpdateManager unit-tests are calling MockNavigatorMozMobileConnections.mTeardown() in the suiteTeardown() function instead of the teardown() one. This is causing certain tests to pass even though they shouldn't as mock connections are being leaked from one test to the next one. I think it's worth investigating it as the failures might just be benign (i.e. only the test setup is wrong) or they could have hidden some real problems.
Attachment #8666726 - Flags: review?(etienne)
Attachment #8666725 - Attachment is obsolete: true
Attachment #8666725 - Flags: ui-review?(padamczyk)
Attachment #8667777 - Flags: ui-review?(padamczyk)
Attachment #8667777 - Attachment description: Screenshot of the patch in action in LTR mode → Screenshot of the patch in LTR mode
Comment on attachment 8666726 [details] [review]
[gaia] gabrielesvelto:bug-834462-update-dialog > mozilla-b2g:master

r=me with the test added, thanks!
Attachment #8666726 - Flags: review?(etienne) → review+
Thanks for the review! I've pushed a new version with the added unit-test and will be waiting for the UI review before merging.
Attachment #8667777 - Flags: ui-review?(padamczyk) → ui-review+
Merged to gaia/master c59d50f033e44c655460f1a7db70281c2cc4cd00

https://github.com/mozilla-b2g/gaia/commit/c59d50f033e44c655460f1a7db70281c2cc4cd00
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(jsavory)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.