1033983 - [WIFI] Fewer available wifi networks are found after upgrade

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Wifi, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Two days ago I got my Flame device with Fx OS 1.3 preinstalled. All was fine. So today I upgraded to the latest aurora build (2-0.0.0-prerelease) from 20140703000248.

After the reboot I'm no longer able to access my Wifi networks because none are shown in the list of available networks. This is a regression between 1.3 and 2.0. I haven't tested it with 1.4 yet. So not sure if this version is also affected.

I tried to grab some details from the console via adb logcat, but nothing is shown there.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is an really annoying problem with the 2.0 version of Firefox OS. If I'm not able to connect to a WIFI network, I cannot really participate in the dogfooding program here, given that I cannot download the updates via the mobile connection. And having to flash the phone each day I also don't consider a good option.

The question here is what has been changed since version 1.x that the device is no longer able to detect any Wifi network? When I got it with version 1.3 all was working fine. We should consider this as blocker and investigate it appropriately. Sadly I don't see which flags I have to set to make it tracking for 2.0. Anyone who can help?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Reopening bug given that it is still not fixed. Bug 1026730 seems to have only taken care of those wifi networks the user was connected to while running version 1.4. So flashing a v2 over it, will keep it intact. But all the other available wifi networks are still not listed. So you can only connect to the already connected ones.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is indeed a regression between v1.4 and v2.0.

Comment 5

[Jason Smith [:jsmith]]

So typically we'll only do windows on blocking issues, given that doing windows on Firefox OS is expensive to conduct. Do you think this is a blocking issue?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I assume that when you get a new phone with Firefox OS 2.0 installed, and you will not be able to join any WIFI network because none are found, I certainly think this is a blocker. If that qualifies for a regression windows check you will have to decide. Another option could be to ask appropriate devs who should know about any changes in that area. Lets CC some from bug 1026730.

Comment 7

[Jason Smith [:jsmith]]

Okay, then can you nominate the bug to block the release (i.e. set the blocking-b2g flag to 2.0?)?

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Attachment: adb logcat

logcat output with wlan info enabled. Looks like we find other networks but something prevents us from showing them.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

[Blocking Requested - why for this release]:

Comment 10

[Joshua Mitchell (Inactive)]

Henrik - can I ask you to clarify something? In comment 0 you state you 'upgraded' from 1.3 to 2.0   Did you use the OTA process (over-the-air 'check for updates') or did you flash 2.0 on top of your 1.3?

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I didn't run OTA but upgraded via the flash tool (https://github.com/Mozilla-TWQA/B2G-flash-tool).

After I borked my phone lately with a broken build, I reflashed it today with an OEM build as instructed in the intranet wiki. Afterward I used the above mentioned flash tool to put the latest gaia+gecko version on it.

Comment 12

[Joshua Mitchell (Inactive)]

OK - using that process I am not able to reproduce so we will need to work to get some specific steps to reproduce.

What I did - 

1) Installed the base image (1.3) version 122
2) Went through FTU connecting to Wi-Fi
3) Arrived on home-screen
4) Flashed the latest 2.0 on top
-------------------------------------------------------------------------------
Device: Flame 2.0
Build ID: 20140805064652
Gaia: 84af4f7a84d449165a2618fd5cfe4431bf156bfe
Gecko: 712836e6770a
Version: 32.0 (2.0)
Firmware Version: v122
------------------------------------------------------------------------------
5) Proceeded to the Network Connection screen of the FTU

there I was able to see all the normally available networks and connect to my normal network.

so currently we are not able to repro - is there anything here that looks out-of-the-ordinary or wrong?
This might come down to the difference between a simple setting that you might do.

Comment 13

[Joshua Mitchell (Inactive)]

annnnd.... I was just being dumb. 

I overlooked the 'after a reboot' - and actually all it took was my phone going to sleep and unlocking it at which point the only network I could see was the one I had connected to - as discussed in comment 3.


So now we have a repro - I'm going to do a bit more investigating and then start on the window.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Great to see that you can repro. So I assume that I don't have to give any answer to the questions above. Thanks Joshua for willing to run the regression window test!

Comment 15

[Vincent Chang[:vchang][changyihsin]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #13)
> annnnd.... I was just being dumb. 
> 
> I overlooked the 'after a reboot' - and actually all it took was my phone
> going to sleep and unlocking it at which point the only network I could see
> was the one I had connected to - as discussed in comment 3.
> 
> 
> So now we have a repro - I'm going to do a bit more investigating and then
> start on the window.

In your description here, it seems that your device still can find the AP. Just not all of APs in the coverange area are scanned and listed in available networks. If this is the case, we need a new DOM API to fix it which is filed in Bug 1011358. You should be able to scan others network if you press search again button several times. 

BTW, I just flash my flame using the flash tool and wifi works fine. I can scan/list/connect to network normally. 

./flash_pvt.py -w 
Branch: b2g32_v2_0
Build Type: Engineer 
Gecko/Gaia/Full: images

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So do we cache found but not connected networks? If that is the case it might be that all those cached networks are not visible. I can tap on search a couple of times but that doesn't show me any of those.

Today I'm working from another place so I changed my WIFI environment. When I now search for networks, I get networks listed. None of those were cached before or queried with v1.4.

Could it be that only the cached networks as done with v1.4, are not visible in v2.0?

Comment 17

[Joshua Mitchell (Inactive)]

B2G Inbound Regression Window:

Last Working:
Device: Flame Master
Build ID: 20140430163002
Gaia: 8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko: b227a707080f
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First Broken:
Device: Flame Master
Build ID: 20140501103002
Gaia: f98b024ffd52b55ea3fa18ece0ed8742d970d4ef
Gecko: 35f9431188ca
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Last Working Gaia First Broken Gecko: Issue DOES reproduce
Gaia: 8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko: 35f9431188ca

First Broken Gaia Last Working Gecko: Issue does not reproduce
Gaia: f98b024ffd52b55ea3fa18ece0ed8742d970d4ef
Gecko: b227a707080f

Gecko pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b227a707080f&tochange=35f9431188ca



B2G Inbound Regression Window:

Last Working:
Device: Flame Master
Build ID: 20140430143002
Gaia: ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634
Gecko: 3be37517e259
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

First Broken:
Device: Flame Master
Build ID: 20140430173007
Gaia: b4f9c9e92a8064084a2b73d8f474dddecac81783
Gecko: aed338f33904
Version: 32.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Last Working Gaia First Broken Gecko: Issue DOES reproduce
Gaia: ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634
Gecko: aed338f33904

First Broken Gaia Last Working Gecko: Issue does NOT reproduce
Gaia: b4f9c9e92a8064084a2b73d8f474dddecac81783
Gecko: 3be37517e259

Gecko pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=3be37517e259&tochange=aed338f33904

Comment 18

[Joshua Mitchell (Inactive)]

Sorry - the top window is a Mozilla Central window - and then it reduces to the b2g inbound for the 2nd window.


Vincent - could this have been broken by bug 996558 ?

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Joshua Mitchell [:Joshua_M] from comment #18)
> Vincent - could this have been broken by bug 996558 ?

Great catch Joshua!! But I think you mean bug 996588, which really looks like to be the regressor. Lets see what Vincent says.

Comment 20

[Joshua Mitchell (Inactive)]

Indeed I did, thanks for the mistake-catch and correction!

Comment 22

[Henry Chang [:hchang]]

> BTW, I just flash my flame using the flash tool and wifi works fine. I can
> scan/list/connect to network normally. 
> 
> ./flash_pvt.py -w 
> Branch: b2g32_v2_0
> Build Type: Engineer 
> Gecko/Gaia/Full: images

Same here:

1) Flash back to v122 that I downloaded from our NAS server (Foxfone-One_v122.zip)
2) Connect to certain wifi network through FTU
3) Use https://github.com/Mozilla-TWQA/B2G-flash-tool to flash to
   - flame => mozilla-b2g32_v2_0 => Engineer => gaia + gecko
4) Reboot

Everything is fine except the network I connected in step 2) is forgotten.

So are you still not able see any other network by a forced scan?
Also, if anyone could attach a log with wifi debug info that would be much helpful.

Comment 23

[Vincent Chang[:vchang][changyihsin]]

[Blocking Requested - why for this release]:

I don't think this is related to bug 996588, and scan list should get up to date AP lists in the coverage area rather than from the cache. 

I use flash pvt tool and update flame to aurora. I find that wifi is unable to scan any APs as described in comment 1. It turns out that the patch in Bug 1025034 is not uplift to aurora pvt build yet. Becuase this problem only happens in aurora, I don't think it should be a 2.0 blocker.    

./flash_pvt.py -w 
Branch: aurora 
Build Type: Engineer 
Gecko/Gaia/Full: images

Comment 24

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Henry Chang [:henry] from comment #22)
> So are you still not able see any other network by a forced scan?

Not if I do a single forced scan. I had to tap about 6 times on repeat search to be able to see other WIFI networks!! Why aren't those shown with a single tap? Further after the phone fall into sleep mode, all the lately found WIFI networks are gone again.

(In reply to Vincent Chang[:vchang] from comment #23)
> to scan any APs as described in comment 1. It turns out that the patch in
> Bug 1025034 is not uplift to aurora pvt build yet. Becuase this problem only
> happens in aurora, I don't think it should be a 2.0 blocker.    

So what's bug 1025034 comment 19 ("v2.0: https://github.com/mozilla-b2g/device-flame/commit/e67827b94d0e5d2fadcacc6049262679c02eec30") telling us then? Is v2.0 something else? Is PVT specific for our testing and won't it reach end-users? Shall we request landing it for v2.0 PVT? I'm a bit confused now.

Comment 25

[bhavana bajaj [:bajaj]]

(In reply to Vincent Chang[:vchang] from comment #15)
> (In reply to Joshua Mitchell [:Joshua_M] from comment #13)
> > annnnd.... I was just being dumb. 
> > 
> > I overlooked the 'after a reboot' - and actually all it took was my phone
> > going to sleep and unlocking it at which point the only network I could see
> > was the one I had connected to - as discussed in comment 3.
> > 
> > 
> > So now we have a repro - I'm going to do a bit more investigating and then
> > start on the window.
> 
> In your description here, it seems that your device still can find the AP.
> Just not all of APs in the coverange area are scanned and listed in
> available networks. If this is the case, we need a new DOM API to fix it
> which is filed in Bug 1011358. You should be able to scan others network if
> you press search again button several times. 
> 
> BTW, I just flash my flame using the flash tool and wifi works fine. I can
> scan/list/connect to network normally. 
> 
> ./flash_pvt.py -w 
> Branch: b2g32_v2_0
> Build Type: Engineer 
> Gecko/Gaia/Full: images

Hey vincent given this is regression and all of those patches are in 2.0 this would be blocking. Reaching out to you offline on how you are testing.

Comment 26

[Vincent Chang[:vchang][changyihsin]]

> > BTW, I just flash my flame using the flash tool and wifi works fine. I can
> > scan/list/connect to network normally. 
> > 
> > ./flash_pvt.py -w 
> > Branch: b2g32_v2_0
> > Build Type: Engineer 
> > Gecko/Gaia/Full: images
> 
> Hey vincent given this is regression and all of those patches are in 2.0
> this would be blocking. Reaching out to you offline on how you are testing.

There are two problems, 
1. If the problem is "Cannot find any available wifi networks", 
This problem happens in "aurora" pvt build. It's not happened in "2.0" pvt build. The root cause for this problem is related to wifi driver as I mentioned in comment 23.

In file https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame/latest/sources.xml

The commit of "device-flame" needs to be updated to e67827b94d0e5d2fadcacc6049262679c02eec30 
<project name="device-flame" path="device/t2m/flame" remote="b2g" revision="897b4d8aa61b48208e3aa16171eef672895d3b11"/>  

2. If the problems is "You can find some available wifi networks but some of them are lost", 
In this case, wifi works normally, you can scan/connect/forget to the APs. But some APs may take couple of scans to show up. It should be Bug 1011358.

Comment 27

[Vincent Chang[:vchang][changyihsin]]

Hi Henrik and Joshua, can you help to confirm that the problem you are encountered is problem 1, problem 2 or others ? If it is problem 1, I think we should mark this as won't fix, if it is problem 2, we would like to fix it in bug 1011358 and this should not be a 2.0+ blocker.

Comment 28

[Henrik Skupin [:whimboo][⌚️UTC+2]]

As mentioned above I can find networks when tapping multiple times on search. After sleep those are lost again, so I have to tap multiple times again. I assume it's problem 2 then?

Comment 29

[Joshua Mitchell (Inactive)]

If I recall I saw a variety of case 1 and 2 - but I was also all over the place (aurora folder for branch checks, PVT Master branch for the regression window). Henrik is the bug reporter so I think we should focus on his answer in comment 28.

Comment 30

[howie [:howie]]

Removing blocker based on Comment 27 and 28. let's keep moving bug 1011358 forward. Thanks.

Comment 31

[Henry Chang [:hchang]]

I need some information to conclude this bug:

1) Henrik, are you able to reproduce the issue "cannot find any available" 
   by following the steps I mentioned in comment 22?

2) Joshua, in comment 12, how do you flash 2.0 at step (4)? (for example,
   using QA flash tool, select flame ==> mozilla-central ==> gaia+gecko)
   Besides, what issue did you target to find the regeression window? 
   "cannot find any available network" or "cannot find ALL available network"

Thanks!

Comment 32

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Henry Chang [:henry] from comment #31)
> 1) Henrik, are you able to reproduce the issue "cannot find any available" 
>    by following the steps I mentioned in comment 22?

Those are the steps, right. But I can still see the formerly connected wifi network when I was running v1.23. What I do not see are all the other wifi networks. Even tapping multiple times on 'Search Again' doesn't reveal those. Well, sometimes I might be lucky and see them. But they are forgotten again after a while.

Comment 33

[Henry Chang [:hchang]]

(In reply to Henrik Skupin (:whimboo) [away 08/16 - 08/23] from comment #32)
> (In reply to Henry Chang [:henry] from comment #31)
> > 1) Henrik, are you able to reproduce the issue "cannot find any available" 
> >    by following the steps I mentioned in comment 22?
> 
> Those are the steps, right. But I can still see the formerly connected wifi
> network when I was running v1.23. What I do not see are all the other wifi
> networks. 

Hmmm, having tried more times and still didn't reproduce...

One weird thing, the connected network will be always forgotten
after flashing "gecko and gaia ONLY". I couldn't figure out
why you can still connect to any network after flashing...

Comment 34

[Joshua Mitchell (Inactive)]

(In reply to Henry Chang [:henry] from comment #31)
> I need some information to conclude this bug:

> 2) Joshua, in comment 12, how do you flash 2.0 at step (4)? (for example,
>    using QA flash tool, select flame ==> mozilla-central ==> gaia+gecko)
>    Besides, what issue did you target to find the regeression window? 
>    "cannot find any available network" or "cannot find ALL available network"

I use flash.gg script to flash a Tinderbox-Eng build (usually Mozilla-Central-Flame-Eng). 

The regression window was found with the 'cannot find all available networks' - Most of the time it would only find the first 3 or 4 in the list (alphabetically) - sometimes it would only find the 1 network that I would typically connect to. For the 'working' aspect of the window I would always see 20-30 networks available.

Comment 35

[Jason Smith [:jsmith]]

Hi Everyone,

Let's focus the scope of this bug on what regressed here. I think we might be jumping too quickly to what the root cause is without digging into why bug 996588 was called out as the regressing cause, so let's backup here to find out why that was determined here. A starting point we could do for the investigation is try backing out that patch and seeing if someone can reproduce can reproduce with the backout, as that will confirm that bug 996588 is the cause. If that's firmly proven, then we should look into what changed here to cause a regressing behavior to be observed.

From my perspective, the focus of this bug should be analyzing why we are failing to find some SSIDs when doing a search for networks. That means we shouldn't be focusing on the build concerns here, as this has been proven to reproduce on a 2.0 partner branch build. We also shouldn't be focusing on bug 1011358, as this bug deals with failing to find existing SSIDs on the network, not a new SSID that came online.

Comment 36

[Henry Chang [:hchang]]

(In reply to  Mitchell [:Joshua_M] from comment #34)
> (In reply to Henry Chang [:henry] from comment #31)
> > I need some information to conclude this bug:
> 
> > 2) Joshua, in comment 12, how do you flash 2.0 at step (4)? (for example,
> >    using QA flash tool, select flame ==> mozilla-central ==> gaia+gecko)
> >    Besides, what issue did you target to find the regeression window? 
> >    "cannot find any available network" or "cannot find ALL available network"
> 
> I use flash.gg script to flash a Tinderbox-Eng build (usually
> Mozilla-Central-Flame-Eng). 
> 
> The regression window was found with the 'cannot find all available
> networks' - Most of the time it would only find the first 3 or 4 in the list
> (alphabetically) - sometimes it would only find the 1 network that I would
> typically connect to. For the 'working' aspect of the window I would always
> see 20-30 networks available.

Hi Joshua,

Thanks! I'll try the window you found regarding the issue 
'cannot find all available networks'

(In reply to Jason Smith [:jsmith] from comment #35)
> Hi Everyone,
> 
> Let's focus the scope of this bug on what regressed here. I think we might
> be jumping too quickly to what the root cause is without digging into why
> bug 996588 was called out as the regressing cause, so let's backup here to
> find out why that was determined here. A starting point we could do for the
> investigation is try backing out that patch and seeing if someone can
> reproduce can reproduce with the backout, as that will confirm that bug
> 996588 is the cause. If that's firmly proven, then we should look into what
> changed here to cause a regressing behavior to be observed.
> 

Will check on my side, too.

> From my perspective, the focus of this bug should be analyzing why we are
> failing to find some SSIDs when doing a search for networks. That means we
> shouldn't be focusing on the build concerns here, as this has been proven to
> reproduce on a 2.0 partner branch build. We also shouldn't be focusing on
> bug 1011358, as this bug deals with failing to find existing SSIDs on the
> network, not a new SSID that came online.

Even though the title of Bug 1011358 is about "new SSIDs that came online",
but looking at the STR:

STR: (seems limited to our current setup)
1. Flash with the latest master Flame or Hamachi build
2. In the Mountain View QA lab, enable Wi-Fi through the UI, on-device
3. Look for the presence of the "ateam" SSID

The STR seems to have nothing to do with "new SSID", doesn't it?

Anyways, let me check the regression window and update here later!

Thanks!

Comment 37

[Henry Chang [:hchang]]

Attachment: scan result

According to the scan result, the patch for Bug 996588 would convert the escaped '\x00' to '\0' so that the subsequent result is truncated.

Comment 38

[Henry Chang [:hchang]]

Attachment: Bug1033983.patch

Comment 39

[Henry Chang [:hchang]]

Comment on attachment 8472856 [details] [diff] [review]
Bug1033983.patch

Chuck, this patch modify |LossyConvertUTF8toUTF16| to bypass the leading null character if it's not the last one. We can do similar things in |convertToBytes| but the presence of null char is meaningful to |convertToBytes| because the outcome is "bytes" but not "null-terminated string". As a result, I ended up deciding to work around LossyConvertUTF8toUTF16 since it's "lossy" by nature.

I was trying to find a non-null-terminated string type in gecko. String in javascript is not null termianted. So, if we can use a non-null-termianted string container then the issue could be solved gracefully. However, I failed to find that kind of string in gecko...

Comment 40

[howie [:howie]]

After offline discussion and all the clarification above, blocking this and changing the title to fit the actual problem.

Comment 41

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Comment on attachment 8472856 [details] [diff] [review]
Bug1033983.patch

Review of attachment 8472856 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thank you!

::: dom/wifi/WifiUtils.cpp
@@ +168,5 @@
>    size_t srclen = src.length();
>    uint32_t j = 0;
>    for (uint32_t i = 0; i < srclen; i++, j++) {
>      uint32_t v = uint32_t(src[i]);
> +    if (v == '\0' && i < srclen - 1) {

I think we can cast '\0' to uint32_t here to get ride of compiler warning.

@@ +172,5 @@
> +    if (v == '\0' && i < srclen - 1) {
> +      // If the leading byte is '\0' and it's not the last byte,
> +      // just ignore it to prevent from being truncated. This could
> +      // be caused by |convertToBytes| (e.g. \x00 would be converted to '\0')
> +      j--;

I think we can add |continue;| here to make the exception more clear, and get ride of the |else if| below.

Comment 42

[Henry Chang [:hchang]]

Thanks for the review reminding the warning!

(In reply to Chuck Lee [:chucklee] from comment #41)
> Comment on attachment 8472856 [details] [diff] [review]
> Bug1033983.patch
> 
> Review of attachment 8472856 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good, thank you!
> 
> ::: dom/wifi/WifiUtils.cpp
> @@ +168,5 @@
> >    size_t srclen = src.length();
> >    uint32_t j = 0;
> >    for (uint32_t i = 0; i < srclen; i++, j++) {
> >      uint32_t v = uint32_t(src[i]);
> > +    if (v == '\0' && i < srclen - 1) {
> 
> I think we can cast '\0' to uint32_t here to get ride of compiler warning.
> 
> @@ +172,5 @@
> > +    if (v == '\0' && i < srclen - 1) {
> > +      // If the leading byte is '\0' and it's not the last byte,
> > +      // just ignore it to prevent from being truncated. This could
> > +      // be caused by |convertToBytes| (e.g. \x00 would be converted to '\0')
> > +      j--;
> 
> I think we can add |continue;| here to make the exception more clear, and
> get ride of the |else if| below.

Comment 43

[Henry Chang [:hchang]]

Attachment: Patch V2 (r+'d)

Comment 44

[Ryan VanderMeulen [:RyanVM]]

Do you have a recent Try link for this, Henry? :)

Comment 45

[Henry Chang [:hchang]]

> Do you have a recent Try link for this, Henry? :)

The try result:

https://tbpl.mozilla.org/?tree=Try&rev=1f9123834dd5

Thanks!

Comment 46

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/3ed68f04121a

Comment 47

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3ed68f04121a

Comment 48

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/7194d5ddc5e6

Comment 49

[Henrik Skupin [:whimboo][⌚️UTC+2]]

All works fine now for version 2.0. Thanks for fixing it!

Verified on my Flame device with:
Gaia      a51633e29a7826b6bf07cb1c5ad81b3217b9820a
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/fdac649a65ac
BuildID   20140826000204
Version   32.0