1050548 - Camera in-use indicator is too hard to see

Status: VERIFIED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Eric Rescorla (:ekr)]

Attachment: screenshot

The attached screenshot shows the current camera in-use indicator for 2.0.

Gray and non-flashing is just way too hard for people to see. In fact, I showed this to several people and they weren't even sure what the indicator was. Didn't this used to be red.

Comment 1

[Martin Thomson [:mt:]]

Do we remove colour from the docked indicators?

Comment 2

[Eric Rescorla (:ekr)]

Faramarz, this seems suboptimal. Where should I direct it

Comment 3

[Stephany Wilkes]

Flagging Amy on camera visuals.

Comment 4

[Amy Lee [:amylee] UX]

(In reply to Stephany Wilkes from comment #3)
> Flagging Amy on camera visuals.

Hi, 

I just tested this myself and it looks like the message is coming from the browser and not the camera app since the camera is being accessed from the browser.

Flagging David to confirm this.

Comment 5

[Eric Rescorla (:ekr)]

(In reply to Amy Lee [:amylee] from comment #4)
> (In reply to Stephany Wilkes from comment #3)
> > Flagging Amy on camera visuals.
> 
> Hi, 
> 
> I just tested this myself and it looks like the message is coming from the
> browser and not the camera app since the camera is being accessed from the
> browser.
> 
> Flagging David to confirm this.

Yes, this is the browser. Does that affect the analysis?

Comment 6

[Amy Lee [:amylee] UX]

(In reply to Eric Rescorla (:ekr) from comment #5)
> (In reply to Amy Lee [:amylee] from comment #4)
> > (In reply to Stephany Wilkes from comment #3)
> > > Flagging Amy on camera visuals.
> > 
> > Hi, 
> > 
> > I just tested this myself and it looks like the message is coming from the
> > browser and not the camera app since the camera is being accessed from the
> > browser.
> > 
> > Flagging David to confirm this.
> 
> Yes, this is the browser. Does that affect the analysis?

No, but flagging Eric since he's the visual designer on browser and would be the most familiar with it.

Comment 7

[Stephany Wilkes]

Yes, it very much affects this. Each app is different and this is the browser app and WebRTC, not the camera. 

I'll wait for David to comment on the message coming from browser in order to evaluate what, if any, design needs to be changed. The camera app is correct (there is a huge, bright red circle while recording, plus a red time counter ticking, etc.), so it does seem to be an issue of coming at this from the browser and/or the browser/WebRTC not using or incorporating some expected camera UI here.

Since this is WebRTC/Loop, it also means the design work was guided and done by Tef (the partner), whose design resources are no longer available due to subsequent changes in the partnership. 

Flagging Maria since she worked on this for a bit in the past, and may be able to point us to specs. I'm not sure whether it was specified that WebRTC should use some or all of the camera UI/indicators, etc. Also flagging Eric just in case he knows some of the background on this, in the absence of the partner.

Comment 8

[Eric Rescorla (:ekr)]

(In reply to Stephany Wilkes from comment #7)
> Yes, it very much affects this. Each app is different and this is the
> browser app and WebRTC, not the camera. 
> 
> I'll wait for David to comment on the message coming from browser in order
> to evaluate what, if any, design needs to be changed. The camera app is
> correct (there is a huge, bright red circle while recording, plus a red time
> counter ticking, etc.), so it does seem to be an issue of coming at this
> from the browser and/or the browser/WebRTC not using or incorporating some
> expected camera UI here.
> 
> Since this is WebRTC/Loop, it also means the design work was guided and done
> by Tef (the partner), whose design resources are no longer available due to
> subsequent changes in the partnership. 
> 
> Flagging Maria since she worked on this for a bit in the past, and may be
> able to point us to specs. I'm not sure whether it was specified that WebRTC
> should use some or all of the camera UI/indicators, etc. Also flagging Eric
> just in case he knows some of the background on this, in the absence of the
> partner.

Stephany,

My understanding is that this is actually not Loop UX but pure browser UX.
It used to be red in the browser but now it's not....

Comment 9

[Maria Sandberg [:mushi]]

Hi there. Unfortunately this wasn't part of the work I was involved in for Loop/WebRTC. Like others have said, Eric Pang might know.

Comment 10

[Eric Pang [:epang] UX]

(In reply to Maria Sandberg [:mushi] from comment #9)
> Hi there. Unfortunately this wasn't part of the work I was involved in for
> Loop/WebRTC. Like others have said, Eric Pang might know.

I wasn't invovled in loop/WebRTC, but I'm assuming that the same status bar icon is used for Video Recording and WebRTC?  Also, if being used the icon should be full opacity.

I removed colour from the status bar icons because of the transparent background on the home screen.  Also the default wallpaper is reds and oranges so this caused low visibility for any red icons.

Seeing as the icon will most likely be seen in the browser/camera (where the status bar is not transparent) I think we can make it red again.  I'll update the sprites and post to the bug.  Will anyone be able to swap out the graphics?

Comment 11

[Eric Pang [:epang] UX]

Attachment: Updated Sprites.zip

Updated sprites with Red camera in use icon

Comment 12

[David Flanagan [:djf]]

Amy,

The recording indicator is in the status bar, which is handled by the System app. Gecko and the system app work together to ensure that there is an indicator displayed whenever the camera or microphone are recording. 

This has nothing to do with the Camera app. In fact, since the camera app is full-screen, the status bar and the recording indicator are never actually visible to the user when they are using the Camera app.

Comment 13

[David Flanagan [:djf]]

Eric,

I'm not sure that adding the red color back is the right fix here. Now that we have a transparent status bar, I too had noticed the issue of the red indicator not being very visible on top of the default wallpaper. This recording indicator is important as a privacy feature so that the user knows if an app is spying on them. If the user is in the Camera app, they can't see the status bar. If they are using WebRTC in the browser, then they probably already know that recording is happening...

But if they go back to the homescreen and an app continues to record them, that is something unexpected that we really want to alert them too.

My point is that it is more important that the recording indicator be visible on the homescreen than that it be visible in apps that are obviously doing recording.  So if changing the icon back to red will make it hard to see on the homescreen, then I don't think this is a good fix.

On the other hand, color is very important for this particular icon. A red circle is kind of a universal indicator for video recording, and it works. But take the color away and the gray circle seems meaningless, as :ekr points out in comment #0.

Would it be possible to come up with a better icon than a gray circle? Actually, it might be necessary to have three icons: one to mean "camera in use", one to mean "microphone in use" and one to mean "both camera and microphone in use". We'd then also need system app changes (and maybe gecko changes?) to distinguish between camera and microphone.

Comment 14

[Eric Rescorla (:ekr)]

(In reply to David Flanagan [:djf] from comment #13)
> Eric,
> 
> I'm not sure that adding the red color back is the right fix here. Now that
> we have a transparent status bar, I too had noticed the issue of the red
> indicator not being very visible on top of the default wallpaper. 

I don't have a strong opinion about what the indicator is, but I do think
it needs to be super-visible and that the gray circle is not great,
so we need to fix it soon. Making it red seems like the easiest thing
to do fast.




> This
> recording indicator is important as a privacy feature so that the user knows
> if an app is spying on them. If the user is in the Camera app, they can't
> see the status bar. If they are using WebRTC in the browser, then they
> probably already know that recording is happening...
>

I don't think this assessment is accurate. There's no reason why a malicious
site can't ask for the camera and then pretend to give it up and keep
capturing. The indicator is intended to alert people to that.

> But if they go back to the homescreen and an app continues to record them,
> that is something unexpected that we really want to alert them too.
> 
> My point is that it is more important that the recording indicator be
> visible on the homescreen than that it be visible in apps that are obviously
> doing recording.  So if changing the icon back to red will make it hard to
> see on the homescreen, then I don't think this is a good fix.
> 
> On the other hand, color is very important for this particular icon. A red
> circle is kind of a universal indicator for video recording, and it works.
> But take the color away and the gray circle seems meaningless, as :ekr
> points out in comment #0.
> 
> Would it be possible to come up with a better icon than a gray circle?
> Actually, it might be necessary to have three icons: one to mean "camera in
> use", one to mean "microphone in use" and one to mean "both camera and
> microphone in use". We'd then also need system app changes (and maybe gecko
> changes?) to distinguish between camera and microphone.

Comment 15

[Mike Habicher [:mikeh] (high bugzilla latency)]

My $0.02: if we _really_ want to make it visible, make it blink.

Comment 16

[Stephany Wilkes]

We can make it blink with web components! <- Do not take this seriously. (But really, we can.)

Comment 17

[Eric Pang [:epang] UX]

(In reply to David Flanagan [:djf] from comment #13)
> Eric,
> 
> I'm not sure that adding the red color back is the right fix here. Now that
> we have a transparent status bar, I too had noticed the issue of the red
> indicator not being very visible on top of the default wallpaper. This
> recording indicator is important as a privacy feature so that the user knows
> if an app is spying on them. If the user is in the Camera app, they can't
> see the status bar. If they are using WebRTC in the browser, then they
> probably already know that recording is happening...
> 
> But if they go back to the homescreen and an app continues to record them,
> that is something unexpected that we really want to alert them too.
> 
> My point is that it is more important that the recording indicator be
> visible on the homescreen than that it be visible in apps that are obviously
> doing recording.  So if changing the icon back to red will make it hard to
> see on the homescreen, then I don't think this is a good fix.
> 
> On the other hand, color is very important for this particular icon. A red
> circle is kind of a universal indicator for video recording, and it works.
> But take the color away and the gray circle seems meaningless, as :ekr
> points out in comment #0.
> 
> Would it be possible to come up with a better icon than a gray circle?
> Actually, it might be necessary to have three icons: one to mean "camera in
> use", one to mean "microphone in use" and one to mean "both camera and
> microphone in use". We'd then also need system app changes (and maybe gecko
> changes?) to distinguish between camera and microphone.

Thanks for the feedback David!  I'll see if I can come up with 3 icons this week.  Going to keep need info on myself as a reminder.

Comment 18

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #17)
> (In reply to David Flanagan [:djf] from comment #13)
> > Eric,
> > 
> > I'm not sure that adding the red color back is the right fix here. Now that
> > we have a transparent status bar, I too had noticed the issue of the red
> > indicator not being very visible on top of the default wallpaper. This
> > recording indicator is important as a privacy feature so that the user knows
> > if an app is spying on them. If the user is in the Camera app, they can't
> > see the status bar. If they are using WebRTC in the browser, then they
> > probably already know that recording is happening...
> > 
> > But if they go back to the homescreen and an app continues to record them,
> > that is something unexpected that we really want to alert them too.
> > 
> > My point is that it is more important that the recording indicator be
> > visible on the homescreen than that it be visible in apps that are obviously
> > doing recording.  So if changing the icon back to red will make it hard to
> > see on the homescreen, then I don't think this is a good fix.
> > 
> > On the other hand, color is very important for this particular icon. A red
> > circle is kind of a universal indicator for video recording, and it works.
> > But take the color away and the gray circle seems meaningless, as :ekr
> > points out in comment #0.
> > 
> > Would it be possible to come up with a better icon than a gray circle?
> > Actually, it might be necessary to have three icons: one to mean "camera in
> > use", one to mean "microphone in use" and one to mean "both camera and
> > microphone in use". We'd then also need system app changes (and maybe gecko
> > changes?) to distinguish between camera and microphone.
> 
> Thanks for the feedback David!  I'll see if I can come up with 3 icons this
> week.  Going to keep need info on myself as a reminder.

Before moving forward with visuals I wanted to get Rob's take on using 3 individual icons.

The icons will inform the user of..

1. Camera in use
2. Mic in use
3. Camrera and mic in use

This would also align with the notification tray where we have 3 individual icons for the tray.

Also, Rob mentioned that Darrin was involved with camera as well so flagging need info on his as well for his opinion.

Comment 19

[Darrin Henein [:darrin]]

To be clear, I have been working on the Loop UX for desktop, and don't have any experience/context with the camera. Not sure I will be of much help here!

Comment 20

[Martin Thomson [:mt:]]

(In reply to Eric Pang [:epang] from comment #18)
> The icons will inform the user of..
> 
> 1. Camera in use
> 2. Mic in use
> 3. Camrera and mic in use

We also have screen sharing coming.  Do you really want the combination of all of these?

Comment 21

[jachen]

(In reply to Martin Thomson [:mt] from comment #20)
> (In reply to Eric Pang [:epang] from comment #18)
> > The icons will inform the user of..
> > 
> > 1. Camera in use
> > 2. Mic in use
> > 3. Camrera and mic in use
> 
> We also have screen sharing coming.  Do you really want the combination of
> all of these?

Martin brings up a valid point. Eric, can we simplify to communicate the underlying message this icon is trying to say, rather than having literal icons? Really what we want people to know is that something is being live recorded or shared. 

I agree with David F and Eric that using the red color for the icon is a risk in terms of visibility on the homescreen, which is exactly the context in which a user may not understand that something is still recording since they are not in the app or feature that is actually doing the recording.

What I don't know, is whether regardless of what icon we use whether people will understand what the source of the problem is and how to make it (i.e. the recording) stop. I'll ask Rob to follow up on this.

Comment 22

[Eric Rescorla (:ekr)]

Hi Guys,

This bug has been outstanding for a month now. I can understand that people are
concerned that the red dot may not be ideal, but it seems clear that it's
strictly better than the current gray dot. What say we revert this change
so that there's a red dot and then we can work on something better at
leisure.

Comment 23

[Rob MacDonald [:robmac]]

I'll do a quick sync with Eric, Amy and Jacqueline tomorrow to come up with a quick proposal, factoring the the comments and concerns listed in this bug.

Comment 24

[Rob MacDonald [:robmac]]

Quick update - we met today to discuss alternatives. Visual design is going to mock them up and we'll meet again in a couple of days to review.

Comment 25

[Eric Pang [:epang] UX]

Attachment: Updated Sprites.zip

I've updated the sprite with a the recording icon.  Michael, by any chance can you help us update the sprites? Thanks!

We decided to go with a general icon which covers the different scenarios, if more detail is needed the user can find this in the notifications tray.

Comment 26

[Michael Henretty [:mikehenrty][:mhenretty]]

Seems like you guys are rushing to get this in, but I don't see a blocking flag. What release are we targeting? 2.0 or 2.1? If it's 2.2, then rushing is not going to change the fact that we still are more than a month away from a proper train.

In the meantime I'll see about getting this in, but please answer the above question so we know how much we need to rush.

Comment 27

[Eric Rescorla (:ekr)]

Mike,

I'm not the decision maker here, but this seems like a fairly trivial technical
change that solves a fairly serious lack of notification, so I would favor pushing
it as far up the release chain as possible.

Comment 28

[Faramarz Rashed]

adding fabrice and bhavana to the thread so we can change the flag and get this trivial but important change in.

Comment 29

[bhavana bajaj [:bajaj]]

(In reply to Eric Rescorla (:ekr) from comment #27)
> Mike,
> 
> I'm not the decision maker here, but this seems like a fairly trivial
> technical
> change that solves a fairly serious lack of notification, so I would favor
> pushing
> it as far up the release chain as possible.

jfyi, 2.0 is too late to get this in at this point, the earliest we can take this is 2.1, that too, it will be a non-blocking approval uplift. I would not block ship a release for this change but it would be nice to fix this up :)

Comment 30

[Rob MacDonald [:robmac]]

I'm not sure if this impacts 2.0 as the reason for the change in the icon was to ensure contrast with the color matching status bar, which is new to 2.1. Flagging Eric and Michael to confirm.

Comment 31

[Rob MacDonald [:robmac]]

[Blocking Requested - why for this release]:

Nominating for 2.1. Why? When implementing status bar colour matching, the colors of status bar icons were modified to white or grey to improve contrast with the background. In the case of the recording indicator, the change of color made the meaning of the icon unclear. 

As a result, visual design has modified the icon to make it red and yet work with multiple colored backgrounds. Since this is a swap of an existing visual asset, we're hoping this is a simple, low risk fix that can be included in 2.1. 

This will ensure that users know when audio and or video recording is taking place.

- Rob

Comment 32

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Rob MacDonald [:robmac] from comment #30)
> I'm not sure if this impacts 2.0 as the reason for the change in the icon
> was to ensure contrast with the color matching status bar, which is new to
> 2.1. Flagging Eric and Michael to confirm.

From comment 0, it does look like :ekr was seeing this on 2.0. It's a moot point though, since :bajaj said in comment 29 that it's too late for 2.0 anyway. I'll submit a pull request, and request uplift to 2.1. I don't foresee any problems getting this in.

Comment 33

[Michael Henretty [:mikehenrty][:mhenretty]]

Removing blocking nom per comment 29. Not to worry though, we'll fix this for 2.1.

Comment 34

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [Gaia PR] new recording icons

Comment 35

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [screenshot] browser recording icon

Comment 36

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [screenshot] homescreen dark recording icon

Comment 37

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [screenshot] homescreen light recording icon

Comment 38

[Eric Pang [:epang] UX]

Attachment: Camera in use indicator.png

Hey Michael,

The screens look good but I loaded the patch to test out the interaction.
A few things don't seem to be right.

1. When the camera is active it looks like the disabled state is shown (instead of the full opacity one)
2. When the camera in use icon is shown the play icon also shows up (I don't think it should be there, I swear i wasn't playing music!)
3. Also, do you know what the purpose of the disabled state is?

Rob, when you get a chance can you give the patch a try?  It's possible that this is just a problem with my device.

Thanks!

Comment 39

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Eric Pang [:epang] from comment #38)
> Created attachment 8487859 [details]
> Camera in use indicator.png
> 
> Hey Michael,
> 
> The screens look good but I loaded the patch to test out the interaction.
> A few things don't seem to be right.
> 
> 1. When the camera is active it looks like the disabled state is shown
> (instead of the full opacity one)

This is the way it was before this bug too, I'm not sure why.

> 2. When the camera in use icon is shown the play icon also shows up (I don't
> think it should be there, I swear i wasn't playing music!)

This should have nothing to do with my patch. I only swapped out the image assets, no logic changed. That sounds like a new bug, please file if you can come up with STR.

> 3. Also, do you know what the purpose of the disabled state is?

Disabled state (which is the full opacity for some reason), indicates that the camera recently stopped recording I believe. I defer to media UX though, since I am only looking at the code.


I agree that having the full opacity be the disabled state is confusing. We can probably change that here, but we should consult with media UX first because there might be a reason behind this decision.

Comment 40

[Rob MacDonald [:robmac]]

Adding Jacqueline as I believe she worked on the recording button initially and may be more familiar with the requirement. Jacqueline, please correct me if I'm wrong. :)

Comment 41

[Eric Pang [:epang] UX]

(In reply to Rob MacDonald [:robmac] from comment #40)
> Adding Jacqueline as I believe she worked on the recording button initially
> and may be more familiar with the requirement. Jacqueline, please correct me
> if I'm wrong. :)

Thanks Michael/Rob, Jacqueline can you help test the ixd?  It seems really messed up to me..  For example, the icon should be full opacity when it's recording.  Also, I don't know if we need a lower opacity icon for when the camera was recently recording, I think this could be confusing to the user.  I think it should be recording or not.  :)

Do you know if there's any reason for the play icon that shows up?

Comment 42

[Jacqueline Savory [:jsavory] UX]

Yes I agree that the ixd seems a bit odd here. I don't think that there is any reason that the play icon should appear, so that might be a separate bug. 

In terms of the record icon, I believe that the original idea with the two versions was to prevent a malicious application from recording for a second and then turning off again. If this were to happen it would be most likely that you wouldn't see the record icon in the status bar. So the idea was to have an actively recording icon and a recently recording icon. 

I do agree that the currently recording icon should be the full opacity and have the disabled state (or recently recording icon) has the lesser opacity. We might want to consider different options for the icons however. Eric, let's sync up tomorrow and talk about the options for the recently recording icon.

Comment 43

[Eric Pang [:epang] UX]

Attachment: Updated Sprites

I've updated the sprites, Michael can you help with swapping out the assets and making the interaction changes?  I'll file a separate bug for the play icon that seems to show up from time to time..

Comment 44

[Eric Pang [:epang] UX]

[Blocking Requested - why for this release]: The current implementation makes it difficult to tell when the camera is in use. The interaction is also behaving in correctly, this bug will address these issues.

Comment 45

[Gregor Wagner [:gwagner]]

according to comment 29 its not a blocking bug.

Comment 46

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8487541 [details]
[screenshot] browser recording icon

Obsolete.

Comment 47

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8487542 [details]
[screenshot] homescreen dark recording icon

Obsolete.

Comment 48

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8487544 [details]
[screenshot] homescreen light recording icon

Obsolete.

Comment 49

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [Gaia PR] Update recording icons

Here's a PR with the updated sprites, and the recording icons swapped. Eric, what do you think?

Comment 50

[Eric Pang [:epang] UX]

Comment on attachment 8494163 [details] [review]
[Gaia PR] Update recording icons

ah, working the way it should be now :).  Thanks for working on this Mike!

Comment 51

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8494163 [details] [review]
[Gaia PR] Update recording icons

Simple change.

Comment 52

[Kevin Grandon :kgrandon]

Comment on attachment 8494163 [details] [review]
[Gaia PR] Update recording icons

Code seems fine, and played with it on a device. Looking at this though I still think our recording states are all kinds of messed up, and not very clear to the end user what's going on - we could be much better here.

Comment 53

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Kevin Grandon :kgrandon from comment #52)
> Comment on attachment 8494163 [details] [review]
> [Gaia PR] Update recording icons
> 
> Code seems fine, and played with it on a device. Looking at this though I
> still think our recording states are all kinds of messed up, and not very
> clear to the end user what's going on - we could be much better here.

Can you be more specific here? What parts do you find confusing, and is it worth a filing a followup?

Comment 54

[Michael Henretty [:mikehenrty][:mhenretty]]

master: https://github.com/mozilla-b2g/gaia/commit/a06714c555ca7068545f10b4437a16c14cd8e7f5

Comment 55

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8494163 [details] [review]
[Gaia PR] Update recording icons

[Bug caused by] (feature/regressing bug #):
Not a regression.

[User impact] if declined:
Confusing UX related to camera recording indicator.

[Testing completed]:
On device testing by assignee and reviewer.

[Risk to taking this patch] (and alternatives if risky):
Very low risk. Asset and CSS change only.

[String changes made]: none

Comment 56

[Kevin Grandon :kgrandon]

(In reply to Michael Henretty [:mhenretty] from comment #53)
> Can you be more specific here? What parts do you find confusing, and is it
> worth a filing a followup?

Meh, I'll leave it up to UX. I just don't understand the recording icon states, but I won't file a follow-up bug until I talk to UX more or get other opinions on it.

Sometimes it appears on the statusbar of other apps in various states though and disappears shortly after - that's pretty confusing, not sure if it's a bug though.

Comment 57

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to Kevin Grandon :kgrandon from comment #56)
> (In reply to Michael Henretty [:mhenretty] from comment #53)
> > Can you be more specific here? What parts do you find confusing, and is it
> > worth a filing a followup?
> 
> Meh, I'll leave it up to UX. I just don't understand the recording icon
> states, but I won't file a follow-up bug until I talk to UX more or get
> other opinions on it.
> 
> Sometimes it appears on the statusbar of other apps in various states though
> and disappears shortly after - that's pretty confusing, not sure if it's a
> bug though.

Yeah, I think this is intentional. See comment 42 for more information. It's probably still open to discussion though if it's confusing.

Comment 58

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/d861c76fdd39cdda5849fb9a82776b63a8086696

Comment 59

[SandKing]

This issue has been verified successfully on Flame2.1&2.2
Verify video:"verify_1050548.mp4".

Flame2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141201001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.034405
FW-Date         Mon Dec  1 03:44:15 EST 2014
Bootloader      L1TC00011880

Flame2.2 bulid:
Gaia-Rev        39214fb22c203e8849aaa1c27b773eeb73212921
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/08be3008650f
Build-ID        20141201040205
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141201.074509
FW-Date         Mon Dec  1 07:45:20 EST 2014

Comment 60

[SandKing]

Attachment: Verified video: verify_1050548.MP4