Closed Bug 963013 Opened 8 years ago Closed 8 years ago

[Messages][Refresh] Update bubbles style and layout of the thread.

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 fixed)

VERIFIED FIXED
2.0 S3 (6june)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: borjasalguero, Assigned: azasypkin)

References

Details

(Whiteboard: [p=1])

Attachments

(11 files, 11 obsolete files)

46 bytes, text/x-github-pull-request
julienw
: review+
Details | Review
31.57 KB, image/png
vicky
: ui-review+
Details
51.47 KB, image/png
vicky
: ui-review+
Details
49.03 KB, image/png
vicky
: ui-review-
Details
14.93 KB, image/png
vicky
: ui-review+
Details
17.28 KB, image/png
vicky
: ui-review+
Details
46 bytes, text/x-github-pull-request
steveck
: review+
Details | Review
13.09 KB, image/png
vicky
: ui-review+
Details
42.55 KB, image/png
vicky
: ui-review+
Details
50.49 KB, image/png
vicky
: ui-review+
Details
21.69 KB, image/png
vicky
: ui-review+
Details
The goal of this bug is to implement the new layout based on https://bug951672.bugzilla.mozilla.org/attachment.cgi?id=8361733

In this bug *the photo of the user will not be included in the layout of the bubbles*. This will be solved in other bug, keeping an eye on the performance. I'll attach the bug number as a dependency.
Blocks: 951672
Assignee: nobody → joan.leon
Blocks: 963017
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
blocking-b2g: --- → 1.4?
VD refresh issues are not blockers for the release, so not blocking.
blocking-b2g: 1.4? → backlog
Blocks: 980461
Hey Joan, do you have plans to work on this any time soon?
Flags: needinfo?(joan.leon)
Hi Aleh, tomorrow I want to start with it
Flags: needinfo?(joan.leon)
(In reply to Joan Leon [:joan] from comment #3)
> Hi Aleh, tomorrow I want to start with it

Great! Thanks for the update, just trying to figure out what we can proceed with and what is dependent on Building Blocks so that we can push it forward.
Joan, basically, Oleg can help you on the Visual Refresh, so you can assign him some bugs if necessary.
Target Milestone: 1.3 C3/1.4 S3(31jan) → 1.4 S6 (25apr)
Hey Joan, it looks like bug 980461 overlaps with this one. Could you please let me know what of the issues described in bug 980461 (see attachment) are going to be fixed in the scope of the patch you're working on? I just like to avoid double work.
Flags: needinfo?(joan.leon)
Hi Oleg, seeing the Bug 980461 refers to the attachment, I'm not working on them. After a few days of vacation, I return to work and this afternoon I will spend a PR of my branch
Flags: needinfo?(joan.leon)
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
No longer blocks: 980461
QA Contact: lolimartinezcr
feature-b2g: --- → 2.0
Joan, do you need help with this bug?
Flags: needinfo?(joan.leon)
Hi Julien, yo function header date with property stiky the groups: 

<header>...</header>
<ul>...</ul>

should be in a container, such as <section>. 

<section>
   <header>...</header>
   <ul>...</ul>
</section>

It is controlled from JS, since the list is assembled dynamically.
Flags: needinfo?(joan.leon)
Joan, do you mean that this bug should only update how the JS generates the markup? Then maybe the SMS team can take it?

Is there a pending patch in bug 951672 that we can use to test our code?
Flags: needinfo?(joan.leon)
Blocks: 990537
Joan, we discussed internally and we can take this bug for this sprint, please answer the question in comment 10 and we'll be able to move forward.

Thanks!
Blocks: sms-sprint-1
Whiteboard: [p=2]
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
Hai Julien,

the only thing missing is that the header + ul groups are in a container, as <section>. Should be changed from JS, I think if you look at a person skilled in JS may expedite this Bug.
Flags: needinfo?(joan.leon)
This will be taken by someone from the SMS team.
Assignee: joan.leon → nobody
I'm looking into it right now.
Assignee: nobody → azasypkin
Status: NEW → ASSIGNED
Added WIP patch for wrapping date header and message list into single section. Patch based on patch from bug 871432.

Joan, could you please preliminarily check this out and say whether it's what you was missing to fully resolve this bug?

Thanks!
Flags: needinfo?(joan.leon)
Flags: needinfo?(joan.leon)
Hi Oleg,

I have conflicts to apply the patch… you can do a rebase and you let me know?

Thanks
Hey Joan, I've just rebased my PR, please check it once again.

Thanks!
Attached image bubbles thread 1 (obsolete) —
Attachment #8424883 - Flags: ui-review?(vpg)
Attached image bubbles thread 2 (obsolete) —
Attachment #8424885 - Flags: ui-review?(vpg)
Attachment #8424886 - Flags: ui-review?(vpg)
Attached image bubbles thread sticky date (obsolete) —
Attachment #8424887 - Flags: ui-review?(vpg)
Comment on attachment 8424885 [details]
bubbles thread 2

Can you please use regular font for timestamp and put the subheader text (99791495) in #575757? thanks
Attachment #8424885 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8424886 [details]
bubbles thread sticky date (push previous date)

Can you please use regular font for timestamp and put the subheader text (99791495) in #575757? thanks
Attachment #8424886 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8424887 [details]
bubbles thread sticky date

Can you please use regular font for timestamp and put the subheader text (99791495) in #575757? thanks
Attachment #8424887 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8424883 [details]
bubbles thread 1

Sticky header should contain date but not time if the time is displayed inside the bubbles. 

Can you please use regular font for timestamp and put the subheader text (99791495) in #575757? thanks
Attachment #8424883 - Flags: ui-review?(vpg) → ui-review-
Attachment #8423706 - Attachment description: GitHub pull request URL (wrapper for header+ul, wip) → GitHub pull request URL (wrapper for header+ul)
Attachment #8423706 - Flags: review?(felash)
That's strange because we definitely removed the time from the headers in bug 871432. I think one rebase regressed it.
(In reply to Julien Wajsberg [:julienw] from comment #26)
> That's strange because we definitely removed the time from the headers in
> bug 871432. I think one rebase regressed it.

Yep, it was an issue in my template, now it's fixed.
Attached file Patch in GitHub with Styles for VR (obsolete) —
Attachment #8425445 - Flags: review?(felash)
Comment on attachment 8423706 [details] [review]
GitHub pull request URL (wrapper for header+ul) [checked in: comment 36]

This looks good,

I also checked that performance-wise there is no regression.

(pretty empirically: I run this in one shell:

  adb shell top -s cpu -d 1 -m 3 | grep <message pid> | wc -l

and this in another shell:

  adb shell top -s cpu -d 1 -m 3

then open big thread, then wait that the process disappears in the second shell, then "killall adb".)

I'd like a second round of review: can you please fix the nits in a separate commit to make the second review easy?

Thanks !
Attachment #8423706 - Flags: review?(felash)
Comment on attachment 8425445 [details] [review]
Patch in GitHub with Styles for VR

added lots of comments on github

this looks good but I think we can simplify and clean up more things + one small remaining issue.

If you can add your next changes in a separate commit, it would make it easier to review the next round.
Please request review once you're ready !

Thanks !
Attachment #8425445 - Flags: review?(felash)
Comment on attachment 8423706 [details] [review]
GitHub pull request URL (wrapper for header+ul) [checked in: comment 36]

(In reply to Julien Wajsberg [:julienw] from comment #29)
> Comment on attachment 8423706 [details] [review]
> GitHub pull request URL (wrapper for header+ul)
> 
> This looks good,
> 
> I also checked that performance-wise there is no regression.
> 
> (pretty empirically: I run this in one shell:
> 
>   adb shell top -s cpu -d 1 -m 3 | grep <message pid> | wc -l
> 
> and this in another shell:
> 
>   adb shell top -s cpu -d 1 -m 3
> 
> then open big thread, then wait that the process disappears in the second
> shell, then "killall adb".)
> 
> I'd like a second round of review: can you please fix the nits in a separate
> commit to make the second review easy?
> 
> Thanks !

Thanks for review! I've fixed nits and added more "ThreadUI.appendMessage" tests.
Attachment #8423706 - Flags: review?(felash)
Comment on attachment 8423706 [details] [review]
GitHub pull request URL (wrapper for header+ul) [checked in: comment 36]

r=me for the structure refactoring patch
Attachment #8423706 - Flags: review?(felash) → review+
Blocks: 1014686
(In reply to Julien Wajsberg [:julienw] from comment #32)
> Comment on attachment 8423706 [details] [review]
> GitHub pull request URL (wrapper for header+ul)
> 
> r=me for the structure refactoring patch

Thanks for review! Also as we agreed I've filed follow-up bug 1014686.

Travis is green, do you want this patch to be landed only once CSS part is ready or we can land it separately?
Flags: needinfo?(felash)
Oleg, since it does not break the current app, you can land now this patch.
Flags: needinfo?(felash)
Note to sheriffs: please, land "GitHub pull request URL (wrapper for header+ul)" patch only. Second one will follow later.

Thanks!
Keywords: checkin-needed
Comment on attachment 8423706 [details] [review]
GitHub pull request URL (wrapper for header+ul) [checked in: comment 36]

Master: https://github.com/mozilla-b2g/gaia/commit/30e0a8a6665433a605adb7ee0dfb91a67e4727d6
Attachment #8423706 - Attachment description: GitHub pull request URL (wrapper for header+ul) → GitHub pull request URL (wrapper for header+ul) [checked in: comment 36]
Blocks: sms-sprint-2
Whiteboard: [p=2] → [p=1]
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
Hey Victoria,

Can you let us know what we should do with the long MMS subject? In the current Joan's patch ellipssis is used ("..."), but currently it's wrapped into two lines.

Thanks!
Flags: needinfo?(vpg)
Hey Victoria, I'm going to post several screenshots for you to review. I'll add comment for every screenshot to what I'd like to look at :):

* Colors and text for incoming and outgoing SMS
Attachment #8424883 - Attachment is obsolete: true
Attachment #8424885 - Attachment is obsolete: true
Attachment #8424886 - Attachment is obsolete: true
Attachment #8424887 - Attachment is obsolete: true
Attachment #8429227 - Flags: ui-review?(vpg)
Attached image Sticky date header (default state) (obsolete) —
* Sticky date header (default state, at the top)
Attachment #8429229 - Flags: ui-review?(vpg)
* Sticky date header (intermediate state, overlaying message)
Attachment #8429230 - Flags: ui-review?(vpg)
* Sticky date header + subheader (carrier header), default state
Attachment #8429231 - Flags: ui-review?(vpg)
* Sticky date header + subheader (carrier header), intermediate state. Sticky header is overlaying message with transparency while subheader is in a plain white color.
Attachment #8429234 - Flags: ui-review?(vpg)
* Incoming MMS with subject, color and text of the subject
Attachment #8429236 - Flags: ui-review?(vpg)
Outgoing MMS with subject, colors and text
Attachment #8429239 - Flags: ui-review?(vpg)
Attached image Long subject (wrap into two lines) (obsolete) —
* Long subject (wrap into two lines);
* Error state icon;
* Error state colors and text.
Attachment #8429240 - Flags: ui-review?(vpg)
Attached image Long subject (ellipsis) (obsolete) —
* Long subject (ellipsis). Related to the comment 37
Attachment #8429241 - Flags: ui-review?(vpg)
* File name (changed to italic font style)
Attachment #8429242 - Flags: ui-review?(vpg)
Attachment #8429227 - Flags: ui-review?(vpg) → ui-review+
Flags: needinfo?(vpg)
Comment on attachment 8429229 [details]
Sticky date header (default state)

The text inside the sticky header looks a bit light, can you please make it #575757?

thanks!
Attachment #8429229 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8429230 [details]
Sticky date header (intermediate state)

Transparency is ok. (please fix the text color for the date)
Attachment #8429230 - Flags: ui-review?(vpg) → ui-review+
Attachment #8429242 - Flags: ui-review?(vpg) → ui-review+
Attachment #8429239 - Flags: ui-review?(vpg) → ui-review+
Attached image Sticky date header (default state) (obsolete) —
* Sticky date header (default state), updated text color to #575757

Does it look better now?

Thanks!
Attachment #8429229 - Attachment is obsolete: true
Attachment #8429395 - Flags: ui-review?(vpg)
Comment on attachment 8429241 [details]
Long subject (ellipsis)

Ellipsis OK. But the "!" icon has a wrong alignment
Attachment #8429241 - Flags: ui-review?(vpg) → ui-review-
(In reply to Victoria Gerchinhoren [:vicky] from comment #51)
> Comment on attachment 8429241 [details]
> Long subject (ellipsis)
> 
> Ellipsis OK. But the "!" icon has a wrong alignment

Just to confirm, in case of ellipsis user won't have ways to see full subject if it's too long, is that OK?
Flags: needinfo?(vpg)
Comment on attachment 8429240 [details]
Long subject (wrap into two lines)

Can you please check that the subject text is #333333, it looks lighter.

"!" icon is not well aligned, it should be vertically centered in the available bubble space, minus the subject strip.

Please make the line height 1.7 rem for the 2 lines subject.
Attachment #8429240 - Flags: ui-review?(vpg) → ui-review-
(In reply to Oleg Zasypkin [:azasypkin] from comment #52)
> (In reply to Victoria Gerchinhoren [:vicky] from comment #51)
> > Comment on attachment 8429241 [details]
> > Long subject (ellipsis)
> > 
> > Ellipsis OK. But the "!" icon has a wrong alignment
> 
> Just to confirm, in case of ellipsis user won't have ways to see full
> subject if it's too long, is that OK?

How's specified in the interaction specs?
Flags: needinfo?(vpg)
(In reply to Victoria Gerchinhoren [:vicky] from comment #54)
> (In reply to Oleg Zasypkin [:azasypkin] from comment #52)
> > (In reply to Victoria Gerchinhoren [:vicky] from comment #51)
> > > Comment on attachment 8429241 [details]
> > > Long subject (ellipsis)
> > > 
> > > Ellipsis OK. But the "!" icon has a wrong alignment
> > 
> > Just to confirm, in case of ellipsis user won't have ways to see full
> > subject if it's too long, is that OK?
> 
> How's specified in the interaction specs?

I definitely can check, but can you point me to the place where I can find this spec?
Comment on attachment 8429231 [details]
Sticky date header + subheader (carrier header), default state

Oleg, this case with numbered date and only a number as phone information creates a really odd situation in the subheader area. 

Please follow the specs I have just uploaded indicating a divider line, opacity, color and alignment for the elements in the header:

https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571

(It's uploaded in messaging metabug)
Attachment #8429231 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8429234 [details]
Sticky date header + subheader (carrier header), intermediate state

Please adjust this to new specs. Thanks!

https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571
Attachment #8429234 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8429236 [details]
Incoming MMS with subject

Please make sure time stamp has a 70% opacity. The rest OK.
Attachment #8429236 - Flags: ui-review?(vpg) → ui-review-
Comment on attachment 8429395 [details]
Sticky date header (default state)

Please check the specs for alignment, opacity and color: https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571
Attachment #8429395 - Flags: ui-review?(vpg) → ui-review-
(In reply to Oleg Zasypkin [:azasypkin] from comment #55)
> (In reply to Victoria Gerchinhoren [:vicky] from comment #54)
> > (In reply to Oleg Zasypkin [:azasypkin] from comment #52)
> > > (In reply to Victoria Gerchinhoren [:vicky] from comment #51)
> > > > Comment on attachment 8429241 [details]
> > > > Long subject (ellipsis)
> > > > 
> > > > Ellipsis OK. But the "!" icon has a wrong alignment
> > > 
> > > Just to confirm, in case of ellipsis user won't have ways to see full
> > > subject if it's too long, is that OK?
> > 
> > How's specified in the interaction specs?
> 
> I definitely can check, but can you point me to the place where I can find
> this spec?

The interaction spec for MMS subject is at [1] (I try to link the various repositories in [2]).

[1] https://mozilla.app.box.com/s/0u4jt353ei9ov2c150ip/1/1170795225/11918301182/1
[2] https://wiki.mozilla.org/Gaia/SMS#Design_Specs
We can also NI Omega or Jenny to ask for more information here.
(In reply to Victoria Gerchinhoren [:vicky] from comment #56)
> Comment on attachment 8429231 [details]
> Sticky date header + subheader (carrier header), default state
> 
> Oleg, this case with numbered date and only a number as phone information
> creates a really odd situation in the subheader area. 
> 
> Please follow the specs I have just uploaded indicating a divider line,
> opacity, color and alignment for the elements in the header:
> 
> https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571
> 
> (It's uploaded in messaging metabug)

Great, thanks!
(In reply to Julien Wajsberg [:julienw] from comment #61)
> We can also NI Omega or Jenny to ask for more information here.

Thanks for the link! This spec declares that subject should wrap if it's too long. So if it's the latest spec, patch shouldn't change this behaviour.
Hey Jenny, Omega, can you please give a definitive answer for comment 63?
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Hey Victoria, I'd like to confirm several points:

> Please make sure time stamp has a 70% opacity. The rest OK.
Yes its opacity is 70%, color #000 (https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8403322). Or we should use #333 now?

> Can you please check that the subject text is #333333, it looks lighter.
Do we have the same color for subject for incoming and outgoing messages?

> Please adjust this to new specs. Thanks!
> https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571
I see that spec introduces new format of carrier header ("phone_type, phone_number carrier") + "carrier" has different text color. Currently we have the following formats:
 1. "phone_type | carrier" - if carrier defined;
 2. "phone_type | phone_number" - if no carrier defined;
 3. "phone_type" - if contact doesn't have name and carrier defined;

So do you want change " | " to ", " in cases #1-#2 and additionally add "phone_number" to the case #1?

Also I've noticed that we have CSS rule that changes text color of the message that is in "sending" state. Do we still need this, I can't find this requirement in previous specs?
Flags: needinfo?(vpg)
Depends on: 1008890
(In reply to Oleg Zasypkin [:azasypkin] from comment #65)
> Hey Victoria, I'd like to confirm several points:
> 
> > Please make sure time stamp has a 70% opacity. The rest OK.
> Yes its opacity is 70%, color #000
> (https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8403322). Or we
> should use #333 now?
> 
No, it might be a rendering issue, keep it at #00 as I say and 70% opacity.

> > Can you please check that the subject text is #333333, it looks lighter.
> Do we have the same color for subject for incoming and outgoing messages?
> 
Yes.

> > Please adjust this to new specs. Thanks!
> > https://bug950175.bugzilla.mozilla.org/attachment.cgi?id=8429571
> I see that spec introduces new format of carrier header ("phone_type,
> phone_number carrier") + "carrier" has different text color. Currently we
> have the following formats:
>  1. "phone_type | carrier" - if carrier defined;
>  2. "phone_type | phone_number" - if no carrier defined;
>  3. "phone_type" - if contact doesn't have name and carrier defined;

This was already specd and I am changing the alignment, and color to make it neater. Maybe it is being changed in a different bug, but I can't recall which.

The way information is shown was decided a while ago from a IA POV. So please follow it how it is, I don't have a reason to change it.
> 
> So do you want change " | " to ", " in cases #1-#2 and additionally add
> "phone_number" to the case #1?

In general, we don't use the "|" because of a very old issue with localization. So everything migrated to the "," and I suggest to use the comma in order to keep consistency.
> 
> Also I've noticed that we have CSS rule that changes text color of the
> message that is in "sending" state. Do we still need this, I can't find this
> requirement in previous specs?

I think this is still valid, so better to keep it.

Thanks!
Flags: needinfo?(vpg)
Hey Steve,

It's a follow-up from unfinished Joan's patch (see https://github.com/mozilla-b2g/gaia/pull/19437 for first review round comments). I've tried to address Julien's comments in a separate commit in my PR so that you can see diff + addressed almost all comments from Victoria (except different carrier text styling part as it depends on bug 1008890), so I think it's ready for review.

Once bug 1008890 is resolved, I'll make necessary changes and ask for the second review round (including ui-review) only for the carrier header part :)

Thanks!
Attachment #8425445 - Attachment is obsolete: true
Attachment #8430975 - Flags: review?(schung)
Hey Victoria, here are some updates for sticky header and subheader:
* Height and paddings have been adjusted per spec you provided;
* Color of the carrier name differs from the rest of the header text now( #237171);
* " | " separator is still here, we'll update it in the separate bug.
Attachment #8429231 - Attachment is obsolete: true
Attachment #8432321 - Flags: ui-review?(vpg)
* Opacity of the header is 95%;
* Opacity of the subheader is 85%.
Attachment #8429234 - Attachment is obsolete: true
Attachment #8432322 - Flags: ui-review?(vpg)
* Default state of sticky header without without carrier header.
Attachment #8429395 - Attachment is obsolete: true
Attachment #8432323 - Flags: ui-review?(vpg)
See bug 883911 for the "|" issue, and bug 925404 for always showing the phone number even when the carrier is known.
Comment on attachment 8432321 [details]
Sticky date header + subheader (carrier header), default state

The "|" separator should eventually be changed for a comma. 

Thanks!
Attachment #8432321 - Flags: ui-review?(vpg) → ui-review+
Attachment #8432322 - Flags: ui-review?(vpg) → ui-review+
Attachment #8432323 - Flags: ui-review?(vpg) → ui-review+
Duplicate of this bug: 1017854
Comment on attachment 8429241 [details]
Long subject (ellipsis)

As discussed with Omega and Jenny offline we'll keep current behaviour for the long subject case: wrap it into two lines if needed + reduce line-height as Victoria suggested.
Attachment #8429241 - Attachment is obsolete: true
Flags: needinfo?(ofeng)
Flags: needinfo?(jelee)
Hey Victoria, I've adjusted line-height and padding for the MMS subject. Does it look better now?
Attachment #8429240 - Attachment is obsolete: true
Attachment #8433076 - Flags: ui-review?(vpg)
Attachment #8433076 - Flags: ui-review?(vpg) → ui-review+
QA Contact: lolimartinezcr
Hi Julien, I just have a concern about the sticky position in thread view[1]. Since Vicky agreed having 2 headers(carrier/date) on the top, does this really affects performance if we simply apply sticky position here?

[1]https://github.com/mozilla-b2g/gaia/pull/19671/files#discussion_r13380890
Flags: needinfo?(felash)
About "position: sticky", I discussed about this with Vivien. Performance issues if you have a lot (read: more than 3 or 4) of sticky positioned _visible_ elements. As long as they're not visible, they don't impair performance.

In the inbox, it is very likely to have several of them, that's why the sticky header library is still useful. In the thread view, it's a lot less likely, because messages are likely several lines high.

So I'd say it's fine to use "position: sticky" for the headers in this view, unless we find issues later.

Hope this is clear enough !
Flags: needinfo?(felash)
Hey Steve, thanks for your suggestions on the PR! I've updated it and made Travis green :)
Comment on attachment 8430975 [details] [review]
GitHub pull request URL (styling part)

Thanks for the great work! r=me and let's focus on the carrier header next.
Attachment #8430975 - Flags: review?(schung) → review+
in master: 874df997cb6f527fe96cc78e26e339f26fd2c7d8
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 1036308
Tested and working:
Hamachi
2.0
Gecko-7a31c32
Gaia-1bd6e89
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.