863267 - [CE Certification] Volume warning toast

Status: RESOLVED DUPLICATE of bug 855792

(Firefox OS Graveyard :: Gaia, defect)

Description

[Leo]

[CE Certification]
The device shall have achieved CE Certification :
Pop-up window of warning & volume control shall be appeared in case that sound pressure exceeds 85 dBA and output exceeds 27mV with ear-mic plugged in.

Case 1: When user control a media volume over 85db
* Should be displayed warning toast like this "If you listen at high volume levels for long periods, hearing damage can occur."
* when control a media volume using SUK and other ways

Case 2: The previous media vol status is over 85db and when user repluged ear-mic
* Should be displayed warning toast like this "Media volume automatically turned down to protect your ears."
* If there is no running Media apps, do not display warning toast.
* If any media apps are running, should be displayed warning toast.

Comment 1

[(inactive after 6/18) Alive Kuo [:alive]]

Per discussion this is possible to do but we need product team input on this to determine if we'd accept this new feature request and then we could start to get UX involved in.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Let's get product team's attention then :)

Comment 3

[Peter Dolanjski [:pdol]]

leo team, is this a certification requirement for the launch countries, specifically?

Comment 4

[Leo]

yes, To launch Spain TLF, we should get CE certification.

Comment 5

[Peter Dolanjski [:pdol]]

Leo team, would your team be able to contribute a fix for this (that is not hardware dependent)?

Stephany Wilkes from Mozilla's UX team would be able to support you as required.

Comment 6

[Stephany Wilkes]

For UX, these are our outstanding questions:

1) Will the text in Cases 1 and 2 above satisfy the legal requirement in all markets? Or should UX suggest strings and run them by Leo? We've asked for the legal requirement so we can ensure we meet it, but if Leo's strings cover it we're good.

2) Can the toasts be show-and-user-dismiss, or does the user need to be able to click the toast and be taken somewhere to do something (i.e. to enter the volume controls from the toast)? The first couple sentences of the bug imply that a volume control is expected to be part of the toast.

Please let us know. Thanks!

Comment 7

[Leo]

(In reply to Stephany Wilkes from comment #6)
> For UX, these are our outstanding questions:
> 
> 1) Will the text in Cases 1 and 2 above satisfy the legal requirement in all
> markets? Or should UX suggest strings and run them by Leo? We've asked for
> the legal requirement so we can ensure we meet it, but if Leo's strings
> cover it we're good.
> 
> 2) Can the toasts be show-and-user-dismiss, or does the user need to be able
> to click the toast and be taken somewhere to do something (i.e. to enter the
> volume controls from the toast)? The first couple sentences of the bug imply
> that a volume control is expected to be part of the toast.
> 
> Please let us know. Thanks!

Hi Stephany,

1) We just know that the texts in Cases 1 and 2 satisfy the legal requirement in Europe, and I'm not sure about other countries/markets. It would be good if you can ensure on your side as well.

2) It would be the best if the toasts popup and disappear itself after a few seconds without user interaction (so there's no button). And it doesn't take user to anywhere. I think, the 'volume control' in the first couple sentences mean the volume indicator at the top of the screen when you press volume up/down button. (Let me double check.) So, what we want to add is just a popup with text only.

Comment 8

[Stephany Wilkes]

Thanks for the additional information. 

To #1 above, do you know how many countries/markets this will be launching in initially? And is that the same as the number of countries/markets that need to see this toast? This is probably more a question for development, around how the toast behaves, but it will be good for us to know for 110n purposes, etc.

#2 seems clear for now. We'll do a wireframe based on that. Thanks!

Comment 9

[Leo]

Attachment: Suggestion

Hi Stephany,

I've been implementing the feature and I'd like to confirm with you that this is acceptable. Would you take a look at this video and give a feedback?

The current volume indicator expands to display the warning message when the volume is greater than 10.

Thanks!

p.s. I am checking on our side about your last comment now.

Comment 10

[Leo]

The below #2 message implies that the volume was AUTOMATICALLY TURNED DOWN. I'm checking on our side if we really need to TURN DOWN the volume AUTOMATICALLY (Currently there is no such thing in Firefox OS.), or if we can just use the #1 message instead in this case as well and do not alter the volume.

"Media volume automatically turned down to protect your ears."

Comment 11

[Stephany Wilkes]

It now seems as if our UX should just match the implementation shown here, or rather, that we should review what has been created and provide feedback and any suggested changes. Is that correct? Really just trying to figure out exactly what our team's work is here so we can wrap this up.

Comment 12

[Leo]

(In reply to Stephany Wilkes from comment #11)
> It now seems as if our UX should just match the implementation shown here,
> or rather, that we should review what has been created and provide feedback
> and any suggested changes. Is that correct? Really just trying to figure out
> exactly what our team's work is here so we can wrap this up.

Hi Stephany, 

There was no guideline given to me. I can follow your process. I can change or create a whole new implementation as per your feedback. Let me know how you want to proceed. Thanks!

Comment 13

[Stephany Wilkes]

Let's do this:
* UX will review the video;
* We'll provide some feedback and any new UX that might accompany that (which we'll share with product and engineering at both Mozilla and Leo should agree on);
* Implementation can follow whatever product and engineering decide based on UX feedback and the existing work.

Sound good? :)

Comment 14

[Stephany Wilkes]

Flagging Rob to review the video Leo provided and provide some UX direction, which may be followed (if necessary) by specs/wireframes from Tribe or similar.

Comment 15

[Leo]

(In reply to Stephany Wilkes from comment #13)
> Let's do this:
> * UX will review the video;
> * We'll provide some feedback and any new UX that might accompany that
> (which we'll share with product and engineering at both Mozilla and Leo
> should agree on);
> * Implementation can follow whatever product and engineering decide based on
> UX feedback and the existing work.
> 
> Sound good? :)

Sure, sounds good. Hopefully it won't take too long. :)

Comment 16

[Leo]

(In reply to Stephany Wilkes from comment #8)
> Thanks for the additional information. 
> 
> To #1 above, do you know how many countries/markets this will be launching
> in initially? And is that the same as the number of countries/markets that
> need to see this toast? This is probably more a question for development,
> around how the toast behaves, but it will be good for us to know for 110n
> purposes, etc.
> 
> #2 seems clear for now. We'll do a wireframe based on that. Thanks!

1.
The region that need to see this toast is Europe (not sure about countries/markets) and also certain telecom companies require them as well.

2.
And about AUTOMATICALLY altering the volume when earphone is plugged in, our UX team says it's not MUST, but recommended. Let us know what you think.

3.
Additional info. 
The warning message should be displayed regardless of how the volume is changed. 
i.e. Volume up/down key or Settings->Sound

Comment 17

[Leo]

(In reply to Stephany Wilkes from comment #8)
> Thanks for the additional information. 
> 
> To #1 above, do you know how many countries/markets this will be launching
> in initially?

And about where this will be launching initially.  Sorry I don't have information on that..

Comment 18

[Stephany Wilkes]

Flagging Rob per my comments 13 and 14. Sorry Rob - it's you or Francis. :(

Comment 20

[Rob MacDonald [:robmac]]

I had a some concerns with the current implementation as shown in this video and did some searches on the EU standard. In a BBC article explaining the regulation (dated Feb 2013), all personal music players are expected to not exceed a sound limit of 85dB. The user, however, can choose to override this limit up to a maximum 100dB. If the user overrides this limit, a warning about the risk must be repeated every 20 hours of listening time.

While I'm not an expert in the standard... What this suggests to me is, first, we cannot exceed 85dB without the user acknowledging a prompt. And, two, there's no need to constantly be warning the user if they choose to surpass the 85dB limit, which would be a major annoyance to most users.

So this is what I propose. First, a dialog would appear if the user attempts to exceed the default limit of 85dB (How that's defined, I'm not sure). The dialog should display the current text plus an "OK" button. Once the user acknowledges the dialog, they can then continue to increase the volume up to the maximum limit defined in the standard.

After 20 hours of playback, I'm hoping we can use the temporary notification as shown in the video attached to this bug. However, it needs to be displayed long enough for it to be read, which is likely in the 5-10 second range as opposed to the 2-3 seconds it's displayed now.

Like I said, though, I'd like to review a copy of the standard before finalizing this. Can someone please send me a link to this?

Comment 21

[Rob MacDonald [:robmac]]

Comment on attachment 742878 [details]
Suggestion

From my understanding of the EU standard, I don't believe this meets the requirement. Please see comment 20 and flag me if there are any additional questions. Thanks!

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Rob MacDonald [:robmac] from comment #20)
> After 20 hours of playback, I'm hoping we can use the temporary notification
> as shown in the video attached to this bug. However, it needs to be
> displayed long enough for it to be read, which is likely in the 5-10 second
> range as opposed to the 2-3 seconds it's displayed now.
> 

I really don't think people would listend to the music for 20 hours as well as they stare at the screen for 20 hours. 

The thing happened in the video isn't a notification but some modification to current volume overlay I think. That is to say, if the user isn't staring at the screen he will miss this.

Comment 23

[Stephany Wilkes]

Thanks, Rob. Flagging Peter as needinfo to see if we can get a reference to the standard we're designing this for. 

If anyone else has it, please feel free to add or link to it here and clear the needinfo for Peter.

Comment 24

[Rob MacDonald [:robmac]]

(In reply to Alive Kuo [:alive] from comment #22)
> (In reply to Rob MacDonald [:robmac] from comment #20)
> > After 20 hours of playback, I'm hoping we can use the temporary notification
> > as shown in the video attached to this bug. However, it needs to be
> > displayed long enough for it to be read, which is likely in the 5-10 second
> > range as opposed to the 2-3 seconds it's displayed now.
> > 
> 
> I really don't think people would listend to the music for 20 hours as well
> as they stare at the screen for 20 hours. 
> 
> The thing happened in the video isn't a notification but some modification
> to current volume overlay I think. That is to say, if the user isn't staring
> at the screen he will miss this.

Hi Alive... I don't think the intent there is purely for 20 continuous hours of listening, this is instead an aggregate that would need to be tracked across usage sessions. So if a user listens to their headphones at work for 10 hours, the warning would pop up every couple of days.

Also, although we need to review the standard, in the boards discussing this feature for other products, the main complaint is having to dismiss this warning every couple of days (for frequent users) so the proposal to use a notification instead of a prompt that the user must acknowledge is to avoid this problem. But, again, that would depend on the standard.

Comment 25

[Leo]

(In reply to Rob MacDonald [:robmac] from comment #20)
> So this is what I propose. First, a dialog would appear if the user attempts
> to exceed the default limit of 85dB (How that's defined, I'm not sure). The
> dialog should display the current text plus an "OK" button. Once the user
> acknowledges the dialog, they can then continue to increase the volume up to
> the maximum limit defined in the standard.

Hi Rob, I have one question about "how long" the acknowledgement is valid for. 
Is it valid for a life time of the current playback? or battery? or system until factory-reset/upgrade?

For example, 
1. Start listening with headphone with over the 85dB limit.
2. Show the OK/Cancel dialog.
3. If OK is selected, continue listening with increased volume for 20 hours.
4. Show the warning message.
5. Stop listening with headphone for 1 minute.
6. Start listening again with headphone with over the 85dB limit.
7. "Should we repeat from 2 above? or from 4 after 20 hours of listening?"

Also, what if Cancel is selected in 3 and user tries to increase volume soon again? Should we repeat from 2?

Comment 26

[Leo]

(In reply to Alive Kuo [:alive] from comment #22)
> I really don't think people would listend to the music for 20 hours as well
> as they stare at the screen for 20 hours. 
> 
> The thing happened in the video isn't a notification but some modification
> to current volume overlay I think. That is to say, if the user isn't staring
> at the screen he will miss this.

Hi Alive, 

Surprisingly, I was just told that Android JB+ has the warning message implemented for the 20 hours. My thought about user staring at the screen for 20 hours is.. that we just do what we have to do regardless of user looking at the screen or not.. Or to improve that, we can add a "ding" sound if screen is off.

Right, I modified the current volume overlay to show the warning message. The reason is I neither want to show a full-screen dialog to annoy user, nor I want to add two different notifications (current volume overlay + warning message) separately at the same time. (If the current volume overlay is considered as a notification, which I think is true.)

Comment 27

[Leo]

(In reply to Leo from comment #16)
> 2.
> And about AUTOMATICALLY altering the volume when earphone is plugged in, our
> UX team says it's not MUST, but recommended. Let us know what you think.

I have new info to my previous comment.

I'm not saying we should do whatever Android does but just for reference, I was told that Android alter the volume to the 85dB limit without any notification in the following case.

1. User is listening to media with over 85dB limit in speaker mode.
2. User plugs in earphone.
3. The volume is automatically altered to 85dB with no notification.

We also need to decide what we want to do in 3 as well.

Comment 28

[Leo]

(In reply to Alive Kuo [:alive])
> See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=855792

Why not we close one as dup, either this bug or 855792? They seem the same now with the 20 hours thing.

Comment 29

[Leo]

(In reply to Stephany Wilkes from comment #23)
> Thanks, Rob. Flagging Peter as needinfo to see if we can get a reference to
> the standard we're designing this for. 
> 
> If anyone else has it, please feel free to add or link to it here and clear
> the needinfo for Peter.

Is this what you are looking for?
https://bug855792.bugzilla.mozilla.org/attachment.cgi?id=742686

Please clear the needinfo if this is the right one.

Comment 30

[Leo]

(In reply to Stephany Wilkes from comment #23)
> Thanks, Rob. Flagging Peter as needinfo to see if we can get a reference to
> the standard we're designing this for. 
> 
> If anyone else has it, please feel free to add or link to it here and clear
> the needinfo for Peter.

And this comment directs you to the exact part.
https://bugzilla.mozilla.org/show_bug.cgi?id=855792#c16

p.s. I really think those two bugs are the same, dup.

Comment 31

[Stephany Wilkes]

Thanks! I agree: The documentation looks correct and these look like duplicates to me. 

The question is: What needs to happen to successfully wrap up UX on this, and in which bug should that go?

Comment 32

[Leo]

(In reply to Stephany Wilkes from comment #31)
> Thanks! I agree: The documentation looks correct and these look like
> duplicates to me. 
> 
> The question is: What needs to happen to successfully wrap up UX on this,
> and in which bug should that go?

Who needs to answer the question?

Comment 33

[Stephany Wilkes]

We have provided a UX recommendation (per comment) and have reviewed the legal requirement. Are assets needed here (i.e. the actual notification)? Flagging Chris Lee, in addition to Peter, to see if he can shed any light on the remaining Leo requirement here.

Comment 34

[Kai-Chih Hu [:khu]]

It looks like this bug should be marked as tef+.

Comment 35

[David Palomino [:dpalomino]]

Hi, 

CE certificate is a mandatory requirement for all European countries and carriers (legal requirement). 

My doubt is if the device is able to exceed 85dBs. If the device would not be able to exceed that limit, I understand that it'd be not needed to implement this. 

Vendor colleagues, could you please confirm if your device can excceed 85dB in audio?

Thanks!
David

Comment 36

[Kai-Chih Hu [:khu]]

Hi, Alive, you may know the related codes well here. May we get your professional confirmation here: is there any codes related to hardware if the solution needs to be provided?

Comment 37

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to khu from comment #36)
> Hi, Alive, you may know the related codes well here. May we get your
> professional confirmation here: is there any codes related to hardware if
> the solution needs to be provided?

We could provide a customizable settings(config at build time) for the OEM vendor to specify the value of volume warning threshold of their device. We won't know the audio output power of the device but the OEM vender should know from acoustic estimating.

For Mozilla implementation, we could set a default value to the threshold but OEM needs to change the value after real device estimation.

This is my proposal, but it seems nobody could come to the same solution here.

Comment 38

[Kai-Chih Hu [:khu]]

Thanks, Alive. 

I think your proposal should work. Any other voices here? Thanks.

Comment 39

[Juan Perez-Bedmar [:juanpbf]]

(In reply to khu from comment #38)
> Thanks, Alive. 
> 
> I think your proposal should work. Any other voices here? Thanks.

Thanks Alive and Kevin for your comments.
Dear colleagues ([e-mail]), please make comments here, and let us all know if this is OK for us

Comment 40

[Rob MacDonald [:robmac]]

Attachment: Proposed volume warning flows from UX

Based on my review of the CENELEC standard, this document summarizes my understanding of the requirement along with key flows. (This document is in the process of being reviewed by visual design.) I'd appreciate if someone more familiar with the standard could review the document to confirm.

Please post any comments / questions / concerns. I look forward to your comments!

Comment 41

[Rob MacDonald [:robmac]]

(In reply to Leo from comment #27)
> (In reply to Leo from comment #16)
> > 2.
> > And about AUTOMATICALLY altering the volume when earphone is plugged in, our
> > UX team says it's not MUST, but recommended. Let us know what you think.
> 
> I have new info to my previous comment.
> 
> I'm not saying we should do whatever Android does but just for reference, I
> was told that Android alter the volume to the 85dB limit without any
> notification in the following case.
> 
> 1. User is listening to media with over 85dB limit in speaker mode.
> 2. User plugs in earphone.
> 3. The volume is automatically altered to 85dB with no notification.
> 
> We also need to decide what we want to do in 3 as well.

Thanks! That's the correct behaviour based on my understanding of the standard. I've included this in the draft spec.

Comment 42

[Rob MacDonald [:robmac]]

(In reply to Leo from comment #29)
> 
> Is this what you are looking for?
> https://bug855792.bugzilla.mozilla.org/attachment.cgi?id=742686
> 
> Please clear the needinfo if this is the right one.

Yes. Thanks!

Comment 43

[Rob MacDonald [:robmac]]

(In reply to Leo from comment #27)
> (In reply to Leo from comment #16)
> > 2.
> > And about AUTOMATICALLY altering the volume when earphone is plugged in, our
> > UX team says it's not MUST, but recommended. Let us know what you think.
> 
> I have new info to my previous comment.
> 
> I'm not saying we should do whatever Android does but just for reference, I
> was told that Android alter the volume to the 85dB limit without any
> notification in the following case.
> 
> 1. User is listening to media with over 85dB limit in speaker mode.
> 2. User plugs in earphone.
> 3. The volume is automatically altered to 85dB with no notification.
> 
> We also need to decide what we want to do in 3 as well.

Based on my read of the CENELEC standard, this is the correct behaviour. I have included this in my spec and no notification is displayed in these cases. This applies if the audio/video player is closed and re-started or when the headset is plugged in during playback.

Comment 44

[Leo]

(In reply to Rob MacDonald [:robmac] from comment #40)
> Created attachment 746132 [details]
> Proposed volume warning flows from UX
>
> Please post any comments / questions / concerns. I look forward to your
> comments!

Hi Rob, 

Thanks for the attachment and I will start implementing according to that. 

Because I'm still not familiar with your process, I have a question about the Icon and the string in the the acknowledging prompt. Are the icon and the string translation going to be provided by your side?

Comment 45

[Rob MacDonald [:robmac]]

(In reply to Leo from comment #44)

> Hi Rob, 
> 
> Thanks for the attachment and I will start implementing according to that. 
> 
> Because I'm still not familiar with your process, I have a question about
> the Icon and the string in the the acknowledging prompt. Are the icon and
> the string translation going to be provided by your side?

Good point, Leo. I'm flagging Stas for late localization and Patryk and Przemek for the icon. Leo, let me know if you have any questions. Patryk, Przemek, I'll follow up with you over email.

Comment 46

[(inactive after 6/18) Alive Kuo [:alive]]

We have a timeframe pressure, so my propose to make bug 855792 stay tef+ and this keeps leo+. We plan to provide a baseline version of implementation in bug 855792 at first.

Comment 47

[David Palomino [:dpalomino]]

Dear Tang Juan, 

Please, confirm here if: 
- Device is able to exceed 85dB (as previously commented by email)
- You agree with the proposed solution

Thanks, 
David

Comment 48

[TangJuan]

Please, confirm here if: 
- Device is able to exceed 85dB (as previously commented by email)
- You agree with the proposed solution

Tangjuan:
-Yes. I'm sure the device is able to exceed 85 dB. We have already tested it.
-Also from my email. The value of the volume will be provided by ZTE. But only the value. Could you help to implement this reqiurement? We will provide the value. If you worried the other OEM, you can also give us the patch.

Comment 49

[Patryk Adamczyk [:patryk] UX]

Peter La will deliver the icon.

Comment 50

[bhavana bajaj [:bajaj]]

Adding back leo+ as that was the state prior to comment #34.

Comment 51

[Jason Smith [:jsmith]]

Did you mean to leo+ the bug here per comment 50?

Comment 52

[bhavana bajaj [:bajaj]]

(In reply to Jason Smith [:jsmith] from comment #51)
> Did you mean to leo+ the bug here per comment 50?

whoops, indeed!

Comment 53

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

Attachment: pull request: https://github.com/mozilla-b2g/gaia/pull/9636

Comment 54

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

Attachment: ce_warningdialog.png

Because this is an urgency issues,
we have no time to implement warning dialog.

we use 'CustomDialog' first, but there are two button in this dialog, 
as the attachment.

When user click 'continue' and 'close' will do same thing in this stage.
Feel free to talk with me if you any ideas.

Comment 55

[Beatriz Rodríguez [:brg]]

(In reply to GaryChen [:GaryChen] (MoCo-TW) from comment #54)
> Created attachment 747310 [details]
> ce_warningdialog.png
> 
> Because this is an urgency issues,
> we have no time to implement warning dialog.
> 
> we use 'CustomDialog' first, but there are two button in this dialog, 
> as the attachment.
> 
> When user click 'continue' and 'close' will do same thing in this stage.
> Feel free to talk with me if you any ideas.
Agree, we are in hurry right now.

Checking the behaviour of other platforms, that I think we can improve in the future: 
- Continue --> will allow user to increase the volumen
- Cancel --> if user tries to increase the volumen, the warning message will appear again and user must press continue to be allowed to increase the volumen.

Which is the behaviour that will be implemented now? Is it enough to get the CE?

Comment 56

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

(In reply to Beatriz Rodríguez [:brg] from comment #55)
> (In reply to GaryChen [:GaryChen] (MoCo-TW) from comment #54)
> > Created attachment 747310 [details]
> > ce_warningdialog.png
> > 
> > Because this is an urgency issues,
> > we have no time to implement warning dialog.
> > 
> > we use 'CustomDialog' first, but there are two button in this dialog, 
> > as the attachment.
> > 
> > When user click 'continue' and 'close' will do same thing in this stage.
> > Feel free to talk with me if you any ideas.
> Agree, we are in hurry right now.
> 
> Checking the behaviour of other platforms, that I think we can improve in
> the future: 
> - Continue --> will allow user to increase the volumen
> - Cancel --> if user tries to increase the volumen, the warning message will
> appear again and user must press continue to be allowed to increase the
> volumen.
> 
> Which is the behaviour that will be implemented now? Is it enough to get the
> CE?

Good for me.
I will change in next pr,  thanks for your feedback.

Comment 57

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 747308 [details]
pull request: https://github.com/mozilla-b2g/gaia/pull/9636

Hi, we're focusing on fixing tef+ bug 855792 there, :gchen should paste the patch to the wrong bug :)
And I am having some comments on github, :gchen is working on refining the patch now. Thanks leo.

Comment 58

[Marcia Knous [:marcia]]

I filed Bug 872736 to address the typo in the screen - will that be addressed in this bug?

Comment 59

[Lukas Blakk [:lsblakk] use ?needinfo]

(In reply to Alive Kuo [:alive] from comment #57)
> Comment on attachment 747308 [details]
> pull request: https://github.com/mozilla-b2g/gaia/pull/9636
> 
> Hi, we're focusing on fixing tef+ bug 855792 there, :gchen should paste the
> patch to the wrong bug :)
> And I am having some comments on github, :gchen is working on refining the
> patch now. Thanks leo.

Is this bug now fixed with the landing of bug 855792?

Comment 60

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to [e-mail] [:lsblakk] from comment #59)
> (In reply to Alive Kuo [:alive] from comment #57)
> > Comment on attachment 747308 [details]
> > pull request: https://github.com/mozilla-b2g/gaia/pull/9636
> > 
> > Hi, we're focusing on fixing tef+ bug 855792 there, :gchen should paste the
> > patch to the wrong bug :)
> > And I am having some comments on github, :gchen is working on refining the
> > patch now. Thanks leo.
> 
> Is this bug now fixed with the landing of bug 855792?

I think so, though its not entirely implemented to spec but the function is usable now.

Comment 62

[Alissa（leave from Mozilla）]

According to comment 61,delete keywords verifyme.