App doesn't work in FireFox or Safari, only Chromium-based browsers?

[jasoncoon]

FireFox v124.0.2 64-bit on MacOS 14.4.1 Intel

I followed the instructions at WiFi Configuration | emotiscope

I connected to the “Emotiscope Setup” network. I entered my wi-fi network name and password, but when I click the Connect button it immediately redirects me to https://app.emotiscope.rocks/ which doesn’t work because I’m still connected to the “Emotiscope Setup” network, which is still available. The light continues blinking. I went back to emotiscope.local and tried again, repeatedly, same result.

I opened FireFox dev tools and noticed clicking the Connect button submits a GET request to http://emotiscope.local/save-wifi?ssid=SSID&pass=PASS which failed with no response. I got the same result if I use the IP address (192.168.4.1).

I double-clicked the request, which opened the save-wifi URL in a new browser tab, which seemed to work. The light stopped blinking and the setup network went away. I can see the device on my network, and it has a local IP. When I connect to app.emotiscope.rocks it’s just stuck on CONNECTING. The GET request succeeds with a 200 OK response, but I don’t see any other requests being made (except a request for the favicon.ico file which fails with 404 Not Found. Same result if I use the local IP address instead of the device.

I later noticed the save-wifi request was being blocked by something. Maybe because it’s bad form to include sensitive data in the query string parameters of an insecure HTTP request? Note that I did not see any browser popups or warnings of any kind, it just didn’t work.

I do use the uBlock Origin FireFox extension. But disabling uBlock does not fix the save-wifi or the app connecting problem.

Accessing its local IP gives me the WIFI SETTINGS page, but the same thing happens when I click the CONNECT button. It redirects to app.emotiscope.rocks but is stuck on CONNECTING…

I begrudgingly fired up Chrome and everything works fine.

Doesn’t work in Safari.

[jasoncoon]

Now, even in Chrome, I'm getting an error: Sorry, portrait mode only! unless I resize the window?

[asutherland]

For the setup, I ran into the same problem using Firefox mobile. I believe the problem is that the HTML submit logic looks like:

            let wifi_endpoint = "/save-wifi?ssid="+ssid+"&pass="+pass;
            fetch(wifi_endpoint);

            window.location.href = "https://app.emotiscope.rocks/";

The problem here is that unless "keepalive" is used with fetch, performing a fetch() call immediately followed by navigating the page will immediately try to terminate the fetch request before it can be issued[1]. A better approach would arguably be to make the function an async function and then await fetch(wifi_endpoint); which will wait for the browser to complete the network request. (And where if there's a problem with the request, the rejection will throw, avoiding the navigation. Although it would be best practice to inspect the returned Response object for its status and potentially its payload, etc.)

If iterating on the logic, it might also be worth considering using trim() on the SSID and password as well. A different problem I ran into when switching to Chrome to try and fix things is that my auto-complete recognized my wifi name and when I picked it out of laziness, it inserted a space character after the SSID name. Obviously, this could cause problems for people being tricky about including whitespace in their passwords or SSIDs although I don't know if that's legal?

1: Browser behavior obviously differs here and the spec allows for that since network requests are inherently race-prone, but as the code is written there's definitely no guarantee of the network request getting made.

[asutherland]

For the app redirect problem, I'm seeing that the source code of app.emotiscope.rocks only seems to invoke fetch_and_redirect() if navigator.connection is defined and truthy in order to find local instances:

        if (navigator.connection) {
                console.log("Connection type: "+navigator.connection.type);
                if (navigator.connection.type == 'cellular') {
                    alert("Emotiscope is only reachable from your home WiFi network! Please enable WiFi.");                   
                }
                else{
                    fetch_and_redirect();
                }
            }
        });

According to the browser compat table at https://developer.mozilla.org/en-US/docs/Web/API/Navigator/connection neither Firefox nor Safari implement this at this time.

A reasonable fallback might be to call fetch_and_redirect() in the case navigator.connection is not defined/truthy.

[larryqiann]

Just wanted to add that I've had the same issue with setup and with Chrome

On my side, there's an additional problem involving the Chrome web app only working on phones or other touch-enabled devices. When using a mouse to operate the sliders, nothing happens, but when mobile emulation mode is enabled in DevTools, the app works fine. It looks like the app specifically is looking for 'touchstart', 'touchmove', 'touchend' etc events, which the browser in desktop mode won't be sending.

Thanks!

[note: I am running the source code version (v1.0.0) on a dev board and not the actual product, so your experiences may be different.]

[connornishijima]

@jasoncoon, @asutherland and @larryqiann:

Thank you guys for all the feedback! I'm taking all of your great advice into effect for 1.1 as I continue development. I'm definitely a hardware/embedded guy first, and more of a hobbyist web dev, so pardon me while I learn the ropes!

• I'm aware of the issues running the web-app on desktop, and only supporting touch devices and portrait mode at launch was due to not knowing yet how to design an ergonomic landscape interface for the remote. I'd rather delay a great landscape mode than ship an okay one. Ideas are welcome!

• Great catch with the unsupported Navigator connection issue. It's truly painful how little of the cool HTML5 stuff Safari and Firefox are including. I'll shoot for a 1.0.1 patch later this week that'll just let the unsupported devices through without checking their WiFi status.

• For use on a PC, Chrome has a "Toggle Device Toolbar" button which switches to a responsive mobile phone screen size and emulates touch events instead of mouse events, which are annoyingly a different type of event.

  

[connornishijima]

I've replaced the code @ app.emotiscope.rocks to allow through any browsers that don't support navigator.connection, and have pushed changes to the 1.1 branch that fix CSS formatting issues that only Safari had.

Shoutout to BrowserStack Local, that's what's now letting me test Safari on my local network without any iOS devices in my house!

Still finishing up some 1.1 changes this week before an official OTA release, thank you all for your patience.

[connornishijima]

I've also now pushed an official Landscape Mode in 1.1 as well! Just hiding the device preview when the aspect ratio is landscape has good enough results for now until I think of a more ergonomic horizontal design. https://github.com/Lixie-Labs/Emotiscope/commit/81d4f61a6a71598565267ce99f372a91ac93a285

[connornishijima]

Mouse support is next

[connornishijima]

Mouse support has been pushed to the 1.1 branch! With these changes, Safari/Firefox both work, and PC control is now possible too. <3

OTA update coming soon! I'll reply here when it releases.

[nightshift4000]

Hello. On my side I am still experiencing issues accessing the remote site (with FW 1.1). I get a ERR_CONNECTION_TIMED_OUT error. Tested on Android with

• Firefox 126.0
• Chrome 125.0
• Vivaldi 6.7.335.109 Vivaldi is the only browser that at least sometimes can access the site. Mostly after rebooting emotiscope.