Closed
Bug 1043813
Opened 10 years ago
Closed 10 years ago
[B2G][Flame]Volume level is very low at max setting
Categories
(Firefox OS Graveyard :: AudioChannel, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: bkerensa, Assigned: gerard-majax)
References
Details
(Keywords: dogfood, regression, Whiteboard: [2.1-flame-test-run-2][fullflash-smoketest])
Attachments
(3 files)
When making calls the volume level at max is very low and it is much harder to hear calls then on other platforms. Tested with nightly on a Flame handset.
Reporter | ||
Comment 1•10 years ago
|
||
Version: 2.1.0.0-prerelease Platform: 34.0a1 Build: 20140805040204
Component: General → AudioChannel
Summary: Volume level is very low → [b2g] Volume level is very low at max setting
Reporter | ||
Comment 2•10 years ago
|
||
[Blocking Requested - why for this release]:
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Summary: [b2g] Volume level is very low at max setting → [B2G][Flame]Volume level is very low at max setting
Reporter | ||
Comment 3•10 years ago
|
||
[Blocking Requested - why for this release]: Call volume is too loud on max setting to the point user cannot hear other caller.
blocking-b2g: --- → 2.1?
Reporter | ||
Comment 5•10 years ago
|
||
I just tested the volume again and I put it at one bar and the volume level seems identical and when I increased it to max during the call there was no noticeable change in volume. Mind you I noticed someone on Twitter said the lowest volume setting is too loud on the Flame.
Comment 6•10 years ago
|
||
302 mwu, this is out of my area of expertise.
Flags: needinfo?(paul) → needinfo?(mwu)
Comment 7•10 years ago
|
||
Requesting qawanted for branch checks. Not only is the volume far too low, the volume controls do not change the volume. It's the same level of too-quiet whether the controls are at the highest or lowest point.
Comment 8•10 years ago
|
||
Dietrich - are you sure this is a regression already? I've only seen info for it occurring on 2.1 and no evidence of anyone checking 2.0 or 1.4 yet.
Flags: needinfo?(dietrich)
Comment 9•10 years ago
|
||
Hm, I'm not sure. I seem to remember it being louder before. But human senses and memory are a lie.
Flags: needinfo?(dietrich)
Comment 10•10 years ago
|
||
Hah. Fair enough. Branch checks are under-way.
Comment 11•10 years ago
|
||
Can you please provide the base version you were using? I was unable to repro on the same nightly build nor on today's engineering builds for 2.1 or 2.0. 2.1 nightly BuildID: 20140805040204 Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9 Gecko: 7f81be7db528 Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 2.1 engineering BuildID: 20140814004506 Gaia: 5e074831f9ddacdf6f622a6dffaecb626f740be8 Gecko: de1d3c229e5a Platform Version: 34.0a1 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0 2.0 engineering BuildID: 20140814024604 Gaia: d889984833025f208cfd3f3c2c37c87940a529dc Gecko: abdb13f41d68 Platform Version: 32.0 Firmware Version: V123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Flags: needinfo?(bkerensa)
Reporter | ||
Comment 12•10 years ago
|
||
2.1 User BuildID: 20140814040202 Platform: 34.0a1 Not sure how to grab the Firmware or Gaia info. But Dietrich and others have been able to reproduce on their own hardware too.
Flags: needinfo?(bkerensa)
Comment 13•10 years ago
|
||
Unable to reproduce this issue on the build the user provided with either V122 or v123 bases for flame. Was always able to adjust the volume higher on the DuT during a call. Adjusted all volumes in settings to both extremes with no problems seen. In comment 11 branch checks were done without success and I was just trying to get the bug on an original build with various base firmwares. Environmental Variables: Nightly build Device: Flame Master BuildID: 20140805040204 Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9 Gecko: 7f81be7db528 Version: 34.0a1 (Master) Firmware Version: v122 ----------------------------------------------- Environmental Variables: Nightly build Device: Flame Master BuildID: 20140805040204 Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9 Gecko: 7f81be7db528 Version: 34.0a1 (Master) Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 14•10 years ago
|
||
I'm using the OTAs on Nightly channel. Maybe you have better hearing than I do. I went to a lot of super loud shows when I was young.
Comment 15•10 years ago
|
||
Cody can you try flashing to yesterdays 2.1 and do an OTA and then attempt to reproduce, perhaps that's the difference we need?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga) → needinfo?(croesch)
Comment 16•10 years ago
|
||
Sorry.........no luck there either. Flashing Nightly 2.1 to 8/14 build then OTAing to today's 8/15 build does not cause an issue with calls being too quiet and not being able to adjust volume. Environmental Variables: Nightly Build Device: Flame Master Build ID: 20140815040204 Gaia: 9979fccc6321be72cd17370f3a20c65bc376af33 Gecko: c9f8cc9ce89c Version: 34.0a1 (Master) Firmware Version: v123
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(croesch) → needinfo?(pbylenga)
Reporter | ||
Comment 17•10 years ago
|
||
Is there anything else myself or Dietrich can offer to help isolate this?
Comment 18•10 years ago
|
||
Maybe the firmware used will reveal something? Run the following command adb shell getprop t2m.sw.version First 3 of the last 4 digits is the Firmware, mine ends in '1230' and is v123.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(bkerensa)
Reporter | ||
Comment 19•10 years ago
|
||
That command generates no return for me but other adb commands work fine.
Flags: needinfo?(bkerensa)
Reporter | ||
Comment 20•10 years ago
|
||
Dietrich, can you run Th above since mine is not outputting anything useful?
Flags: needinfo?(dietrich)
Comment 21•10 years ago
|
||
Three people on our test team have taken a shot at this bug to reproduce, but we've had no success at reproducing this. As a result, I'm going to have to remove QA keywords for now, since there's it doesn't look like we're going to be able to help here unless we get better clarification on STR.
Keywords: qawanted,
regressionwindow-wanted
Reporter | ||
Comment 22•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #21) > Three people on our test team have taken a shot at this bug to reproduce, > but we've had no success at reproducing this. As a result, I'm going to have > to remove QA keywords for now, since there's it doesn't look like we're > going to be able to help here unless we get better clarification on STR. STR are: 1. Make a call with volume set to lowest setting 2. Listen to call volume 3. Increase call volume to max and notice no distinguishable change 4. Decrease volume back to low while still on call notice no change
Comment 23•10 years ago
|
||
QA-Wanted to attempt Repro with the updated STR (comment 22). If we get a Repro, please do a branch check.
Keywords: qawanted
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+]
Comment 24•10 years ago
|
||
(In reply to Benjamin Kerensa [:bkerensa] from comment #19) > Created attachment 8474702 [details] > Results > > That command generates no return for me but other adb commands work fine. Ditto. This command executes successfully, and returns nothing.
Flags: needinfo?(dietrich)
Reporter | ||
Comment 25•10 years ago
|
||
Any reason why this command would not be working? Were hoping to provide info so this can be isolated.
Flags: needinfo?(pbylenga)
Comment 26•10 years ago
|
||
The command is working. You just don't have a t2m.sw.version property set in your build. Which build is that exactly?
Reporter | ||
Comment 27•10 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #26) > The command is working. You just don't have a t2m.sw.version property set in > your build. Which build is that exactly? The nightly build and now OTA's Mozilla is providing for the flames?
Comment 28•10 years ago
|
||
What did you use as the base for the phone? Or more specifically, have you ever flashed an OEM base image to your device?
Flags: needinfo?(pbylenga)
Flags: needinfo?(dietrich)
Flags: needinfo?(bkerensa)
Comment 29•10 years ago
|
||
PVT build of master + m-c via the scripts at https://github.com/Mozilla-TWQA/B2G-flash-tool. Switched to channel "nightly", also via the scripts there.
Flags: needinfo?(dietrich)
Reporter | ||
Comment 30•10 years ago
|
||
(In reply to Peter Bylenga [:PBylenga] from comment #28) > What did you use as the base for the phone? Or more specifically, have you > ever flashed an OEM base image to your device? As far as it was explained to me the Flame's came pre-flashed with the 123 base image and that once we then flashed the nightly https://developer.mozilla.org/en-US/Firefox_OS/Developer_phone_guide/Flame using shallow flash we were good to go?
Flags: needinfo?(bkerensa)
Comment 31•10 years ago
|
||
Oops, I missed that part of the question. My device's current state is * flashed base image * flashed latest build via the QA scripts * OTAs via nightly channel
Comment 32•10 years ago
|
||
Thanks for the information Dietrich and Benjamin! I think the full flash may be the culprit as it changes more than just a gecko/gaia flash. Okay, adding qawanted to try the following: * flash base v123 * full flash with B2G-flash-Tool to yesterday's build * OTA to today's nightly attempt STRs provided in Comment 22.
Reporter | ||
Comment 34•10 years ago
|
||
Just to confirm I flashed v123 today then used shallow to upgrade to nightly then checked for OTA and am on today's nightly OTA and still same volume issues.
Comment 35•10 years ago
|
||
Using the steps from comment 32 and comment 22 I was unable to reproduce this issue. The volume difference between maximum and minimum volume is not very large, but it is noticeable and I was always able to understand the other caller even at minimum volume. Environmental Variables: (after updating) Device: Flame Master BuildID: 20140828040204 Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2 Gecko: 3be45b58fc47 Version: 34.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Reporter | ||
Comment 36•10 years ago
|
||
(In reply to Jayme Mercado [:JMercado] from comment #35) > Using the steps from comment 32 and comment 22 I was unable to reproduce > this issue. The volume difference between maximum and minimum volume is not > very large, but it is noticeable and I was always able to understand the > other caller even at minimum volume. > > Environmental Variables: (after updating) > Device: Flame Master > BuildID: 20140828040204 > Gaia: 3a838afca295c9db32e1a3ec76d49fb7fe7fd2d2 > Gecko: 3be45b58fc47 > Version: 34.0a1 (Master) > Firmware Version: v123 > User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 So you agree its not very large but would you be able to take a call on a city street at max volume? I know I cannot and others have experienced same. If indeed there is an increase in volume I would highly suggest we increase the max volume and create a larger gap. With this current volume situation I cannot dogfood.
Comment 37•10 years ago
|
||
I'm gonna assume we all make calls in different settings and we all have differently shaped faces and ears and different hearing abilities so there are many ways this could fail for people. I agree that the range between low and high volume is not enough. The full loud setting should make me want to pull the phone away from my ear and it does not. I've compared with a couple of other devices and we are quieter at the high end for sure. Let's increase the range. Where does this code live? Can we tune in Gecko/Gaia or do we need more from the manufacturer?
Comment 38•10 years ago
|
||
Alex, have you seen this? I'm wondering if we're hitting a difference between the vendor's audio policy and ours, or some other difference in binary blobs..
Flags: needinfo?(mwu) → needinfo?(lissyx+mozillians)
Assignee | ||
Comment 39•10 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #38) > Alex, have you seen this? I'm wondering if we're hitting a difference > between the vendor's audio policy and ours, or some other difference in > binary blobs.. I remember seeing commits related to this, but I can't remember in which repo.
Flags: needinfo?(lissyx+mozillians)
Assignee | ||
Comment 40•10 years ago
|
||
> adb shell dumpsys media.audio_policy
I don't see any change at all in volume on my Kitkat build :(
Flags: needinfo?(bkerensa)
Assignee | ||
Comment 41•10 years ago
|
||
I just checked on a JB build on Etienne's phone.
Running:
> adb shell dumpsys media.audio_policy
Shows that we are changing stream 0 volume properly, but I don't hear any change :(
Assignee | ||
Comment 42•10 years ago
|
||
I do reproduce this on my own Flame JB full flash.
Assignee | ||
Comment 43•10 years ago
|
||
We will need help from T2M to know where and when they fixed this.
Flags: needinfo?(bkerensa) → needinfo?(vchen)
Assignee | ||
Comment 44•10 years ago
|
||
Okay, even pushing /system/lib/ from v123 base image has no impact :(
Comment 47•10 years ago
|
||
(In reply to Benjamin Kerensa [:bkerensa] from comment #0) > When making calls the volume level at max is very low and it is much harder > to hear calls then on other platforms. Tested with nightly on a Flame > handset. Hi Benjamin, could you describe what output did you use? speaker or receiver?
Updated•10 years ago
|
Flags: needinfo?(bkerensa)
Reporter | ||
Comment 48•10 years ago
|
||
(In reply to Wayne Chen [:xwaynec] from comment #47) > (In reply to Benjamin Kerensa [:bkerensa] from comment #0) > > When making calls the volume level at max is very low and it is much harder > > to hear calls then on other platforms. Tested with nightly on a Flame > > handset. > > Hi Benjamin, > > could you describe what output did you use? speaker or receiver? I tried both Speaker and Receiver while Speaker was slightly louder the difference was not much (not compared to other mobile platforms or even my expectations as a user) Receiver was the worst definitely
Flags: needinfo?(bkerensa)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Keywords: smoketest
Comment 49•10 years ago
|
||
For clarification, we are not seeing this issue to the same extent with the shallow flash as we are with the full flash. When using the full flash method we cannot hear either phone's audio and changes to the devices volume levels are not being reflected.
Comment 50•10 years ago
|
||
Not a smoketest blocker. This issue has been present for multiple months, which does not make this a blocker.
Keywords: smoketest
Updated•10 years ago
|
Updated•10 years ago
|
Whiteboard: [2.1-flame-test-run-2] → [2.1-flame-test-run-2][fullflash-smoketest]
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Updated•10 years ago
|
Flags: needinfo?(ktucker)
Comment 51•10 years ago
|
||
In case dupe bug 1055832 has been missed, I have the same issue (using a v2.0 build). While the volume is loud enough in a quiet room, it's not as soon as the environment is noisy (in a street, when there is some wind or passing cars). I didn't have this issue with other FxOS phones I used in the past.
Comment 52•10 years ago
|
||
Reviewed in triage - regression, and maybe uncovering issues with full vs shallow flash, so blocking+.
blocking-b2g: 2.1? → 2.1+
Assignee | ||
Comment 53•10 years ago
|
||
(In reply to Dietrich Ayala (:dietrich) from comment #52) > Reviewed in triage - regression, and maybe uncovering issues with full vs > shallow flash, so blocking+. Dietrich, while I agree with you, I could not find from where this discrepency comes from. My latest tries in comment 43 suggests it is not related to the /system/lib/ we are building.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → lissyx+mozillians
Assignee | ||
Comment 54•10 years ago
|
||
Maybe related to bug 1068587.
Assignee | ||
Comment 55•10 years ago
|
||
Current status when volume buttons looks to be ineffective: - dialpad tones - in call without speaker mode - in call with speaker mode
Assignee | ||
Comment 56•10 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #55) > Current status when volume buttons looks to be ineffective: > - dialpad tones > - in call without speaker mode > - in call with speaker mode Pushing those files: > adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb > adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb > adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb > adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb > adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb > adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb > adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb does not improve the situation
Assignee | ||
Comment 57•10 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #55) > Current status when volume buttons looks to be ineffective: > - dialpad tones > - in call without speaker mode > - in call with speaker mode Puhsing: > adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/ does not improve the situation
Assignee | ||
Comment 58•10 years ago
|
||
(In reply to Alexandre LISSY :gerard-majax from comment #55) > Current status when volume buttons looks to be ineffective: > - dialpad tones > - in call without speaker mode > - in call with speaker mode Pushing both: > adb push backup-flame/system/etc/snd_soc_msm/ /system/etc/snd_soc_msm/ + > adb push backup-flame/system/etc/Bluetooth_cal.acdb /system/etc/Bluetooth_cal.acdb > adb push backup-flame/system/etc/General_cal.acdb /system/etc/General_cal.acdb > adb push backup-flame/system/etc/Global_cal.acdb /system/etc/Global_cal.acdb > adb push backup-flame/system/etc/Handset_cal.acdb /system/etc/Handset_cal.acdb > adb push backup-flame/system/etc/Hdmi_cal.acdb /system/etc/Hdmi_cal.acdb > adb push backup-flame/system/etc/Headset_cal.acdb /system/etc/Headset_cal.acdb > adb push backup-flame/system/etc/Speaker_cal.acdb /system/etc/Speaker_cal.acdb I get this situation: - volume change can be heard in call, with and without speaker mode.
Assignee | ||
Comment 59•10 years ago
|
||
Michael, please find attached a PR that fixes the issue for JB images.
Attachment #8490756 -
Flags: review?(mwu)
Comment 60•10 years ago
|
||
Note - we're going to need a patch here for KK too, as our one-off fullflash smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well.
Assignee | ||
Comment 61•10 years ago
|
||
(In reply to Jason Smith [:jsmith] from comment #60) > Note - we're going to need a patch here for KK too, as our one-off fullflash > smoketest of Flame KK showed that this is happening on Flame KK 2.1 as well. Thanks for bringing this: I could not find any trace of those files on my KK backup-flame (made out of v166 base image), so I assumed this one was not faulty. I'll check the status on Kitkat then.
Comment 62•10 years ago
|
||
I can confirm that the files from comment 58 fixed the issue for me (jb build).
Assignee | ||
Comment 63•10 years ago
|
||
On kitkat, having pulled files from v166 base image I see that they are now within /system/etc/acdbdata/
Assignee | ||
Comment 64•10 years ago
|
||
Path have changed a bit, and it seems we do not have any snd_soc_msm on KK. As far as I could test, it fixes the issue on KK as well this way.
Attachment #8491515 -
Flags: review?(mwu)
Updated•10 years ago
|
Attachment #8491515 -
Flags: review?(mwu) → review+
Comment 65•10 years ago
|
||
Comment on attachment 8490756 [details] [review] JB Device PR Review comment on PR.
Attachment #8490756 -
Flags: review?(mwu)
Assignee | ||
Comment 66•10 years ago
|
||
(In reply to Michael Wu [:mwu] from comment #65) > Comment on attachment 8490756 [details] [review] > JB Device PR > > Review comment on PR. Thanks, I just replied :)
Flags: needinfo?(mwu)
Comment 67•10 years ago
|
||
Do these files live in our code or do we need new base images from partner to fix this for our contributors who don't compile themselves?
Comment 68•10 years ago
|
||
The base images are fine. The issue is that we don't properly reuse the files from the backup-flame directory (pulled from a device flashed with a base image) when we generate our own images.
Assignee | ||
Comment 69•10 years ago
|
||
Merged for kitkat: https://github.com/mozilla-b2g/device-flame/commit/960533f716ce31dfad357e87fa2f1d9ee5e94674
Assignee | ||
Comment 70•10 years ago
|
||
Comment on attachment 8490756 [details] [review] JB Device PR Updated PR: after discussing with mwu, let's use from repo.
Attachment #8490756 -
Flags: review?(mwu)
Updated•10 years ago
|
Attachment #8490756 -
Flags: review?(mwu) → review+
Flags: needinfo?(mwu)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(vchen)
Assignee | ||
Comment 71•10 years ago
|
||
https://github.com/mozilla-b2g/device-flame/commit/b04c1a7d96f01a743f23a544870cd5be2c8d172e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 72•10 years ago
|
||
Does this need approval requests for branches still?
status-b2g-v2.2:
--- → fixed
Flags: needinfo?(lissyx+mozillians)
Target Milestone: --- → 2.1 S5 (26sep)
Assignee | ||
Comment 73•10 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #72) > Does this need approval requests for branches still? I'm not sure, it's already on the proper branches.
Flags: needinfo?(lissyx+mozillians)
Comment 74•10 years ago
|
||
please full flash a KK tinderbox 2.1 build and verify its fixed on 2.1 branch. thanks.
Keywords: verifyme
Comment 75•10 years ago
|
||
I tested this on Flame 2.1 and Flame 2.2 Full Flash with the KK Base. On both branches, the volume seemed to work properly across the following areas of the device: -Ringtone volume when receiving a call could be set appropriately loud and quiet. -In-Call volume could be set appropriately loud and quiet. -Dialer Touch Tone Keypad tones could be set appropriately loud and quiet (note, this required the user to change the Media volume, which must be done outside the Dialer app). -Radio media volume could be set appropriately loud and quiet. -YouTube media volume could be set appropriately loud and quiet (the volume range seemed a bit small when listening with headphones, but was still good when using the system speaker). -Alarm volume could be set appropriately loud and quiet. Environmental Variables: Device: Flame 2.1 BuildID: 20140923003005 Gaia: 3a2947df41a480de1457a6dcdbf46ad0af70d8e0 Gecko: df42b05782aa Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.2 (Master) BuildID: 20140922193018 Gaia: fe92ddd450e03b38edb2d465de7897971d68ac68 Gecko: 790f41c631cc Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(pbylenga)
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(pbylenga)
Keywords: verifyme
You need to log in
before you can comment on or make changes to this bug.
Description
•