Closed Bug 1182644 Opened 9 years ago Closed 9 years ago

[Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::Bluetooth
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:2.5+, b2g-master affected)

Status:
RESOLVED DUPLICATE of bug 1191715
Project Flags:
blocking-b2g 2.5+
Tracking Flags:
Tracking Status
b2g-master --- affected

People

(Reporter: NicholasN, Unassigned)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [2.5-Daily-Testing][Spark])

Attachments

(1 file)

logcat_bluetooth.txt
609.12 KB, text/plain
Details
Attached file logcat_bluetooth.txt — 
Description:
The user pairs the device to a laptop via bluetooth, then shares any file. Right as the transfer completes successfully, the device appears to reboot. Sometimes the just goes black and returns to the lock screen when the power button is tapped. Other times the screen goes black, the blue firefox OS screen appears, and then the lock screen comes up. This does not occur device to device, only device to laptop.


Repro Steps:
1) Update an Aries to 20150710105517
2) Enable bluetooth and pair to a laptop.
3) Open any file that can be shared, and share via bluetooth to the laptop.
4) Open the notification tray and observe transfer.


Actual:
Device reboots just as the transfer completes successfully.


Expected:
Device does not reboot after transfer.


Notes:

Environmental Variables:
Device: Aries 2.5
Build ID: 20150710105517
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: f7e1f596d57d
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0


Repro frequency: 6/6
See attached: video clip, logcat
This issue does not occur in Flame 2.5 or the RC4 build of AriesKK. It appears to be a recent regression in Aries.

Flame 2.5

Actual Result:

Bluetooth transfer completed and the phone did not reboot.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150710010203
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: 2c91d57441fd
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0


AriesKK 2.5 (RC4 Build)

Actual Result:

Bluetooth transfer completed and the phone did not reboot.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150619225606
Gaia: 4c06ed88ddccaba8dc941e5006bd2a9e57306f07
Gecko: 7c1a6b1151a1539186b950a144387e2d7f378d1b
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
URL: https://www.youtube.com/watch?edit=vd...
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master: --- → affected
Flags: needinfo?(pbylenga)
Keywords: regression
Summary: [Bluetooth] Device restarts after file transfer completes. → [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
Whiteboard: [2.5-Daily-Testing][Spark]
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Keywords: qaurgent, regressionwindow-wanted, smoketest
Summary: [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer. → [Aries][Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
The changes for Bug 1155059 seem to have caused this issue.

Mozilla-inbound Regression Window

Last Working 
Environmental Variables:
Device: Aries 2.5
BuildID: 20150710034840
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: 3871596b6370
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

First Broken 
Environmental Variables:
Device: Aries 2.5
BuildID: 20150710035707
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: 470d574f3f49
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Last Working gaia / First Broken gecko - Issue DOES occur
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: 470d574f3f49

First Broken gaia / Last Working gecko - Issue does NOT occur
Gaia: ad76c159c641c977d9140c5fedea84aea04e0e60
Gecko: 3871596b6370

Gecko Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3871596b6370&tochange=470d574f3f49
Blocks: 1155059
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qaurgent, regressionwindow-wanted
Randell, can you take a look at this please? This might have been caused by the work done for bug 1155059. This is a smoke test blocker.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(rjesup)
This issue is now seen occurring on Flame devices with the latest 2.5 build.
Device reboots just as the transfer completes successfully.

Environmental Variables:
Device: Flame 2.5
Build ID: 20150713010204
Gaia: e4b63559eba364892867eb381c3002d6518e5d6a
Gecko: eab21ec484bb
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Summary: [Aries][Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer. → [Bluetooth] When transferring a file to laptop, device restarts upon completion of transfer.
Flagging the reviewers of bug 1155059 to take a look initially, instead of backing out the bulk of commits, this is a smoketest blocker.
Flags: needinfo?(nfroyd)
Flags: needinfo?(jdaggett)
Flags: needinfo?(cpearce)
I suspect this has tripped an existing bug, perhaps timing.  I've already found several instances of "don't know which thread something will release on" with runnables while working on converting directories over to already_AddRefed.

Is this a)crashing the device, or b) forcing gecko/gaia to restart?

Can you attach with GDB and catch the crash?

Can you tell me how to reproduce this locally?  I have Flame devices, though they need updating.
Flags: needinfo?(rjesup) → needinfo?(nnelson)
Also, is it possible to run this in a debug build?  Yes, I know it'll be slow...
Requesting qawanted to assist with Comment 7 and Comment 8
Keywords: qaurgent, qawanted
Looks like there's no taskcluster debug aries builds anymore, I'll have to follow up with taskcluster team.

There's debug builds for flame : https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame-kk-eng-debug/
It happens on flame, Naoki provided the debug builds. Currently not set-up to connect with GDB locally here.

The device rebooted and didn't provide a crash report.  Attachment 8632271 [details] has the adb logcat

To produce it locally, have a laptop with bluetooth enabled:
1. Connect Flame to laptop
2. From Gallery send picture to laptop

Actual Flame reboots after sending (file is received by laptop).
Flags: needinfo?(nnelson) → needinfo?(rjesup)
I think this is an issue unrelated to the fontloader changes that I reviewed.
Flags: needinfo?(jdaggett)
I downloaded the latest build from and flashed flame-kk.zip (./flash.sh)

Turned on Bluetooth, made visible.  Paired from laptop and phone.  Laptop (Win7 W520) installed most drivers (first two failed).

Took picture on Flame.  Viewed it, hit the share icon.  Selected Bluetooth & the laptop.  

File transfered, saw notification it was done.  No crashes.

Any steps missing?  The base build on this flame is likely old.
Flags: needinfo?(rjesup)
Flags: needinfo?(nnelson)
Flags: needinfo?(nhirata.bugzilla)
We are testing in a Linux environment using Ubuntu 12.04. I was able to reproduce this on the latest flame build we have with those same steps.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150714010206
Gaia: 7676b68b4d32ed13243eeb719188847121bd5611
Gecko: 0931671a14ef
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

You can find the latest base here:

https://developer.mozilla.org/en-US/Firefox_OS/Phone_guide/Flame/Updating_your_Flame#Up-to-date_%28use_these_unless_you_have_a_good_reason_not_to%29
Flags: needinfo?(nnelson)
Just as a side follow up : Bug 1184336 for the Aries debug builds.

Wait.  If Randall can't reproduce with an old gonk layer and we can reproduce with a newer gonk layer, doesn't that mean the issue is in the gonk?

Randall, could you please update your flame's gonk layer and retest to see if you can reproduce?
Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip
Flags: needinfo?(nhirata.bugzilla) → needinfo?(rjesup)
Flags: needinfo?(cpearce)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #15)
> Just as a side follow up : Bug 1184336 for the Aries debug builds.
> 
> Wait.  If Randall can't reproduce with an old gonk layer and we can
> reproduce with a newer gonk layer, doesn't that mean the issue is in the
> gonk?
> 
> Randall, could you please update your flame's gonk layer and retest to see
> if you can reproduce?
> Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip

Flashed 18D_nightly_v3 (which says it's v5 in the zip file...)
Softwar/OS Version (in Device Information) used to say 2.5.0.0-prerelease, now it says 3.0.0.0-prerelease.  This installed a 5/27 Gecko; this also worked.  (

I then installed the newer gecko per above (7/13).  This won't boot; I'm seeing this:

F/MOZ_Assert( 1245): Assertion failure: timestamp <= PR_Now(), at /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/dom/quota/QuotaManager.cpp:3324
Flags: needinfo?(rjesup) → needinfo?(nhirata.bugzilla)
That's https://bugzilla.mozilla.org/show_bug.cgi?id=1110010
This shouldn't cause the phone not to boot. 

You have to have the matching gecko/gaia versions together in order for it to boot correctly.  It may be easier to do a full flash of the device once you flashed the contributor build.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(rjesup)
(In reply to Randell Jesup [:jesup] from comment #16)
> (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from
> comment #15)
> > Just as a side follow up : Bug 1184336 for the Aries debug builds.
> > 
> > Wait.  If Randall can't reproduce with an old gonk layer and we can
> > reproduce with a newer gonk layer, doesn't that mean the issue is in the
> > gonk?
> > 
> > Randall, could you please update your flame's gonk layer and retest to see
> > if you can reproduce?
> > Direct link to the build : http://cds.w5v8t3u9.hwcdn.net/v18D_nightly_v3.zip
> 
> Flashed 18D_nightly_v3 (which says it's v5 in the zip file...)
> Softwar/OS Version (in Device Information) used to say 2.5.0.0-prerelease,
> now it says 3.0.0.0-prerelease.  This installed a 5/27 Gecko; this also
> worked.  (
> 
> I then installed the newer gecko per above (7/13).  This won't boot; I'm
> seeing this:
> 
> F/MOZ_Assert( 1245): Assertion failure: timestamp <= PR_Now(), at
> /builds/slave/b2g_m-cen_flm-kk_eng-d_dep-000/build/gecko/dom/quota/
> QuotaManager.cpp:3324

This should be fixed if you perform 'make reset-gaia' in the gaia folder.
Jesup could not reproduce on windows, I could not reproduce on Mac nor Linux using debug build, asked PBylenga and his team to reinvestigate.
Flags: needinfo?(pbylenga)
I can believe that bug 1155059 turned up some issues; I don't think I have anything useful to contribute here, though.
Flags: needinfo?(nfroyd)
I was able to reproduce this issue using a debug engineering build when transferring to both an Ubuntu laptop, and a Windows 7 laptop.

Environmental Variables:
Device: Flame 2.5 (Full Flash)
Build ID: 20150721073213
Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
Gecko: d7a9e44717b7
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Flags: needinfo?(pbylenga)
(In reply to Martin Shuman [:Marty] from comment #21)
> I was able to reproduce this issue using a debug engineering build when
> transferring to both an Ubuntu laptop, and a Windows 7 laptop.

Where can I install this exact version from?

> 
> Environmental Variables:
> Device: Flame 2.5 (Full Flash)
> Build ID: 20150721073213
> Gaia: 4fe0507781f3ed56c8ae5e66dd9489165d1ff68e
> Gecko: d7a9e44717b7
> Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Flags: needinfo?(rjesup) → needinfo?(pbylenga)
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/tinderbox-builds/mozilla-central-flame-kk-eng-debug/20150721073213/

Here's the pvt link for the build used.
Flags: needinfo?(pbylenga) → needinfo?(rjesup)
I also should note we used the flame-kk.zip to full flash.
Flashed that build.  Couldn't pair (many attempts), rebooted, wouldn't boot (known assertion issue).  did reset-gaia, tried again.  *Many* pairing attempts later it *finally* paired (it wouldn't show the code/UX with Pair button).  Transferred photo from camera.  No crash.  Tried transferring from Gallery as well, no crash.

I'm stuck until someone can get a log from a crashing phone (that shows the crash) at least or better yet reproduce it in gdb.
Flags: needinfo?(rjesup)
Flags: needinfo?(pbylenga)
Flags: needinfo?(nhirata.bugzilla)
Given that the dev and I are having a hard time reproducing the issue, could we get a video of the reproduction?  I think there's some step missing.
I'm not sure if this matters, which side initiated the connection?  

Also which module is on the linux box itself to support the blue tooth transfer?
(In reply to Randell Jesup [:jesup] from comment #25)
> Flashed that build.  Couldn't pair (many attempts), rebooted, wouldn't boot
> (known assertion issue).  did reset-gaia, tried again.  *Many* pairing
> attempts later it *finally* paired (it wouldn't show the code/UX with Pair
> button).  Transferred photo from camera.  No crash.  Tried transferring from
> Gallery as well, no crash.
> 
> I'm stuck until someone can get a log from a crashing phone (that shows the
> crash) at least or better yet reproduce it in gdb.

This sounds like issues we used to see on an older Gonk, can you update base image before flashing?

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #26)
> Given that the dev and I are having a hard time reproducing the issue, could
> we get a video of the reproduction?  I think there's some step missing.

There's a video already in the URL section


(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #27)
> I'm not sure if this matters, which side initiated the connection?  
> 
> Also which module is on the linux box itself to support the blue tooth
> transfer?

We've done both for initiation (starting at laptop and phone)
We're using a bluetooth dongle:
http://www.iogear.com/product/GBU521/
Flags: needinfo?(pbylenga)
Marked as 2.5+, it's pretty serious which need to be fixed
blocking-b2g: 2.5? → 2.5+
Ok: differences in the video from what I did (and I presume naoki did):
a) it's not a Flame, though according to the comments here it happens to Flames as well now. (ok)
b) it's a video, not a still image (dunno if it matters).  ALso, it was done via the Video app, not the camera.   Initial report says "any file that can be shared".
c) most of my tests were from viewing the items, not from the list of items (and typically from viewing the picture from the camera app, though I tried the gallery once too out of paranoia).
d) the notification bar was pulled down to watch the transfer.  I just started it and waited

So I tried this (on a Flame), as close as I could.  No crash.

NI to nhirata.  I'm out of ways to look at this without someone getting some more data.  I'll note there are a TON of Dispatch/DispatchToMainThread in bluetooth, and typically they were done in a way that was not threadsafe (the Release() might happen on MainThread, or on the sending thread, depending on timing) - and most are still that way until followup patches land, but there may be minor timing or other differences that affect which thread or exactly when it's destroyed (which this API change is meant to help us resolve to get reliable behavior).  There are patches to move to reliable Dispatch semantics for bluetooth (untested) on a bug now with a ton of other patches
I suspect the dongle. 

The bluetooth device is a v4 bluetooth.  I only have v2 devices.

Can you try to reproduce this issue with v2 bluetooth machine/device instead if there's a machine available such as that?

I will see about a v4 bluetooth dongle.
Flags: needinfo?(pbylenga)
I attempted to pair the Aries to my Ipad Mini (which uses v2 bluetooth). Unfortunately I was unable to do so and consistently kept receiving a "Unsupported format" message. Tomorrow we will have access to a Surface Pro V3 tablet and will be attempting with a V4 bluetooth connection.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150727165113
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: d576f2cec511
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
I tested this on Flame 2.5 and Aries KK, connecting to a V4 bluetooth device (Windows laptop). In both instances the file failed to send just after initiating the transfer. 4/4 repro attempts.

Aries KK

Actual Result:

File fails to send right after transfer begins.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150729131820
Gaia: 302a448729ff2b336581cf94b66327ea836294c7
Gecko: cd9fa05c943e6784faeeaff7c027d1b561c070b0
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Flame 2.5

Actual Result:

File fails to send right after transfer begins.

Environmental Variables:
Device: Flame 2.5
BuildID: 20150729030209
Gaia: 21256d7665f972255d198f8af81a8df4bd0e0fc4
Gecko: 2ee9895e032c
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
Blocks: 1174840
clearing NI, leaving qawanted to try to get a gdb log
Flags: needinfo?(pbylenga)
Nick can you write up a new issue for the instances where we failed to pair.
Flags: needinfo?(nnelson)
Here is the bug for the V4 issue I mentioned above.

https://bugzilla.mozilla.org/show_bug.cgi?id=1189521
Flags: needinfo?(nnelson)
Odd.  I thought I updated this bug last friday.

Anyhow, the v4 BT dongle seemed to work for me on the windows machine.  I think it's that specific version of the adapter that's the issue.

I think we'll need an iogear v4 bt adapater.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
Demoting as a smoke test blocker given it may be specific to certain hardware configurations.  Still a major issue.
Keywords: smoketest
Hi Ben, does this bug have the same root cause with bug 1189521?
Flags: needinfo?(btian)
(In reply to Ken Chang[:ken] from comment #39)
> Hi Ben, does this bug have the same root cause with bug 1189521?

I don't think so. This bug's symptom is crash, while bug 1189521 only shows error and happens on Surface only.
Flags: needinfo?(btian)
I still cannot reproduce the original issue of the reboot after sending the file.

When I send the file from the device, it cancels it automatically.
When I send the file from the computer, the image is sent without reboot.  I don't think this issue exists any more.

Comment 33 also doesn't specify that the original issue is being seen.  I think we need to close this out as WFM and open a new one in regards to the device not sending.
Flags: needinfo?(nhirata.bugzilla) → needinfo?(nnelson)
To note, I used Ubuntu + the iogear BT v4 adapter.  I should be using the same configuration as per the reporter.
The bug symptom seems similar to bug 1191715 since the crash happens during disconnection.

qawanted to confirm whether this bug remains on the latest m-c since bug 1191715 fix is already landed.
Following the repro steps in description, I did not observe any issue on the latest master build. Files transferred to laptop successfully. 

Build ID               20150909215153
Gaia Revision          47459eead04385e22f967012b824f5abdddcfb7c
Gaia Date              2015-09-09 10:37:28
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/dd2a1d737a64d9a3f23714ec5cc623ec8933b51f
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150909.211310
Firmware Date          Wed Sep  9 21:13:17 UTC 2015
Bootloader             s1
Resolve duplicate per comment 44. Please reopen this bug for any further concern or if it reoccurs.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
This issue is no longer occurring on the the latest Flame and Spark 2.5 Master builds. The bluetooth transfer completes successfully, and the device does not crash or restart afterwards.

I did try this on a 9/8 Flame build from a couple days ago, before the fix for bug 1191715, and the issue was still occurring, so I would agree that this is a dupe of that bug.

Removing qaurgent and qawanted tags.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150909215207
Gaia: 47459eead04385e22f967012b824f5abdddcfb7c
Gecko: dd2a1d737a64d9a3f23714ec5cc623ec8933b51f
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150910030223
Gaia: 47459eead04385e22f967012b824f5abdddcfb7c
Gecko: dd2a1d737a64d9a3f23714ec5cc623ec8933b51f
Gonk: c4779d6da0f85894b1f78f0351b43f2949e8decd
Version: 43.0a1 (2.5)
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(nnelson) → needinfo?(jmercado)
Keywords: qaurgent, qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: