1120849 - [Flame][NFC]Device A can not send image to device B via NFC, while device A is receiving file via BT.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: NFC, defect)

Description

[Sue]

Attachment: screenshot.png

[1.Description]:
According to Bug 998175 in Comment 65, this bug is filed.
[Flame v2.0 & v2.1 & v2.2][NFC]
When device A is receiving a video from laptop via BT, device A can not send image to device B via NFC.
Device A found time:05:29
Device B found time:05:18
See attachment: logcat_deviceA_0529.txt and logcat_deviceB_0518.txt and screenshot.png

[2.Testing Steps]: 
1. Enable NFC in Settings on both devices.
2. Device A is receiving video from laptop via BT.
3. Touch two devices together.
4. Swipe screen on Device A to share an image to Device B via NFC (laptop is still transfering file).

[3.Expected Result]: 
4. Device A can send image to Device B successfully.

[4.Actual Result]: 
4. Device A could not send image to Device B via NFC. 

[5.Reproduction build]: 
Flame 2.0 build (v188):
Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a05a5378cb1f
Build-ID        20150112000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150112.034955
FW-Date         Mon Jan 12 03:50:06 EST 2015
Bootloader      L1TC00011880

Flame 2.0 build:
Gaia-Rev        31d6c9422cd0a8213df9f96019c9ab7168ec3ab3
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a05a5378cb1f
Build-ID        20150112000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150112.034955
FW-Date         Mon Jan 12 03:50:06 EST 2015
Bootloader      L1TC000118D0

Flame 2.1 build:
Gaia-Rev        1975241ac29f723479e6c60b2bf74ebed54da91a
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/0863fe4b75c3
Build-ID        20150112001215
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150112.035023
FW-Date         Mon Jan 12 03:50:34 EST 2015
Bootloader      L1TC000118D0

Flame 2.2 build:
Gaia-Rev        7c5b27cad370db377b18a742d3f3fdb0070e899f
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/2c37b89bdd86
Build-ID        20150112153951
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150112.194842
FW-Date         Mon Jan 12 19:48:52 EST 2015
Bootloader      L1TC000118D0

[6.Reproduction Frequency]: 
Always Recurrence,5/5

[7.TCID]: 
Free Test

[8.Note]:
I have tested with v188 of base image and latest build of Flame 2.0, when device A is receiving video from laptop via BT, device A can not send image to device B via NFC.

Comment 1

[Sue]

Attachment: logcat_deviceA_0529.txt

Comment 2

[Sue]

Attachment: logcat_deviceB_0518.txt

Comment 3

[Sue]

Hi William, 
According to https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c80
this is a bug, could you help with it? Thanks!

Comment 4

[William Hsu [:whsu]]

(In reply to Sue from comment #3)
> Hi William, 
> According to https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c80
> this is a bug, could you help with it? Thanks!

Thanks Sue. :)

Comment 5

[William Hsu [:whsu]]

[Blocking Requested - why for this release]:

This is not high priority bug, but I still nominate it to see if we need to fix it or put it on the backlog since it conflicts with expected behavior.

Comment 6

[Eric Chang [:ericcc] [:echang]]

Adding NFC QA owner Alison.

Comment 7

[Alison Shiue]

Hi Arno,

According the test video: http://youtu.be/ZMGLpUBhiQc 
1. Device A receive file from laptop
2. Device A try to share file to device B via NFC while receiving file
3. Device B NFC wait file transfer timeout, show "File could not be received"
4. After device A received file from laptop, device A start transfer file to device B
5. File transfer request shows on Device B. (if device B click transfer, file transfer start!)

It looks like the timeout setting (solution of bug 1043856) causes this problem, please correct me if I am wrong. Could you please take a look at this issue?  Thank you.

Comment 8

[Vincent Chang[:vchang][changyihsin]]

Ni Shawn and see if he has any comments here, too.

Comment 9

[arno]

(In reply to Alison Shiue from comment #7)
> Hi Arno,
> 
> According the test video: http://youtu.be/ZMGLpUBhiQc 
> 1. Device A receive file from laptop
> 2. Device A try to share file to device B via NFC while receiving file
> 3. Device B NFC wait file transfer timeout, show "File could not be received"
> 4. After device A received file from laptop, device A start transfer file to
> device B
> 5. File transfer request shows on Device B. (if device B click transfer,
> file transfer start!)
> 
> It looks like the timeout setting (solution of bug 1043856) causes this
> problem, please correct me if I am wrong. Could you please take a look at
> this issue?  Thank you.

What you are experiencing is a race condition that cannot be avoided because device B does not know what is happening at device A. In your setup, device A is still busy with the file transfer but device B just observes that its file transfer is not happening. When the timeout hits, device B assumes that there was a problem and aborts the transfer. When device A later tries to send, it triggers the transfer request dialog at device B.

Just increasing the timeout will not fix this problem. If device A is busy with a really big file transfer, you will always hit the timeout. Also, a long timeout would defer the deactivating of BT (in case it was automatically turned on during the handover). With a long timeout, device B might all of a sudden turn off BT after a long timeout when the user no longer expects it anymore.

Comment 10

[Wesly Huang (EPM)]

[Triage]

Per comment#7 and comment#9 it seems a expected and reasonable behavior?
To clarify if this is a valid issue before Triage decision.


@Alison and Vincent:

Are you seeing this one as a bug?

Comment 11

[Sue]

(In reply to Wesly Huang from comment #10)
> [Triage]
> 
> Per comment#7 and comment#9 it seems a expected and reasonable behavior?
> To clarify if this is a valid issue before Triage decision.
> 
> 
> @Alison and Vincent:
> 
> Are you seeing this one as a bug?

I had verified Bug 998175, and this problem works well with "20140715160201" build of Flame 2.0, you could refer to https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c71

Comment 12

[Alison Shiue]

2 scenarios:
(1) Device B BT initial off: After device A receiving file from laptop, Device A would show "File could not be sent".
(2) Device B BT initial on: After device A receiving file from laptop, File transfer request would show on Device B.

I think user would feel strange about the behavior of (2). 
I am not sure shall we put this as a known issue, maybe we could refer UX opinions.

Comment 13

[arno]

(In reply to Sue from comment #11)
> (In reply to Wesly Huang from comment #10)
> > [Triage]
> > 
> > Per comment#7 and comment#9 it seems a expected and reasonable behavior?
> > To clarify if this is a valid issue before Triage decision.
> > 
> > 
> > @Alison and Vincent:
> > 
> > Are you seeing this one as a bug?
> 
> I had verified Bug 998175, and this problem works well with "20140715160201"
> build of Flame 2.0, you could refer to
> https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c71

The reason this worked in that case was most likely different timings (which is the nature of a race condition). You didn't document how large the file was you tried to transfer. E.g., if the file you used in Bug 998175 was shorter than the file you used in this bug, transfer might have completed before the timeout expired, thus not causing the same behavior as documented in this bug.

Comment 14

[Sue]

(In reply to arno from comment #13)
> The reason this worked in that case was most likely different timings (which is the nature of a race condition). You didn't document how large the file was you tried to transfer. E.g., if the file you used in Bug 998175 was shorter than the file you used in this bug, transfer might have completed before the timeout expired, thus not causing the same behavior as documented in this bug.

I used the same file to test in both Bug 998175 and this bug.

Comment 15

[arno]

(In reply to Alison Shiue from comment #12)
> 2 scenarios:
> (1) Device B BT initial off: After device A receiving file from laptop,
> Device A would show "File could not be sent".
> (2) Device B BT initial on: After device A receiving file from laptop, File
> transfer request would show on Device B.
> 
> I think user would feel strange about the behavior of (2). 
> I am not sure shall we put this as a known issue, maybe we could refer UX
> opinions.

Asking the UX team is a good idea. Here are my thoughts: even for (2) it might be good to prompt the user after the timeout. The reason being is that the NFC handover will cause the BT transfer app to accept the next file send request without prompting the user for permission. If device A crashes and you leave the pending request at device B (without any timeout), it could happen that one hour later device B silently accepts a file transfer request that is unrelated to the NFC handover without prompting the user. Keep in mind that NFC and BT do not share a common context, so when the BT transfer app gets a file transfer request, it is not possible to determine with absolut certainty if this was initiated by a NFC handover or not.

Comment 16

[arno]

(In reply to Sue from comment #14)
> (In reply to arno from comment #13)
> > The reason this worked in that case was most likely different timings (which is the nature of a race condition). You didn't document how large the file was you tried to transfer. E.g., if the file you used in Bug 998175 was shorter than the file you used in this bug, transfer might have completed before the timeout expired, thus not causing the same behavior as documented in this bug.
> 
> I used the same file to test in both Bug 998175 and this bug.

Sue: the difference between the two tests is timing because in this bug the timeout hits while the one you did for Bug 998175 the transfer completed before the timeout. Different file sizes would have been an easy way to explain it but the devious thing about race conditions is that they are difficult to reproduce.

Comment 17

[Sue]

(In reply to arno from comment #16)
> Sue: the difference between the two tests is timing because in this bug the timeout hits while the one you did for Bug 998175 the transfer completed before the timeout. Different file sizes would have been an easy way to explain it but the devious thing about race conditions is that they are difficult to reproduce.

arno, I used a MP4 file that is 15.9MB to test this bug, thanks for your help.

Comment 18

[Juwei Huang[:juwei]]

Hi,
It's a bit awkward in scenario b) in comment 12...
In device B, user already got a failure notification but the device will still receive file afterward, right?

If so, I would suggest that no matter device B initials BT or not, the file should not be received and we can prompt a notification to the user in device B: " Device A is transferring another file, please try again later"

In order to do so, I also want to know that technologically can device B knows the error is because device A is busy on other files from BT ?

Comment 19

[Sue]

(In reply to Juwei Huang from comment #18)
> In device B, user already got a failure notification but the device will
> still receive file afterward, right?

(1)Send a picture from device A to device B via NFC while device A is receiving video from laptop via BT:
In device B, user can't receive the file sent from device A, device B just prompt "File could not be received"
In device A, user can receive the file transfered from laptop, and after about 3 minutes, it will prompt "File could not be sent"
(2)Send a picture from device B to device A via NFC while device A is receiving video from laptop via BT:
In device B, user can't send the file to device A, device B will prompt "File could not be sent"
In device A, user can receive the file transfered from laptop, and it will prompt "File could not be received"

Comment 20

[arno]

(In reply to Juwei Huang from comment #18)
> [...]
> In order to do so, I also want to know that technologically can device B
> knows the error is because device A is busy on other files from BT ?

Although the scenario spans different devices, no device has knowledge of the global state. Device B waits for the file transfer to start but nothing happens. It cannot know if device A is simply busy or crashed. After the timeout, Device B aborts the file transfer and the only sensible message it can show is "Transfer failed". If a little later there is a file transfer request from device A, device B cannot know if this is the delayed request from an earlier NFC handover or a new unrelated transfer request. Please note that the problem is symmetrical and device A also has no global knowledge.

Comment 21

[Vincent Chang[:vchang][changyihsin]]

Can we just reject the NFC sharing while either Device A or Device B is in BT busy state (Maybe we can pop-up a notification message said that BT is in use. Not sure if we have this state currently)?

Comment 22

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Hi,

a. scenario(1) in Comment 12 seems to be OK. I think it's always like this (thru v2.0~v2.2) and we're ok to live with it unless Alison/Juwei disagree. 

b. scenario(2) in Comment 12, and scenario (1) in Comment 19 are "timing issues". Per comment 20, this looks like the limitation. How do we improve/fix it?

c. scenario (2) in Comment 19: I'm confused if this is expected. Alison, could you clarify again?
(https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c74 seems to be conflict with the description of bug 998175)

Both a, b are non-regression, right?

Comment 23

[Alison Shiue]

(In reply to Wesley Huang [:wesley_huang] (EPM) (NI me) from comment #22)
> Hi,
> 
> a. scenario(1) in Comment 12 seems to be OK. I think it's always like this
> (thru v2.0~v2.2) and we're ok to live with it unless Alison/Juwei disagree. 
> 
> b. scenario(2) in Comment 12, and scenario (1) in Comment 19 are "timing
> issues". Per comment 20, this looks like the limitation. How do we
> improve/fix it?
> 
> c. scenario (2) in Comment 19: I'm confused if this is expected. Alison,
> could you clarify again?
> (https://bugzilla.mozilla.org/show_bug.cgi?id=998175#c74 seems to be
> conflict with the description of bug 998175)
> 
> Both a, b are non-regression, right?

I think both a, b are regression, since this issue occurred after bug 1039239 added timeout setting.

Comment 24

[arno]

(In reply to Alison Shiue from comment #23)
> I think both a, b are regression, since this issue occurred after bug
> 1039239 added timeout setting.

Alison is correct that bug 1039239 introduced the timeouts. However, I would not call it a regression. Without the timeout it could happen that a NFC handover request would simply be pending forever if the remote side crashes or does not respond. This is a security problem because the pending handover request would silently accept the next incoming file transfer request without prompting the user for permission; even if that request came an hour later. The timeout is needed to prevent this from happening. However, the timeout also leads to the unavoidable behavior that Sue reported in this bug. If you remove the timeout, it would fix the behavior reported here, but it would also open up the security issue I just mentioned. Pick your poison.

Comment 25

[Alison Shiue]

Hi Arno, 

I tried with android for the same scenario, no matter device B initials BT on or not, the file did not be received (device A and B both show "Beam did not complete") just as Juwei mentioned at Comment 18. Do you think this is a possible solution?

Comment 26

[arno]

(In reply to Alison Shiue from comment #25)
> Hi Arno, 
> 
> I tried with android for the same scenario, no matter device B initials BT
> on or not, the file did not be received (device A and B both show "Beam did
> not complete") just as Juwei mentioned at Comment 18. Do you think this is a
> possible solution?

This is also what Vincent suggested in comment 21. Since UX seems to be OK with such a behavior, I can prepare a patch to mimic the way Android handles this case.

Comment 27

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: let's not block on v2.1 and v2.0 which are already code complete. localization might also be required. Let's fix in 2.2

Comment 28

[arno]

Ian: as per this bug, NFC handover will disallow concurrent file transfers. I made a small change to BluetoothTransfer that allows me to check if a transfer is currently in progress. Would you mind taking a look to see if that change is OK or if you would like to have that implemented differently? TIA.

https://github.com/svic/gaia/commit/4db153ba477e73f9dd9df5b62ebf7aad7f94673e

Comment 29

[[e-mail], [e-mail]]

I'm okay for a small change in BluetoothTransfer module. But I only agree that we do the change in v2.2.

In Gaia/master, we have tried hard to make decoupled for every modules in system app. We can see that BluetoothTransfer module is no longer to access NfcHandoverManager module and vice versa.

BluetoothTransfer
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/bluetooth_transfer.js#L146-L149

NfcHandoverManager
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/nfc_handover_manager.js#L240

Please follow up system work if we want to fix it in master. TIA.

Comment 30

[GitHub Autolander Bot]

Attachment: [PullReq] svic:Bug_1120849 to mozilla-b2g:master

Comment 31

[arno]

Attachment: Don't allow concurrent file transfers (master)

Alive: as per this bug, concurrent file transfers via NFC handover should be blocked. This PR is for master.

Comment 32

[GitHub Autolander Bot]

Attachment: [PullReq] svic:Bug_1120849_v2.2 to mozilla-b2g:v2.2

Comment 33

[arno]

Attachment: Don't allow concurrent file transfers (v2.2)

PR for v2.2 branch.

Comment 34

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

Comment on attachment 8561725 [details] [review]
Don't allow concurrent file transfers (master)

Mock the fileTransferInProgress in mock_service, please.

Comment 35

[arno]

(In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #34)
> Comment on attachment 8561725 [details] [review]
> Don't allow concurrent file transfers (master)
> 
> Mock the fileTransferInProgress in mock_service, please.

Whoever adapted nfc_handover_manager_test.js in master for the new service, used the same pattern of stubbing Service.query:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/test/unit/nfc_handover_manager_test.js#L420

I just followed that pattern. I made the change you suggested but that seems to conflict with the import of service.js:
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/test/unit/nfc_handover_manager_test.js#L24

Fixing your nit would require some other changes not relevant to this bug. Do you want to fix all of this as part of this patch or open a new bug to cleanup the usage of Service?

Comment 36

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

(In reply to arno from comment #35)
> (In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #34)
> > Comment on attachment 8561725 [details] [review]
> > Don't allow concurrent file transfers (master)
> > 
> > Mock the fileTransferInProgress in mock_service, please.
> 
> Whoever adapted nfc_handover_manager_test.js in master for the new service,
> used the same pattern of stubbing Service.query:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/test/unit/
> nfc_handover_manager_test.js#L420
> 
> I just followed that pattern. I made the change you suggested but that seems
> to conflict with the import of service.js:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/test/unit/
> nfc_handover_manager_test.js#L24

It is. So what you need is require shared/test/mocks/mock_service.js and
nfcHandoverManager.service = MockService;
MockService.mBluetoothTransferInProgress = true
// ..assert...

> 
> Fixing your nit would require some other changes not relevant to this bug.
> Do you want to fix all of this as part of this patch or open a new bug to
> cleanup the usage of Service?

It's up to you.I am fine with followup.

Comment 37

[arno]

(In reply to Alive Kuo@Paris~2/17 [:alive][NEEDINFO!] from comment #36)
> > Fixing your nit would require some other changes not relevant to this bug.
> > Do you want to fix all of this as part of this patch or open a new bug to
> > cleanup the usage of Service?
> 
> It's up to you.I am fine with followup.

Thanks for your guidance. I will fix the other stubbing of Service as part of this bug since it is a very small change.

Comment 38

[arno]

Attachment: Don't allow concurrent file transfers (v2.2) r=alive

Comment 39

[arno]

Attachment: Don't allow concurrent file transfers (master) r=alive

Comment 40

[Ryan VanderMeulen [:RyanVM]]

Can you please rebase the patches and update the pull requests? Github can't merge them.

Comment 41

[arno]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #40)
> Can you please rebase the patches and update the pull requests? Github can't
> merge them.

done.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

There's a Linter failure on the Gaia Try run.
https://treeherder.mozilla.org/logviewer.html#?job_id=507136&repo=gaia-try

Comment 43

[arno]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #42)
> There's a Linter failure on the Gaia Try run.
> https://treeherder.mozilla.org/logviewer.html#?job_id=507136&repo=gaia-try

Sorry about that. Fixed...

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Github says that the PR needs rebasing.

Comment 45

[arno]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #44)
> Github says that the PR needs rebasing.

rebased again.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

At last! :P

Master: https://github.com/mozilla-b2g/gaia/commit/ddc06cc00cc2d8da4a331affd15d9d3b99066356

Comment 47

[Ryan VanderMeulen [:RyanVM]]

Please request Gaia v2.2 approval on this patch when you get a chance.

Comment 48

[arno]

(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #47)
> Please request Gaia v2.2 approval on this patch when you get a chance.

Please ignore my ignorance but how do I do this? The v2.2 patch was r+ed by Alive.

Comment 49

[Ryan VanderMeulen [:RyanVM]]

It's a flag on the attachment.

Comment 50

[arno]

Comment on attachment 8563533 [details] [review]
Don't allow concurrent file transfers (v2.2) r=alive

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]:

Comment 51

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

Comment on attachment 8563533 [details] [review]
Don't allow concurrent file transfers (v2.2) r=alive

I am not sheriff. Someone will reply later.

Comment 52

[bhavana bajaj [:bajaj]]

(In reply to arno from comment #50)
> Comment on attachment 8563533 [details] [review]
> Don't allow concurrent file transfers (v2.2) r=alive
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #):
> [User impact] if declined:
> [Testing completed]:
> [Risk to taking this patch] (and alternatives if risky):
> [String changes made]:

Can you please fill the questions requested above ? This helps us understand the risk and testing done on the patch you are trying to uplift. Thanks!

Comment 53

[arno]

Comment on attachment 8563533 [details] [review]
Don't allow concurrent file transfers (v2.2) r=alive

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): NFC/BT
[User impact] if declined: not disabling concurrent file transfers will very likely lead to timeouts that may confuse users
[Testing completed]: Tests were done with Flame devices. Patch includes unit tests.
[Risk to taking this patch] (and alternatives if risky): None
[String changes made]: New string ID: transferFinished-try-again-description

Comment 54

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/c48d20c87e2c3af08cc89b58c65decbccdec6add

Comment 55

[[e-mail]]

In master I found isFileTransferInProgress() is not defined in BluetoothTransfer.js, and the event is not registered as well. Can you check it?

Comment 56

[arno]

(In reply to Fred Lin [:gasolin] from comment #55)
> In master I found isFileTransferInProgress() is not defined in
> BluetoothTransfer.js, and the event is not registered as well. Can you check
> it?

You are right and I am too embarrassed to explain how this happened. I created Bug 1144556 that adds the missing changes to BluetoothTransfer in master. Nice catch!

Comment 57

[Delphine Lebédel [:delphine - Use needinfo]]

Please remember to add the late-l10n keyword when you land patches on 2.2 with string changes! (too late now)
late-l10n keyword use started at FL...thanks!

Comment 58

[Alison Shiue]

Verified on 
[2.2]
Gaia-Rev        44c62060581fde8de1e12e94cf55e9673b401a47
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/e6140a32902a
Build-ID        20150322162502
Version         37.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150322.200808
FW-Date         Sun Mar 22 20:08:19 EDT 2015
Bootloader      L1TC100118D0

But if sender which initial BT disabled try to send files to receiver which is receiving files, after sender get notification "Cannot send file right now....", BT did not back to the default setting.
Creating bug 1146220 to track this issue.

Comment 59

[Alison Shiue]

Verified on 3.0

Build ID               20150426160201
Gaia Revision          b4c949cdc780893897c9b45c1adea46e2eb694ff
Gaia Date              2015-04-24 16:13:40
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/37d60e3b8be6
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150426.193323
Firmware Date          Sun Apr 26 19:33:34 EDT 2015
Bootloader             L1TC100118D0