Update howler.core.js

[k888168168]

Fix Android cross domain can not auto resume issue

[brenwell]

Works for me, would love to see this incorporated

[AshokPitambar]

Hi ,
This change is critical since we are using howler in cross domain. When we can expect this change as part next tag release.

Thanks , Ashok

[goldfire]

Can someone explain what this PR is fixing and why self.state = 'resuming'; is being removed?

[pjbaron]

I got here from #676 after experiencing errors on a limited selection of Android devices with Howler 2.0.3:
Galaxy Tab S, Galaxy S4

"BUG: Sounds and music does not work on Android devices"

STEPS:

1. Just open game on Android

After inspecting the log file I found this message (which lead me to issue 676):
03-30 12:27:20.402 27138 27138 I chromium: [INFO:CONSOLE(2)] "An AudioContext in a cross origin iframe must be created or resumed from a user gesture to enable audio output.", source: xxxxxxxxxx/lib/howler.min.js (2)

According to 676 Howler is becoming stuck in the 'resuming' state, I am not at all sure that removing that state is a good fix though.
Unfortunately I don't have either of the reported problem devices and audio works fine on my Nexus 7 and on most other Android devices.

Hope this helps!
p.s. thanks for an awesome library :)

[cojo]

@goldfire
If I might add some extra context that might be helpful, we ran into this today on our game and I've produced a temporary workaround on our end, but it is probably possible to fix this directly in the library for future developers as well (and would allow us to remove our workaround).

First, here is an example of our workaround in our page:

    <script>
      window.document.addEventListener('touchend', function() {
        if (typeof Howler !== 'undefined') {
          if (Howler.state === 'resuming') {
            Howler.state = 'suspended';
            Howler._autoResume();
          }
        }
      });
    </script>

Now, the context - as @pjbaron noted, there is a scenario in which _autoResume can get called from various non-gesture contexts (for example in our game we optimistically try to play audio early on in certain situations even if user input hasn't yet occurred). If this happens, state is set to resuming and is not restored to suspended even if the resume() promise fails due to the gesture-context issue in Android Chrome 55+.

The problem is that once the state is "locked" in resuming, calling _autoResume on an appropriate gesture is no longer sufficient to guarantee that context will be resumed - because only the suspended state is checked for (not the resuming stuck state as well).

Happy to provide any additional context or explanation that might be helpful - I know this one is a bit confusing without a repro and I also know I may not have explained it perfectly here.

Hope this helps! Thanks for an awesome library :)
-cojo

EDIT: as an additional aside, I'll note that none of this should imply that I think removing resuming entirely is necessarily the right fix - I think there may be a better fix than that involving handling of these various states - I just wanted to explain what I think is going on in some more detail.

[goldfire]

Thanks for the detailed explanation! As I've thought about this more, there's really no use for the running state, so I'm going to merge this as-is now.