885680 - [Messages] Subject management when composing a MMS

Status: RESOLVED FIXED

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

Description

[Borja Salguero [:borjasalguero]]

We have to show the subject in the MMS App when receiving a MMS.

Comment 1

[Alex Keybl [:akeybl]]

(In reply to Borja Salguero [:borjasalguero] from comment #0)
> We have to show the subject in the MMS App when receiving a MMS.

Cert issue or implementation detail?

Comment 2

[Alex Keybl [:akeybl]]

Bug 885679 suggests that this is likely a cert issue. Dietrich - can you confirm?

Comment 3

[Gene Lian (I already quit Mozilla)]

The Gecko has exposed the |subject| in the MMS dom message object. Sounds like a pure Gaia issue?

interface nsIDOMMozMmsMessage : nsISupports
{
  ...
  readonly attribute DOMString subject;
  ...
};

If you're hoping to display the subject (of the last message) in the thread list as well (bug 885679), then there's something to do with the Gecko end.

Comment 4

[Wilfred Mathanaraj [:WDM]]

this is picked up as a "nice to have" in the product backlog for v1.2.

Comment 5

[Rick Waldron [:rwaldron]]

(Copying notes from bug 894265)

Relevant notes:

- MMS Messages already include a "subject" property (currently unused)
- SMS Messages do not include a "subject" property (SMS doesn't have subject)
- MessageManager.sendMMS will need a refactor to accept a "subject" parameter (or an options object)
- MessageManager.sendMMS currently sends an explicit empty string as a "subject".

From a program perspective, I believe adding support for "subject" will be trivial. From UI/UX perspective, it's hard to say. I've put together a set of screen caps showing how iOS deals with (sending) messages that have a subject: https://www.dropbox.com/sh/8vsbel95k0i11re/DQGzPZ6Z2a

Comment 7

[Rick Waldron [:rwaldron]]

Attachment: Add subject field.pdf

Comment 9

[Yusuke Yamamoto]

Hi Rick,
Thanks added to attach our detail pdf ;)

'n we're considering it's useful for users :
 - If message has "subject", Messenger automatically send MMS.
 - If message has NO "subject",  Messenger automatically send SMS.
 - If message's size is larger than 140 bytes, Messenger automatically send MMS or Concatenates SMS( it depends on mobile carrier )   
 - If message's size is smaller than 140 bytes, Messanger automatically send SMS.

Comment 10

[Wilfred Mathanaraj [:WDM]]

I would go by:

1. if there is an attachment and/or subject choose MMS
2. if it does not have an attachment and/or subject choose SMS

I am not a fan of changing it based on message size as not many users will be able to understand why suddenly something changed from SMS to MMS (if case they type that big messages)

Comment 11

[Borja Salguero [:borjasalguero]]

Hi Yusuke,
Here we have to wait until getting feedback from UX Team. As this is a 'nice to have' thing, UX team is focused in v1.2 blockers, but they will come here soon!
Im going to add a 'needinfo' to Ayman, who is the owner of this.

Comment 12

[ayman maat :maat]

(In reply to Yusuke Yamamoto from comment #9)
> Hi Rick,
> Thanks added to attach our detail pdf ;)
> 
> 'n we're considering it's useful for users :
>  - If message has "subject", Messenger automatically send MMS.
>  - If message has NO "subject",  Messenger automatically send SMS.
>  - If message's size is larger than 140 bytes, Messenger automatically send
> MMS or Concatenates SMS( it depends on mobile carrier )   
>  - If message's size is smaller than 140 bytes, Messanger automatically send
> SMS.

There are rules already clearly defined rule in V1.1 for conversion from SMS to MMS and back again. You need to take those into account.

I will look at this from a UX perspective (when i have bandwith in between v1.2 priorities) as the proposed solution on comment 7 is both suboptimal in terms of layout and also discards key information that is a requirement to display... and therefore is not viable.

Comment 13

[Yusuke Yamamoto]

(In reply to ayman maat :maat from comment #12)
> There are rules already clearly defined rule in V1.1 for conversion from SMS
> to MMS and back again. You need to take those into account.
Oh, sorry about that...
I'm going to read detail of V1.1 spec to contribute to you.

So, I think , SMS-MMS spec is below link.
https://mozilla.app.box.com/applications/1/864518456
Is it correct?

Comment 15

[at-kitamura]

Attachment: Messages Subject(It is like the iPhone).pdf

Because it was a little unpopular, about correspondence of MMS Subject, the contents of "Add subject field.pdf". 

I made UX specifications like iPhone and attached screen capture "Messages Subject(It is like the iPhone).pdf" when I implemented it by a trial.

Please confirm it and someone follow me.

Comment 16

[Julien Wajsberg [:julienw]]

Comment on attachment 805799 [details]
Messages Subject(It is like the iPhone).pdf

Ayman, this looks like what we discussed during the workweek. Maybe you can give some guidance ?

Comment 17

[ayman maat :maat]

(In reply to a.kitamura from comment #15)
> Created attachment 805799 [details]
> Messages Subject(It is like the iPhone).pdf
> 
> Because it was a little unpopular, about correspondence of MMS Subject, the
> contents of "Add subject field.pdf". 
> 
> I made UX specifications like iPhone and attached screen capture "Messages
> Subject(It is like the iPhone).pdf" when I implemented it by a trial.
> 
> Please confirm it and someone follow me.

Hi. Let me be absolutely clear that, though your input and feedback is more than welcome, I am driving the UX for the messaging app and overseeing the UX for all the comms apps. Please send all suggestions to me personally over email. Posting specifications that have not been validated 1) duplicates work (We are currently producing the specification for the inclusion of Subject) 2) causes confusion for the developers as follow the wrong specifications. Both of these scenarios bring at the least inefficiency and at the worst risk to the performance and ultimately success of the project... so please be a team player and direct your suggestions to the person who is overseeing the UX for the area you wish to input into. Thanks.

Comment 18

[ayman maat :maat]

Comment on attachment 805799 [details]
Messages Subject(It is like the iPhone).pdf

**note to developers** 

do not follow these screen. they are both very much incomplete and conflict with other solutions that are being composed and proposed through the formal design track. 

It would be lovely if they could be removed.

The actual solution will be proposed in the forthcoming days.

Comment 19

[ayman maat :maat]

(In reply to Julien Wajsberg [:julienw] from comment #16)
> Comment on attachment 805799 [details]
> Messages Subject(It is like the iPhone).pdf
> 
> Ayman, this looks like what we discussed during the workweek. Maybe you can
> give some guidance ?

we cannot have subject permanently visible for two reasons: 
1) as it eats more real-estate which we do not have when the device is in landscape mode. 
2) due to end user cost implications we need to make MMS mode a clear action to enter into.. typing in a field that is permanently displayed is not a clear enough action as it invites the user to accidentally enter MMS and therefore incur higher charges.

Comment 20

[Julien Wajsberg [:julienw]]

Comment on attachment 805799 [details]
Messages Subject(It is like the iPhone).pdf

Dear a.kitamura, I'm going to make this proposal obsolete.

Thanks again for your contribution, it's always hard to contribute to UX because it needs to be consistent in the whole app.

We understand the subject handling is a much wanted feature and as Ayman has said we're commited to make it work soon :)

Once UX is frozen by Ayman, and we have some Visual Design, you could contribute to the code if you like !

Comment 21

[ayman maat :maat]

Attachment: FFOS_Subject_V1.3_20120920_V1.0.pdf

*RELEASE NOTE*

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Add and remove subject in a new message
- Send new message with subject
- Add and remove subject in a new message thread
- Send new message in a thread with subject

updated flows
- none

deleted flows
- none

--------------------

If you need clarification on the relationship between the subject field and the message field in the interaction model ping me.

Comment 22

[ayman maat :maat]

Attachment: FFOS_Subject_V1.3_20120920_V1.0.pdf

(oops, correct document attached this time)

*RELEASE NOTE*

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Add and remove subject in a new message
- Send new message with subject
- Add and remove subject in a new message thread
- Send new message in a thread with subject

updated flows
- none

deleted flows
- none

--------------------

If you need clarification on the relationship between the subject field and the message field in the interaction model ping me.

Comment 23

[Julien Wajsberg [:julienw]]

Ayman, one remark: the max message length is not absolute as you define in the wireframes, but it depends on the message encoding.

These wireframes are clear to me but this handle only the composing, we'll need UX for the display of subject too.

I think these 2 cases should be separated in 2 bugs though. I'll create a new one for handling how we display a received message with a subject.

Comment 24

[Julien Wajsberg [:julienw]]

Now this bug is for composing, the gecko change is for bug 920164 instead.

Comment 25

[Julien Wajsberg [:julienw]]

I suppose we need a Visual Design now.

Comment 26

[Victoria Gerchinhoren [:vicky]]

Thanks Julien, but not yet as the WF are not final, after a final version is out i will provide Visual Design for this feature. Not clearing needinfo as i will get back to this bug.

Comment 27

[ayman maat :maat]

Attachment: FFOS_MessageSubject_V1.3_20121007_V2.0.pdf

*RELEASE NOTE*

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Subject : New message, send message
- Subject : Message thread, send message
- Subject : New message, add and remove subject
- Subject : Message thread, add and remove subject

updated flows
- none

deleted flows
- New message : Save as draft from within app
- New message : Save as draft from outside of app

Comment 28

[Victoria Gerchinhoren [:vicky]]

Publishing visuals and layout specs. Please note that the icons are place holders and definitive ones will be posted here once they are final.

Comment 29

[Victoria Gerchinhoren [:vicky]]

Attachment: Compose Subject Idle state

Comment 30

[Victoria Gerchinhoren [:vicky]]

Attachment: Compose Subject subject field inactive

Comment 31

[Victoria Gerchinhoren [:vicky]]

Attachment: Compose Subject subject field active

Comment 32

[Victoria Gerchinhoren [:vicky]]

Attachment: Message subject spec

Comment 33

[ayman maat :maat]

Attachment: FFOS_MessageSubject_V1.3_20121009_V3.0.pdf

**RELEASE NOTE**

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Subject : Add subject when message thread is extended

updated flows
Subject : New message, send message
- affordance of message input field and subject field enhanced

Subject : Message thread, send message
- affordance of message input field and subject field enhanced

Subject : New message, add and remove subject
- affordance of message input field and subject field enhanced
- annotation on screen 3 altered

Subject : Message thread, add and remove subject
- affordance of message input field and subject field enhanced
- annotation on screen 3 altered

deleted flows
- none

Comment 34

[ayman maat :maat]

Attachment: FFOS_MessageSubject_V1.3_20121009_V4.0.pdf

**RELEASE NOTE**

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- none

updated flows

Subject : New message, add and remove subject
- mms mode supressed until content is added to subject field

Subject : Message thread, add and remove subject
- mms mode supressed until content is added to subject field

deleted flows
- none

Comment 35

[David Scravaglieri [:scravag]]

Blocking as it is a feature request.

Comment 36

[David Scravaglieri [:scravag]]

blocking per comment 35

Comment 37

[Victoria Gerchinhoren [:vicky]]

Need info to Peter La to provide the final menu icon for the header.

Comment 38

[Evelyn Eastmond [:evhan55]]

Hi Fernando.

rwaldron wanted me to find 1.3 feature bugs to work on and I was wondering if I could take this to work on.

Thanks!
Evelyn

Comment 39

[Peter La]

Attachment: Menu Action Icons @1x and 1.5x Resolutions

Hi,

Attached is the icon for the menu @1x and 1.5x sizes.  Until things get reworked in 1.3 and onwards, e've decided that it is best to stick to a consistent metaphor in this case rather than create a new one.

Comment 40

[Peter La]

Comment on attachment 820533 [details]
Menu Action Icons @1x and 1.5x Resolutions

Apologies.  In my haste, I mistook this for a 1.2 item, and thus this icon is not what we intend.  We are in the process of updating the menu icon for 1.3.  Will post it as soon as we have a final design (soon).

Comment 41

[Fernando Campo (:fcampo)]

Hi Evelyn, 

thanks a lot for the offering, but there's some work already going on around this bug and a PR on the waiting (couple of blockers to be solved), so if it's ok with you, I'd rather to keep it :)

In case you can't find any other 1.3 suitable, let me know (better to free it than block it)

Comment 42

[Evelyn Eastmond [:evhan55]]

(In reply to Fernando Campo (:fcampo) from comment #41)
> Hi Evelyn, 
> 
> thanks a lot for the offering, but there's some work already going on around
> this bug and a PR on the waiting (couple of blockers to be solved), so if
> it's ok with you, I'd rather to keep it :)
> 
> In case you can't find any other 1.3 suitable, let me know (better to free
> it than block it)

Sounds good, Fernando!
Will do.

Comment 43

[Rick Waldron [:rwaldron]]

(In reply to Fernando Campo (:fcampo) from comment #41)
> Hi Evelyn, 
> 
> thanks a lot for the offering, but there's some work already going on around
> this bug and a PR on the waiting (couple of blockers to be solved), so if
> it's ok with you, I'd rather to keep it :)
> 
> In case you can't find any other 1.3 suitable, let me know (better to free
> it than block it)

The reason I asked Evelyn to request this is because she's working on the Subject display as well. The only PR I see is the one for creating the header button menu—is there something else that I've missed?

Comment 44

[Fernando Campo (:fcampo)]

(In reply to Rick Waldron [:rwaldron] from comment #43)
> The reason I asked Evelyn to request this is because she's working on the
> Subject display as well. The only PR I see is the one for creating the
> header button menu—is there something else that I've missed?

No, nothing missing, I never launched the PR, as I don't see the point of it until bug 923024 is solved, as that's the way we have to show/hide subject during compose.

Comment 45

[ayman maat :maat]

Attachment: FFOS_MessageApp_V1.3_20121025_V5.0.pdf

**Release Note**

new wireframes
- none

updated wireframes
- none

deleted wireframes
- none

new flows
- Forward Message : Message from thread
- Delivery / Read report : Setting reports from within phone settings
- Delivery / Read report : Setting reports from message app inbox
- Delivery / Read report : Setting reports from within new message
- Delivery / Read report : Setting reports from within message thread
- Delivery / Read report : View report from thread
- Delivery / Read report : View delivery report from notification
- Delivery / Read report : View read report from notification
- Message Module Interactions : Long press and MMS
- Message Module Interactions : Tap on email address and MMS
- Message Module Interactions : Tap on url and MMS
- Message Module Interactions : Tap on phone number and MMS
- Anonymous messages : Thread

updated flows
- none

deleted flows
- none

pages relevant to this bug: 5-10 however no updates have been made in this wireframe pack, just attaching the latest wireframe pack here

Comment 46

[Julien Wajsberg [:julienw]]

Hey Fernando, everything's moving smoothly ? :)

Comment 47

[Fernando Campo (:fcampo)]

Attachment: pre-patch v1

Sending first version with some comments on github

Comment 48

[Corey Frang [:gnarf]]

Comment on attachment 8336834 [details] [review]
pre-patch v1

I'm pretty sure we should leave compose.js mostly alone.  This is pretty invasive for adding a subject.  The subject should probably also not be a [contenteditable], but an <input maxlength=40>

Comment 49

[Fernando Campo (:fcampo)]

Comment on attachment 8336834 [details] [review]
pre-patch v1

Changed subject to textarea (we need multiline), and addressed some other comments. 
As gnarf is on PTO, could you take a look to the updated PR Rick?

I also would like to discuss about modifying Compose. IMO it should include Subject related stuff, as it is part of the MMS composition.

Again, this is not the final patch, so please ignore the debugging codes

Comment 50

[Rick Waldron [:rwaldron]]

Comment on attachment 8336834 [details] [review]
pre-patch v1

I've left some significant notes on the PR, please r? me when ready

Comment 51

[Julien Wajsberg [:julienw]]

(In reply to Fernando Campo (:fcampo) from comment #49)
> Comment on attachment 8336834 [details] [review]
> pre-patch v1
> 
> Changed subject to textarea (we need multiline), and addressed some other
> comments. 

Are you sure we need multiline ? Ayman is not here right now so I can't ask directly, I'm needinfo him then.

Comment 52

[Julien Wajsberg [:julienw]]

Just discussed with Ayman: yes we need multiline.
I was only considering the case of the user pressing enter (where there are other solutions) but not the case of wrapping the text.

Then Fernando it's probably easier to use a div[contenteditable] that will grow automatically rather than a textarea that you'll need to grow yourself on keypress.

Comment 53

[Julien Wajsberg [:julienw]]

Ayman, another question for you: assuming there are some recipients, when the user entered some text in the subject line, but no content in the message field, should the "send" button be enabled or disabled? (I'd say "disabled").

Comment 54

[Julien Wajsberg [:julienw]]

Ok, Ayman said 'enabled' in that case ;)

Comment 55

[Julien Wajsberg [:julienw]]

Comment on attachment 8336834 [details] [review]
pre-patch v1

I think the general feeling is good, except the subject markup/css itself. We need another way to do this than complex calculations and reflows. The current way was made before we had the final flex layout spec, and I'm sure we can convert at least some of it to the flex layout.

Let's move forward with our comments :)

Comment 56

[Fernando Campo (:fcampo)]

(In reply to Julien Wajsberg [:julienw] from comment #52)
> 
> Then Fernando it's probably easier to use a div[contenteditable] that will
> grow automatically rather than a textarea that you'll need to grow yourself
> on keypress.

That was my first approach, but as Corey pointed out on the review, the current code assumes that Compose will have only one [contenteditable] at a time, so apart from the changes that implies, we would have to calculate the height limit for both subject and message every time we have an input (if it change the number of lines) on any of the fields anyway.

Comment 57

[Fernando Campo (:fcampo)]

(In reply to Julien Wajsberg [:julienw] from comment #55)
> ...The current way was made before we had the final flex layout spec, and I'm sure
> we can convert at least some of it to the flex layout.
> 
I think that a transformation to flex layout would imply too many changes that shouldn't be treated in this bug (that focuses on only add a subject) (e.g. compose form and message container needs to be flex boxes), so maybe we can handle all at the same time in a followup better?

Comment 58

[Rick Waldron [:rwaldron]]

It seems strange to allow multiline input when all newline characters are removed anyway...

Comment 59

[Fernando Campo (:fcampo)]

(In reply to Rick Waldron [:rwaldron] from comment #58)
> It seems strange to allow multiline input when all newline characters are
> removed anyway...
It seems weird indeed, but this is because the subject length limit of 40 characters is bigger than the space that we have to show them (around 32 in one line I think), so a second line is permitted to avoid horizontal scrolling. The fact that we allow pressing the new line button is a problem with the keyboard, because afaik we don't have a layout without the enter key (and just disable the action when the user presses it would be disorienting to the user).

Comment 60

[Julien Wajsberg [:julienw]]

(In reply to Fernando Campo (:fcampo) from comment #56)
> (In reply to Julien Wajsberg [:julienw] from comment #52)
> > 
> > Then Fernando it's probably easier to use a div[contenteditable] that will
> > grow automatically rather than a textarea that you'll need to grow yourself
> > on keypress.
> 
> That was my first approach, but as Corey pointed out on the review, the
> current code assumes that Compose will have only one [contenteditable] at a
> time, so apart from the changes that implies, 

I'm not sure these changes would be that big, especially compared to the code we need to add because of this.

> We would have to calculate the
> height limit for both subject and message every time we have an input (if it
> change the number of lines) on any of the fields anyway.

Except you won't need to "set" a height as often since it will be handled by the engine, and therefore it will be more efficient.


(In reply to Fernando Campo (:fcampo) from comment #59)
> (In reply to Rick Waldron [:rwaldron] from comment #58)
> > It seems strange to allow multiline input when all newline characters are
> > removed anyway...
> It seems weird indeed, but this is because the subject length limit of 40
> characters is bigger than the space that we have to show them (around 32 in
> one line I think), so a second line is permitted to avoid horizontal
> scrolling. The fact that we allow pressing the new line button is a problem
> with the keyboard, because afaik we don't have a layout without the enter
> key (and just disable the action when the user presses it would be
> disorienting to the user).

Just FYI With Ayman we discussed of the following behavior: pressing enter would move to the next field. But we agreed about not doing this now (because we need a multiline input for the reason you outlined anyway).


About the full flex box change, I agree this could be done in a follow-up... But I was wondering if we could not do only some of it now. Maybe that's not possible...

Comment 61

[Corey Frang [:gnarf]]

(In reply to Fernando Campo (:fcampo) from comment #59)
> (In reply to Rick Waldron [:rwaldron] from comment #58)
> > It seems strange to allow multiline input when all newline characters are
> > removed anyway...
> It seems weird indeed, but this is because the subject length limit of 40
> characters is bigger than the space that we have to show them (around 32 in
> one line I think), so a second line is permitted to avoid horizontal
> scrolling. The fact that we allow pressing the new line button is a problem
> with the keyboard, because afaik we don't have a layout without the enter
> key (and just disable the action when the user presses it would be
> disorienting to the user).

Pressing enter while in the subject line could bring you to the content area... I.E. "tab"

Comment 62

[Julien Wajsberg [:julienw]]

Corey, see my previous comment :p

Comment 63

[Fernando Campo (:fcampo)]

Comment on attachment 8336834 [details] [review]
pre-patch v1

I addressed the comments and added some tests. There still an open discussion about using a [contenteditable] <div> or a <textarea>, flex layout and subject multiline, but guess we can handle it on the comments.

Comment 64

[Rick Waldron [:rwaldron]]

I'm unclear about the "[contenteditable] <div> or a <textarea>" discussion, using a contenteditable is really easy and resizing is free: http://jsfiddle.net/rwaldron/8ABu6/

Previously, when I suggested an input or textarea, I didn't realize there were multiline display cases to be considered.

Comment 65

[Fernando Campo (:fcampo)]

Updated the PR to address latest comments. 

Sorry for the pressure, but deadline is tomorrow (or subject will go to 1.4), so if you are busy I can change the review to Borja, as he have some free cycles.

Comment 66

[Julien Wajsberg [:julienw]]

I started looking at this again yesterday but since we already talked about the big things I think Borja could take the final steps. (and give me some free time ;) )

Comment 67

[Julien Wajsberg [:julienw]]

Comment on attachment 8336834 [details] [review]
pre-patch v1

Hey Borja,

could you help finishing this review?

Thanks!

Comment 68

[Borja Salguero [:borjasalguero]]

Ok! I'll take a look right now! :)

Comment 69

[Borja Salguero [:borjasalguero]]

Let's wait to Travis and merge!

Comment 70

[Julien Wajsberg [:julienw]]

I don't want to be a killjoy, but you need approval from Fabrice before merging.

Comment 71

[Fernando Campo (:fcampo)]

So let's ask for it in a humble way :D
Do we need any other flag or a ni is enough?

Comment 72

[Julien Wajsberg [:julienw]]

The best way is to raise an approval flag on the patch, and filling in the form, so that Fabrice can take the decision. eg: safety of the patch, was it well tested, user impact, etc.

Comment 73

[[:fabrice] Fabrice Desré]

(In reply to Julien Wajsberg [:julienw] from comment #72)
> The best way is to raise an approval flag on the patch, and filling in the
> form, so that Fabrice can take the decision. eg: safety of the patch, was it
> well tested, user impact, etc.

Yep. I would appreciate some rationale on why this needs to go in. How risky is this, do we have automated tests, smoketests?

Comment 74

[Fernando Campo (:fcampo)]

Comment on attachment 8336834 [details] [review]
pre-patch v1

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): MMS Subject user story commited for 1.3 (bug #919966)
[User impact] if declined: user won't be able to send MMS with a subject
[Testing completed]: added unit tests and checked both on desktop and device
[Risk to taking this patch] (and alternatives if risky): medium risk, as we are messing with message composing. alternative is not using a subject
[String changes made]: added necessary strings for warn user and errors (4 added)

Comment 75

[Fernando Campo (:fcampo)]

r+ approval+ and travis green. Can anyone merge it? Apparently I don't have rights to do so.

Comment 76

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

landed in gaia
https://github.com/fcampo/gaia/commit/ee3fe8c84cd5edfc2061510409039b7858620051

Comment 77

[Joe Cheng [:jcheng] (please needinfo)]

is this uplifted to v1.3?
cannot find the  status-b2g-v1.2 flag yet so therefore ni?
thanks

Comment 78

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

Seems these files change have been already on v1.3 branch, so no need to uplift any more.