On both Mac and PC, Chrome Kiwi session hangs upon startup [fixed in v1.179]

rrobinetrrobinet
edited April 2018 in Problems Now Fixed
What appears to me to be a new problem In both v1.175 and 178, the Kiwi page hangs upon startup until I open a wspr session.  Safari appears to start normally.
Clicking on the green arrow icon next to the frequency display (what is that icon supposed to do?) will pop up a new working tab at the cost of another session.

Comments

  • jksjks
    edited April 2018
    Do you mean you have no audio or waterfall until the WSPR extension is opened? And then they start up? That would be a new one.
    Anyone else having problems? Chrome 65.0.3325.181 64-bit Mac and 63.0.3239.132 32-bit Windows 10 work fine here.


    The green arrow produces a link to the current current Kiwi with frequency, mode and zoom level specified. As the documentation describes, if you right click while moused over it you can do a "copy link location" (or whatever your browser/OS says) to get a copy of the link. Then you can paste the link into an email or something. This feature was requested by a user.

  • rrobinetrrobinet
    edited April 2018
    Yes running Chrome Version 66.0.3359.117 (Official Build) beta (64-bit) on my Mac, I open the Kiwi page and get a startup display but no sound or other activity after the PCB picture goes away.  Selecting the WSPR extension does produce a fully functioning WSPR session, but no audio.  Clicking on the green button causes a new fully functional tab to be opened.   Safari and Firefox start normally in the first session.
    Perhaps I have a lurking Chrome cookie?
  • jksjks
    edited May 2018
    Well, the idiots at Google have decided they know what's best for us: https://developers.google.com/web/updates/2017/09/autoplay-policy-changes#webaudio

  • rrobinetrrobinet
    I'm glad it wasn't my fault.  I guess I can live with this behavior.
  • jksjks
    edited April 2018
    With Chrome audio is broken for all the sites on websdr.org except for PT's http://websdr.ewi.utwente.nl:8901/
    I wonder how he got around the new policy? (if he's actually changed anything at all) That link above mentions there are a few mechanisms for deciding you visit a site often enough that the new no-autoplay feature shouldn't apply. But I visited PT's site in incognito mode so none of that should have applied (I don't use Chrome on a regular basis anyway).

    So I think I'm going to have to display the "Play" button with Chrome just like I have to for iOS. You'll have to click on the screen before the audio will start.

  • jksjks
    Okay, v1.179 has been release and has a fix for this issue. Reboot if you need it before today's auto-update.

    If Chrome would prevent audio autoplay then an overlay appears asking you to "Click to start OpenWebRX". You can click anywhere on the screen to proceed. Right now a keyboard press isn't sufficient and I'm not sure why. Will look into this more.
  • jksjks
    You can also change the default audio autoplay action for all web sites by going to this internal Chrome URL:
    chrome://flags/#autoplay-policy

Sign In or Register to comment.