When the Join button won't enable on Android Whale even after you pick a video

This is a translated article. Read the original in Korean ↗

I was building a web app for dance studios. Several people play the same choreography video on their own phones so they can line up their moves. A leader creates a room, viewers pick the same video, and everyone follows along through real-time sync . It worked in Chrome on a laptop and on iPhone. In the Naver Whale browser on Android, though, the "방 만들기" (Create room) and "참여" (Join) buttons stayed gray even with the video filename showing . Trying to pick a file also brought up Google Photos, or an unfamiliar "클라우드 미디어" (cloud media) prompt .

Conclusion

The direct cause of the dead buttons was that fingerprint.js didn't load in Whale. With that script missing, code at the very top of the page threw an exception and stopped. Renaming the file to mediacheck.js made the buttons enable . The idea that Whale blocked the file because of its name is a guess. The session never recorded an actual block.

The Google Photos picker problem is unresolved and still being tested. video/* was not confirmed as the cause of this picker. The extension-only accept below is only a method under test, not a verified fix. It was already tried once, and the user said "안돼네" (doesn't work) .

What to try right now:

• If the buttons won't enable, add ?debug=1 to the end of the URL, open the page, and look at the first error line. If it shows Cannot destructure property 'fingerprintVideo' of 'window.FormationFingerprint', the script didn't load, so try renaming the file first .
• The confirmed workaround for the button problem is regular Chrome on the same phone. The buttons enabled in regular Chrome .
• The picker has no confirmed workaround. Apply the after code below (extension-only accept, the final applied version ) and check whether you can actually pick a local mp4 received over KakaoTalk on the same phone. The same approach was reported as failing in #159, so whether it works this time has to be checked from scratch. Whoever tests it writes four items on one line in their own notes: device / Whale version / whether only videos appear / whether an mp4 can be selected. Without that note, the result stays unknown. This article does not claim the picker is fixed in that state.

<!-- Before (as of #174: no accept attribute. Before that, accept="video/*") -->
<input type="file">

<!-- After (final applied version) -->
<input type="file" accept=".mp4,.m4v,.mov,.webm,.mkv,.avi,.3gp,.ts,.mpeg,.mpg">

Situation

formation is a web app for dance studios. When one person (the leader) plays a video on a phone or laptop, everyone else (the viewers) plays from the same point on their own devices. The iOS test instructions also described a flow where the leader and each viewer pick the same mp4 on their own . When this happened, the app had moved past local testing, and the create-room and join flows were being verified on the cloud deployment .

When you pick a video file, the browser computes the file's fingerprint (a hash of the video's contents) . The viewer's "참여" (Join) button only enables when the selected file's fingerprint matches the fingerprint of the video stored in the room. If the fingerprinting script doesn't load, the button can never enable .

Symptom

In the Naver Whale browser on an Android phone (UA: Android 10, Whale/3.9.14.9), picking a video file showed the filename, but the "방 만들기" (Create room) and "참여" (Join) buttons didn't enable . Regular Chrome on the same device worked, and iPhone and desktop were fine too .

A separate picker symptom was also reported. The user said tapping the file-select button seemed to open Google Photos by default . After clearing the default app, a "클라우드 미디어 설정" (cloud media settings) prompt still appeared . Meanwhile, the .json input for formation data files could be picked without any trouble .

Cause

The confirmed button cause has to be kept separate from the picker hypothesis.

First, the button symptom was a script load failure. Once a debug panel was added, the error below was already there the moment the leader page opened, before any file was picked .

window.error: Uncaught TypeError: Cannot destructure property 'fingerprintVideo'
of 'window.FormationFingerprint' as it is undefined.

fingerprint.js didn't load in Whale, so window.FormationFingerprint was empty. The code that destructures that object threw an exception at the top of the page . Later in the session, since the buttons enabled after the file was renamed, the rename was recorded as the step that resolved this symptom . The reason the load failed was never directly confirmed, though, including whether Whale blocked it based on the filename. What's confirmed goes only as far as "this file didn't load" and "renaming it made it work."

Second, a hypothesis came up that the picker symptom was caused by the MIME hint in accept. The evidence was a contrast: the .json input worked, and only the video input fell through to Google Photos . This hypothesis rests on the premise that the browser chooses the picker type independently of the page's scripts. So the file load problem does not also explain the picker symptom.

Fix

Three changes to accept were tried in sequence. accept is the attribute that tells the browser which files a file input should let you pick.

1. The MIME wildcard (video/*) was removed. The user then said "여전히 마찬가지" (still the same) .
2. All MIME types were dropped and only extensions were listed. The user said "안돼네 다음 수 쓰자" (doesn't work, let's try the next move) .
3. The accept attribute was removed entirely .

The reports in 155 and 159 were about the picker symptom, so the accept changes up to that point didn't fix the picker. After step 3 (removing accept), there is no report on the picker symptom in the record.

The debug panel caught the button symptom. Opening with ?debug=1 immediately printed the exception from the script load failure . After the file was renamed to mediacheck.js, the user confirmed success right away .

Right after that, the extension-only filter was put back on the video input . This approach had already been tried once in #158, and the user said "안돼네" (doesn't work) in #159. The cause of that failure wasn't recorded. The restore in #190 put the same approach back in, and there are no new test results after it.

<input type="file" accept=".mp4,.m4v,.mov,.webm,.mkv,.avi,.3gp,.ts,.mpeg,.mpg">

MIME types were deliberately left out because the session reasoned that video/*-style values can push Android into a media-centric picker flow .

Verification gaps

• After the final extension filter was restored, the session ended without the user confirming whether only videos showed up in the Android Whale file picker, or whether mp4s from KakaoTalk or the Downloads folder could be picked .
• The same extension-based approach got a "안돼네" (doesn't work) report in #159. So the restore in #190 can't be used as evidence of a fix.
• After accept was removed (161), there's no user report on the picker symptom. So the current picker behavior is unconfirmed.
• Late in the session, an explanation came up that the earlier extension-filter failure was also due to the file load problem . No evidence was given for it, though. The picker type is browser behavior driven by the accept attribute, so this explanation is hard to accept. This article treats the two symptoms separately.

So the takeaways from this article should be read as two separate things. If the buttons won't enable, check the console errors and script load failures first . If the picker only shows Google Photos or cloud media, an extension-only accept is worth testing . However, this method wasn't independently verified in this session, and there was one failure report .

Bonus — don't bundle two symptoms under one cause

When two or more symptoms overlap on the same device, finding the cause of one doesn't mean you've found the cause of the other. Here, the button symptom was a script load failure, and renaming the file resolved it . The picker symptom isn't explained by that load failure. Fixing one side doesn't give you enough evidence to declare the other side's fix "right," or to dismiss it as "wrong."

Reporter's Notes — what killed the buttons was a file that didn't load, and the picker needed its own look

Park Doeun

You know the app where everyone in the studio watches the same choreography video on their own phone? Only on Android Whale, the Join button wouldn't enable even after picking a video .

Jung Bada

At first the file picker was what looked off. They said Google Photos came up, and even after clearing the default app, a "클라우드 미디어" (cloud media) prompt showed up . The media MIME type looks like the culprit.

Jung Haneul

But the buttons were already dead before any file was picked. An error printed as soon as the page opened . The picker and the buttons need to be looked at separately.

Park Dohyun

So the picker hypothesis is still alive? You said .json picked fine ?

Jung Bada

Yeah, .json works, so the accept on the video input is suspicious. That's why I dropped the MIME types and kept only extensions .

Park Doeun

But the tester said "여전히 마찬가지" (still the same) and "안돼네" (doesn't work) . Weren't both of those wrong?

Jung Haneul

Both of those were about the picker symptom. So we have to admit the accept changes at that point had no effect.

Jung Bada

So the accept hypothesis missed?

Jung Haneul

Can't say it missed for sure. After accept was removed in 161, there's no picker report in the session. It's unconfirmed.

Park Dohyun

So the file load problem was its own thing, unrelated to the picker. Why was that one file the only one that didn't load?

Jung Haneul

fingerprint.js didn't load in Whale, so the file handler, the connection, and the button-enable logic never got registered .

Jung Bada

I think Whale blocked it because the filename has fingerprint in it. Renaming it should settle it .

Park Dohyun

Hard to believe one filename got it blocked. Is there any evidence Whale actually blocked that name?

Jung Haneul

Not yet. All that's confirmed is the error saying the file didn't load. We can only say that renaming it made it work .

Park Doeun

So we added a debug panel, and in Whale it printed an error saying window.FormationFingerprint was undefined . After renaming the file to mediacheck.js, the tester confirmed: "된다!! 됐어!" (It works!! Got it!) .

Park Dohyun

And the picker? Is putting the video filter back confirmed?

Jung Haneul

No. We just put the extension filter back. Whether only videos show up in Whale hasn't been confirmed yet .

Jung Bada

Then we shouldn't say "if you can't see the Downloads folder, fix accept" yet.

Park Dohyun

Right. If the buttons won't enable, check the console errors first, and write the picker problem down as a hypothesis until it's confirmed.

Jung Haneul

Right. The button cause is confirmed, and the picker is a hypothesis. Success on one side can't count as verification for the other .