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.
1 Like
12

Thanks for the update!

This has created other weird and hard to debug issues in the past too. I wonder if there is a way that we could detect this and give the user a popup warning them that they might see some strange behavior?

13

Yes we can.

the server can see what url is being requested, if it’s not an IP address or the
maslow.local name, we can return a different page (or do a popup) This
page/popup should list the URL that is being requested and ask the user to
report it to the forum (even after we do the other fixes below, there may be new
combinations in the future)

In addition, we should do a poll/research project to find all the URLs that the
different systems (OS and browser combinations) go to to try and tell if they
have Internet access.

Once we have done this, we can make the system detect those URLs and return the
appropriate response to trick the browsers into thinking that they hvae access

I know that early on there were some patches posted to do this
detection/response for a few OS/browser combinations, but we need to do more
testing to find more and add them to the system.

David Lang

1 Like
14

I love this idea. That is brilliant.

I’ve created an issue for it here.

15

Bar wrote:

I love this idea. That is brilliant.

I’ve created an issue for it here.

ideally we fake the detection so that the systems think they are connected to
the Internet, but since that changes over time, detecting when this isn’t the
case and letting the user know is a good backup to have in place.

David Lang

1 Like