React-native: response.json() hangs when chrome debugging

[NgoKnows]

When using fetch to make a get to an external api, and if debugging in chrome is active, then it never reaches the second "then" until there is an interaction with the UI, such as a tap on the screen, but if debugging is turned off then this problem goes away.

fetch(requestURL)
    .then((res) => res.json())
    .then((resData) => {
        this.setState({
            suggestions: resData.Similar.Results
        });
    })
    .done()

Using React Native 0.22
Only occurs on Android (both Genymotion and on device (5.0))
Using a Mac

[satya164]

cc @martinbigio we were talking about this

Do sourcemaps in redbox work for you on Android when you're connected to the debugger?

[NgoKnows]

Now that you mention it, nope, sourcemaps in redbox are not working when connected to the debugger.

[mark0978]

Got the same problem on linux with the v0.22 as well. Interacting with the debug menu breaks the logjam.

For me, sourcemaps stop working after a while and I start seeing the transpiled code. That is happening when this error is occurring. But the problem also happens after a reboot before the sourcemaps stop working.

From Stackoverflow: http://stackoverflow.com/questions/36262456/what-could-be-causing-this-slow-fetch-in-react-native

In the following code, the first console.log message prints pretty much instantly. Then everything just hangs (I'm initially assumed it was waiting for the body of the response to be returned). The Body of the response is only about 26K, the time waiting seems to be indefinite UNLESS, I shake the phone and interact with the debug menu. * As soon as I interact with the debug menu, the promise resolves and everything moves along as expected.* My interactions with the debug menu can be simple, like hide inspector, show inspector, just takes something to kick the promise resolution into gear and everything is fine.

    fetch(SEARCH_URL, requestBody)
        .then((response) => {console.log(response); return response.json();})
        .then((responseData) => {
            debugger
            ...

Note:
Disconnecting from the debugger and running the code does not exhibit the slowness (and not being connected to the debugger ignores the debugger statements)

And yes, I have rebooted the computer.

[martinbigio]

@steveluscher you were looking into setTimeout issues. Could this be related?

@cpojer, @skevy have we recently made any change to the Promise implementation?

cc @bestander, @vjeux

[steveluscher]

I've been seeing ‘setTimeout never fires’ behavior intermittently as well, with timeouts > 0ms. The only clue that I had was that my Genymotion simulator clock and my system clock seem to drift apart over time. I didn't try opening the debug menu when stuck, nor have I noticed this on device yet (I haven't done anything on device in a while). That you've experienced the same behavior on device as you have in Genymotion makes me think it's not going to prove to be clock drift between the host running Chrome and the host running the app.

[mark0978]

Takes more than opening the menu, you have to choose something from it, like hide/show inspector. I'm not using a simulator.

[mj1618]

I'm having the same issue on an S4 mini, except I can stop the behaviour by tapping the screen without opening the debug menu.

[sbekrin]

Got same issue with response.text(), response.json() and response.arrayBuffer(), but response.blob() seems to work fine. Versions are:

react-native-cli: 0.2.0
react-native: 0.22.2
Android 5.1.1

Quick workaround is to add empty timeout execution:

fetch('http://example.com')
    .then(response => {
        setTimeout(() => null, 0);
        return response.text();
    })
    .then(response => {
        console.log(response);
    });

[mark0978]

I can confirm just tapping anywhere on the screen does work around this problem.

[martinbigio]

Do we know when this regression started repro-ing? Do you guys mind sharing which version of react-native you're using? I want to make sure this is not a regression of the current RC.

cc @bestander

[mark0978]

It was in a version installed from npm on March 24. I don't know the version at the moment, but I can look it up tonight.

[thorbenandresen]

I have the same problem with 0.22 and iOS on my mac (installed 1 hour ago).

Tapping anywhere + the setTimeOut workaround does not work for me.

[martinbigio]

So this may have been introduced on 0.22, so not 0.23 launch blocker though we should fix asap.

[davidaurelio]

This is due to our incomplete XHR2 implementation. Check this code that was added with cbc0e21926594cbe650db34c466b934fda5c13ef.

Please consult the spec before fixing stuff.

[thorbenandresen]

Should this be fixed in 0.24? The problem persists for me with 0.24

[bestander]

No, this is in 0.25-rc

[thorbenandresen]

Is it fixed in v0.25.0-rc? Because it persists there as well...

[bestander]

Actually the commit is supposed to be in 0.24.1, it has been cherry-picked into the branch https://github.com/facebook/react-native/commits/0.24-stable.
If you still reproduce the bug then the fix does not work.
cc @davidaurelio

[thorbenandresen]

yes - I still reproduce the error with 0.24.1 - Am I supposed to to do any changes to my code? I have not changed it since it broke around 0.22.

[jrichardlai]

It seems something is off with the sourcemap, the one from my bundle has multiple sections but it seems that when we parse it we expect to be flat https://github.com/facebook/react-native/blob/master/Libraries/JavaScriptAppEngine/Initialization/SourceMap.js#L1086
The sourcemap I get using the explorer is flat:

But the one I get from my project has sections:

The promise is rejected, it seems that SourceMap does not handle sections, I updated it and got the Stacktrace in the red screen working fine after commenting in parseErrorStack, but this didn't fixed the freezing issue of the Chrome Debugger.

// if (frame.file.indexOf(sourceMap.file) !== -1 ||
//     frame.file.replace('.map', '.bundle').indexOf(
//       sourceMap.file
//     ) !== -1) {
  resolveSourceMaps(sourceMap, frame);
// }

[davidaurelio]

@jrichardlai oh yes, that’s a super old version of the source map library. Using what we have in node_modules should do the trick. PR welcome. Will look into the other issue now.

[ericsanjaya]

i have same problem to, i use 0.25.1 and fetch problem not resolve for now. i think fetch is important part to use web service in mobile app and need to fix.
for now i just use version 0.19
my issue same with #7381

[florindobre]

Any update on this issue? Possible workarounds besides just tapping on the screen.

react-native-cli: 0.2.0
react-native: 0.25.1
Android: 5.1.1

[dattran92]

Looking for an update. I have upgraded to:

react-native-cli: 0.2.0
react-native: 0.26.0
The problem still occured.

[alexprice1]

Still on 0.27.0

[cablegunmaster]

Question do you have no cache headers? it might or might not be related.

https://github.com/facebook/react-native/issues/8152

[samuelpismel]

Still on 0.28

[1st8]

Still on 0.29.0-rc.0

[bestander]

Hey guys, thanks for pinging and sorry for taking so long.
Looks like it was an error in our fork of fetch polyfill

[bestander]

Will be fixed in 0.30

[bestander]

This got reverted before 0.30 branch cut.
It should be in 0.31 next week.
Can anyone verify if the fix worked?

[satya164]

@bestander should we cherry-pick this to 0.30? https://github.com/facebook/react-native/issues/8586

[bestander]

Considering that 0.30 is just days away from being called stable and that this bug is not very critical, I would just wait for 0.31.
Afterall fetch implementation git bumped from 0.x to 1.x

[thorbenandresen]

@bestander - I copied the the 0.30rc fetch llibrary into my 0.29 code and it worked fine for me.

[n7olkachev]

Still on 0.31

[pbrito]

I have this issue with 0.32.0-rc.0 but the
setTimeout(() => null, 0);
workaround works for me.

[pbrito]

I made some more tests.
When I disabled "dev mode" and remote debug, I don't notice the slow response any more, even without the setTimeout workaround.

[bestander]

0.31 and 0.32 should have latest fetch from whatwg-fetch npm package.
This sorted out the issue for me when I was testing it.
@pbrito, Could you create a sample github project to reproduce the issue with 0.32?

[winterbe]

@bestander I can confirm that the problem still exists in RN 0.31. A 50ms server request usually takes 800-2000ms until it's processed from RN with remote debugging enabled. The delay is gone when JS debugging is disabled.

I've also reseted packager et al but the problem still persists:

watchmen watch-del-all
rm -rf $TMPDIR/react-*
npm cache clean
rm -rf node_modules
npm install
node node_modules/react-native/local-cli/cli.js start --reset-cache

Edit: This workaround seems to work:

fetch(url).then(response => {
  setTimeout(() => null, 0);  // workaround for issue-6679
  return response.json();
})

[zackify]

Yes, it still happens in 0.31, can confirm too.

[bestander]

Thanks for providing more info.
I won't be able to look at this in the next few weeks but it will be on my list.
Feel free to help me out and find the reason

[bestander]

Maybe a patch to fetch.js that would add a setTimeout if you are chrome-debugging? :)

[thorbenandresen]

I had this problem again after I upgraded to 0.31 and I fixed it by using the Fetch.js from 0.30rc.

Here is the code I used to replace the code in Fetch.js (node_modules/react-native/Libraries/Fetch/Fetch.js)
https://gist.github.com/Thorbenandresen/d5a482863ccc0be5bfc0344340c12367

[saberking]

What solved it for me was making sure any async code is invoked from within a React Component. fetch doesnt seem to work if it is placed outside, and neither does setTimeout

[lacker]

Seems like this has been fixed now so I am closing this issue.

[atasmohammadi]

I still have same issue. not on iOS, but on android only ( remote debugging disabled. release build )

[cooperka]

@lacker I still experience this issue on both iOS and Android. Contrary to @ataomega and as described in the original issue, it's only a problem for me when remote debugging in Chrome. The setTimeout(() => null, 0); workaround still fixes it. I'm using latest react-native v0.39.0.

[atasmohammadi]

@cooperka
I mean the release build. remote debugging is disabled. Works perfect on iOS but on android in first 3-4 minutes its super slow. after few minutes it will work fast.

[cooperka]

@ataomega you may have a different issue than the one described here. This issue is specifically when chrome debugging.

[atasmohammadi]

Thanks for your reply. But chrome debugging is disabled. Its a release
build (dev === false)

On Tue, Dec 13, 2016, 8:17 PM Kevin Cooper [e-mail] wrote:

@ataomega https://github.com/ataomega you may have a different issue
than the one described here. This issue is specifically when chrome
debugging.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-266833532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AQD7QY4rNjngiNQTLRQ9l7GTp4WSOC0Pks5rHu9FgaJpZM4H5YHZ
.

[cooperka]

@ataomega Yes I understand :) Your issue is probably unrelated to this one. It seems very different from what people here are describing. I'm just letting you know.

[yanni4night]

Got the same issue with RN 0.35.0

[jeffmedl]

This issue still seems to be occurring in RN 0.36.1.

Confirmed it only happens when debugger is active, and it requires some kind of screen interaction (e.g. click) to get the fetch promise to resolve. The Fetch is originating outside a React component as others have mentioned, and the setTimeout workaround works.

[cooperka]

@lacker it seems pretty conclusive, could you re-open this issue please?

[lacker]

Hmmm when I read through it seems inconclusive. It seems like some people have gotten this fixed and some people have not. Maybe there is some way to make it more specific how to repro this? Like having a sample app with a specific set of repro steps that makes it happen?

[cooperka]

Hi @lacker, good suggestion. The duplicate issue here has a good explanation of the steps, and I've created a demo repo here that very simply shows the issue. It seems to come down to calling response.json(). Commenting out that single line makes the delay go away. Repro'd using React Native v0.39.2 with no extra dependencies.

[hakunin]

Just updated dependencies for my almost "hello world" app and I still get 6 seconds of lag for each request and I need to make 3 sequential ones when the app starts :(

[ncuillery]

I think I encountered the same issue using Firebase and redux-observable. I tried to add a timeout on a Firebase update:

function organizationCreateEpic($action) {
  return $action
    .ofType(UI_ORGANIZATION_CREATE_START)
    .mergeMap((action) => {
      return Observable.fromPromise(database.ref().update(action.payload))
        .timeout(3000, new Error('Timeout'))
        .map(organizationCreateActionCreator)
        .catch(err => {
          console.error('Error', err);
          return Observable.of(organizationCreateActionCreator(err));
        })
    });
}

The error on timeout is never thrown (I can repro a timeout by disabling the wifi on my laptop).

It happens only when debugging in Chrome. Like https://github.com/facebook/react-native/issues/6679#issuecomment-202853656 the timeout error is finally thrown when I tap anywhere after the duration (3 sec).

Pretty weird: it seems like there is a breaking point on the timeout duration:

• Below 1090ms, I always get the error (expected behaviour)
• Between 1090 and 1100ms, sometimes I get the error, sometimes not
• Above 1100ms, the timeout error is never thrown (until I tap the screen)

Please note that I don't use fetch at all. The issue seems more relative to the Promise implementation (database.ref().update(action.payload) returns a Promise).

react-native 0.39.2
firebase 3.6.3
rxjs 5.0.0-rc.1
redux-observable 0.12.2

[Crash--]

Add this issue with RN 0.39.2 on an Android device while remote debugging is on.

As @ncuillery said, I think it's more related to Promise implementation than fetch since I've lot of fetch requests working (and setTimeout() workaround is not working)

[dvisco]

@ataomega I'm seeing a similar issue and I'm having a tough time replicating it as well. 3-4 minutes for initial http request then snappy afterwards (occasionally). Only on Android release builds.

react-native: 0.35.0

EDIT

Turns out it was related to poor IPv6 connectivity and waiting to time out to switch to the IPv4 address. Should be smoother once okHttp implements Happy Eyeballs

[saberking]

@ncuillery Is organizationCreateEpic called from inside a react component? Doing this solved the issue for me

[ncuillery]

@saberking It can't call it directly, this definition of an epic is part of the redux-observable middleware included in the redux middleware chain.

[saberking]

@ncuillery in that case the best option is just to give up on chrome debug and use react-native log-android

[mikelambert]

While different from the issue described originally (slowness when the debugger is open), I also experienced the same problem @dvisco and @ataomega describe. Android release mode slowness, which is manifested as:

• Start a request. I have it retry if a timeout is hit, so it ends up retrying multiple times.
• There are a few independent pending requests to my server (www.dancedeets.com).
• Eventually this server resolves/connects, and all pending requests are sent out simultaneously (as judged by the Server's Date header that responds to them)

I am unclear what is causing the pending requests to be delayed. A few observations:

• If I jump off my local wifi where this issue is 100% reproducible, the tethering to my cell network correctly allows the requests to be sent and processed immediately.
• I removed all the ipv6 AAAA records for my server, leaving just the ipv4 A records, but noticed no change in behavior. Still broken.
• The delays only seem to occur for http://www.dancedeets.com. Somehow https://codepush.azurewebsites.net and https://usage.trackjs.com both work fine (maybe https vs http? or maybe something specific to my server dns settings? my www.dancedeets.com server is GAE/GCE configured exactly as Google suggests).
• This only occurs for my Android RN build. Android web browser and iOS RN work fine, in the exact same conditions.

[sibelius]

The following code is very slow on ios with chrome debug

const response = await fetch('http://example.com')
const data = await response.json();

it takes almost 60 seconds to convert the response to json

this is happening on react native 39

[saberking]

@sibelius place that code inside a component eg. in the constructor , then it should work

[sibelius]

this function is called inside a component, isn't that the same?

[saberking]

@sibelius in that case it is something else, sorry i can't help!

[sibelius]

chrome version Version 55.0.2883.95 (64-bit)

[mark0978]

It might be the size of your payload, or, it might be the XHR isn't
completing due to a bug that has been around way longer than expected. Try
causing a touch event while you are waiting and you might find it completes
very quickly.

On Tue, Jan 24, 2017 at 8:44 AM, Sibelius Seraphini <
[email protected]> wrote:

chrome version Version 55.0.2883.95 (64-bit)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-274805644,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGept6L2vR1WgUKLXNUCrMvonD7iTw_ks5rVgAlgaJpZM4H5YHZ
.

[sibelius]

yep, doing a touch event makes it very fast

any reason for a touch fix the issue?

[mark0978]

Has something to do with Promise resolution not being checked until an
event loop action. I found this workaround, reported the bug and left it.
I was only working on a spike and my time was limited.

On Wed, Jan 25, 2017 at 8:53 AM, Sibelius Seraphini <
[email protected]> wrote:

yep, doing a touch event makes it very fast

any reason for a touch fix the issue?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-275112867,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGepmHrWMXuOqdlVCPupl-A7OpDooMaks5rV1P0gaJpZM4H5YHZ
.

[sibelius]

is there any issue open for this already?

[mark0978]

I think so, but it is about xhr promise resolution instead of json parsing.

On Wed, Jan 25, 2017 at 10:09 AM, Sibelius Seraphini <
[email protected]> wrote:

is there any issue open for this already?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-275132398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGeppAQwN0Ke2NdO9GXCeqAiHM1uAw6ks5rV2W2gaJpZM4H5YHZ
.

[sibelius]

@ghost could u please reopen this?, as this is still happening on RN39

[grubstarstar]

Still happening for me in 3.10.6

[JasonHenson]

this has always happened for me -- I just click the screen over and over.

[sibelius]

it happens on RN41 as well

[alexanderlamb]

@mikelambert I'm seeing something very similar.

1. Android RN build on device. Everything is operating normally.
2. Quickly disable and then re-enable wifi connection on the device.
3. For the next 3-4 minutes all requests from Android RN app will timeout. I'm watching device network traffic with a proxy and can see other network requests going through successfully from the device. Web browser, email etc.
4. After ~3-4 all pending requests from Android RN app will be sent. Even the ones that were reported as having timed out.
5. Once pending requests are sent everything is back to normal.

[sebandres]

still going in 0.42.0

This workaround still works:

fetch(url).then(response => {
  setTimeout(() => null, 0);  // workaround for issue-6679
  return response.json();
})

[JasonHenson]

Lol, it actually works -- wish I knew that long ago so many clicks so many clicks...

[Jacse]

I think this issue should be re-opened as it hasn't been resolved.

[SteveIb]

I have the same problem, I send image to my server processed there then send back image as json object.
There is no problem if the size of json object is small, but when my json object is 1,118 kb my app hangs, dunno if this can help to solve this issue. I'm new in Mobile app development, if this notice is not important skip it :)

[sibelius]

it still happens on rn44!

[zywj]

@sibelius Stop JS Remote Debugging

[sibelius]

@zywj I does work without js remote debugging, but I would like to have the debug enabled

[MyGuySi]

Still there in RN 0.43.3

+1 for reopening if this hasn't been fixed...

[divonelnc]

Still happening for me on 0.44.0
Is this still being investigated?

[codedogfish]

My RN app run on android always be extremely slow for the first serveral fetch requests.
Finally, I realize the reason is my LAN has turned on IPv6, but in China (it's a great LAN not support ipv6). So it's seems that android wait ipv6 timeout and change to IPv4, then everything back to normal.

[Nomaq]

Can confirm error still happens in 0.45.1

[moppymopperson]

I can also confirm this behavior is still present in 0.45.1 as well.

[RobTS]

Same here. Interestingly, I did not experience this before up to 0.43

[githubdoramon]

I can also also confirm confirm this behavior is still present in 0.45.1 as well as well.

[foobarfighter]

Having the same problem. setTimeout hack works around the problem. RN version is 0.45.1

[neiker]

This it's back on RN 0.45.1

[ugiacoman]

@neiker Yep, can confirm!

[ccdwyer]

Having this issue as well. Very frustrating.

[danawoodman]

How does one debug React Native apps that fetch JSON? 😭 @lacker can you please re-open as this is again an issue

[cablegunmaster]

@danawoodman debug? Well make log lines everywhere to the console And see where iT reaches like for Every line a console.log("1"); And count up And see which logs arent found And you Got the issue where Its stuck. Use above workarounds to fix it. As there is No generaal fix for this issue.

[rishabhpoddar]

This error still exists RN 45.1

[danawoodman]

@cablegunmaster yes, what I am saying is that without a hack you cannot troubleshoot your apps since the debugger causes this issue to fail with fetch.

[jan-happy]

I was also pulling my hair over this. Glad I've found this issue!

[ghost]

Didn't encounter this issue before, but once i upgrade from 0.44.0 to 0.46.0 today it pops up. The response.json() is just stuck, doesn't invoke then() nor catch(). Like some said, the fetch() was called from a helper function defined outside of a React component, but is called by a react component.

[raunaqss]

Encounter this issue sometimes only through React Native versions 0.44, 0.45 & 0.46. What would I do without these updated issues on Github and user submitted work around? 👍

[mikelambert]

Yay, this appears to be fixed in 0.47 by https://github.com/facebook/react-native/commit/64825389dfb4e01d5b30cd63b0b41937a9bb431d !

[amritg]

I too had faced same issue while debugging on ios Emulator with react-native version: "0.46.4". But as @mikelambert suggested, upgrading to version "^0.47.0-rc.5" solved this issue

[maxim-c]

but it still hangs on android devices.

[chug2k]

i'm still seeing fetch on android devices being really slow. i'm on 0.49

[mark0978]

It's probably not slow, tap the screen and it will go fast.

On Sun, Aug 20, 2017 at 9:52 PM, Charles Lee [e-mail]
wrote:

i'm still seeing fetch on android devices being really slow. i'm on 0.49

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-323634725,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGepnnp5aS-0Xc7a5-5SGyCarECCAvtks5saPDqgaJpZM4H5YHZ
.

[chug2k]

of course, why didn't i think of that

[mark0978]

Cause it is so unobvious and is such a new bug (no wait, it's more than 2
years old....)

On Sun, Aug 20, 2017 at 9:57 PM, Charles Lee [e-mail]
wrote:

of course, why didn't i think of that

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-323635295,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGepjJ16GFnf9exbcTSKdN9eCynJEDJks5saPINgaJpZM4H5YHZ
.

[mikelambert]

Just a reminder @mark0978 and @chug2k , this is fixed in the latest version of RN 0.47.

[maxim-c]

@mikelambert nah... Fixed only for ios, android still broken.

[cablegunmaster]

@reactjs-bot @mikelambert I am still following this post as it seems for me just a stupid bug which should be squashed ages ago, but nobody has/takes the time to do so. #android

[Fahad-pnw]

wtf i spent 12 hours trying to adjust my code, wondering why it wont go within a .then statement of a promise only to find out its a freakin bug

[mark0978]

Sadly, we get so used to the platform working that when the platform fails
us, we waste a lot of time on it. And it's fixed in the next release is
beginning to sound like the repeating chorus of song that just won't end.

On Sat, Aug 26, 2017 at 1:04 AM, Penandweb [e-mail] wrote:

wtf i spent 12 hours trying to adjust my code, wondering why it wont go
within a .then statement of a promise only to find out its a freakin bug

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-325091421,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGeph4seX9aXKGw2gVUfys4u39iKzs_ks5sb7WEgaJpZM4H5YHZ
.

[JasonHenson]

you can always make your own pull request to address the issue

[mark0978]

After my experience with the jest team, no thanks. Why waste my time to be
told, "I don't want to include a dependency, I'm just going to copy the
code from that dependency code into my project" (I believe the phrase was
"vendor it in").

On Sat, Aug 26, 2017 at 7:58 AM, JasonHenson [e-mail]
wrote:

you can always make your own pull request to address the issue

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/facebook/react-native/issues/6679#issuecomment-325124938,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGepgdYGEqDCmtYiUakfnJuPX4lRsdRks5scBaIgaJpZM4H5YHZ
.

[jstahlmann]

wtf i spent 12 hours trying to adjust my code, wondering why it wont go within a .then statement of a promise only to find out its a freakin bug

same here!

[hey99xx]

@maxim-c @mikelambert , if this is only fixed for iOS, shouldn't this issue still be open for Android devs? Reading the entire issue, it seems prematurely closed by @lacker , am I wrong?

[cablegunmaster]

Its not fixed on Android, just some nasty work arounds. ( tapping on the screen kind of )
Which you don't want the user to do in order to go further.

[amitassaraf]

This actually still happens on Android, and when using an emulator even tapping the screen doesn't help..