FluidNC from 1.05 renaming bug on Android Chrome

Software
1

Quite amusing (because I was able to work around it) bug.

I’ve not fully checked I can repro from a fresh flash but I believe all I did was:

  • Full Flash 1.05 from Windows on top of a fresh from factory 4.1 board.
  • Try config and have it fail (don’t think it’s related).
  • Power cycle
  • Attempt to rename / modify files on Android 12 running Chrome 136..0.7103.87 connecting via Maslow-self-hotspot.

Soooooo when I did this, if I tried to rename a file (ie maslow.yaml → maslow_bak.yaml), it instead renamed it to ‘Ok.js’. File itself was unchanged so it appears it’s pulling the string for the button name rather than the text field.

And I tried creating a folder and canceling that and it called it ‘Cancel’ (maybe .js I forgot to check).

I wonder if it’s related to:

I wasn’t able to delete the folder, but I also bailed from trying to work around it on my phone at that point.

I bought it in, and connecting to my laptop inside I was able to upload a new maslow.yaml, so I went off to keep trying at that point.

Screenshot 2025-05-14 at 16.09.01
Screenshot 2025-05-14 at 16.09.011094×837 38.9 KB

I’ll try to find some time to look at the code see if I can find where it’s doing it once i’ve got myself set up building the source (unless someone can spot it easily).

1 Like
2

:joy:
:joy:
:joy:

That is a really good one, I will see if I can replicate that :grin:

3

Yep, it’s definitely one of the more entertaining bugs i’ve seen in my time :rofl:

1 Like
4

I have run across this and have been able to confirm using window 11 - Chrome

2 Likes
5

I am able to replicate this too using the edit file name tool:

image
image1274×978 54.5 KB

It seems like the culprit is these two lines here:

const creditsDlgCancel = () => closeModal("cancel");
const creditsDlgClose = () => closeModal("Ok");

We should be calling the closeInputModal function instead.

Here is a fixed index.html file. The fixes will also be in the next release.

index.html.gz (117.4 KB)

1 Like
6

@bar

I think there might be the same / similar problem with the filename for saving serial - on Android Chrome + FW 1.06 the filename I get when trying to save the serial is the entire serial output (as far as I can tell).

1 Like
7

Interesting, it seems to be working correctly for me on ios with 1.07. Is there any chance you have an older index.html file?

We’re talking about what happens when you click the “Save Serial” button?

1 Like
8

Yep.

Possibly, will recheck tomorrow with definitely 1.07 :slight_smile:

1 Like
9

I still see it with 1.07. I have a sneaking suspicion it worked before you fixed the other bug too :laughing:

BUT

I’m not sure i’d jump to assuming it’s a Maslow bug and not something specific to my device (as no-one else has talked about it). Chrome on my mac and windows laptops don’t do it.

1 Like
10

Thanks for checking!

:grimacing:

That does happen sometimes.

I don’t have a good way to replicate it without an Android phone, but I will think on how to address it

11

It’s bug update Sunday…

Turns out this latest behaviour was user error on my part. It’s the result of me running Chrome on Android:

  • Attaching to the device network, but not actually signing into the network ‘As Is’.
    • In both cases (on my phone at least) attaching by the auto-open and putting in the IP address it is attaching in ‘AP’ (Access Point I think) mode, and it’s not visibly intuitive it’s different.
    • Without signing into the network you get restricted permissions behaviour, which mostly means no you can interact with the page, but file operations are blocked.
    • It’s interesting that the result of attempting to do the save serial ends up as the whole serial file being piped to the filename, but from when i’ve looked at the console log, I think it might be turning it all into a string first then saving it when it works right, so I can see how it might possibly happen.