Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] [Safari] Form Auto Fill messes up terminal input field #1875

Open
toxuin opened this issue Apr 16, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@toxuin
Copy link

commented Apr 16, 2017

What were you doing?

After first command, Safari (may be other browsers with autofill enabled) tries to auto-fill the form based on previous input. This does put text in, but does NOT produce keyUp and keyDown events, where octoprint terminal form relies on.
This messes up the whole input field, disallowing me to input even a fresh string. Input can be done, but the command will never be sent to server.
After I manually add autocomplete="off" to the input field, everything works amazingly well.

What did you expect to happen and what happened instead?

I am not quite sure how this field internally works, but I would assume this should not rely on keyUp and keyDown as this would theoretically get messed up for copy-pasting too.

Input field in question is the one on the terminal page with id="terminal-command".

Branch & Commit or Version of OctoPrint

OctoPrint 1.3.2 (master branch)

Operating System running OctoPrint

Server runs Raspbian, most likely irrelevant.

Printer model & used firmware incl. version

FIRMWARE_NAME: RepRapFirmware for RADDS FIRMWARE_VERSION: 1.17d ELECTRONICS: RADDS 1.5 FIRMWARE_DATE: 2017-01-28

Browser and Version of Browser, Operating System running Browser

MacOS 10.12.3 (16D32), Safari 10.0.3 (12602.4.8)

Link to octoprint.log

link to gist.github.com

Link to contents of terminal tab or serial.log

same link to gist.github.com

Link to contents of Javascript console in the browser

same link to gist.github.com

Screenshot(s) or video(s) showing the problem:

Not applicable

I have read the FAQ.

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 19, 2017

Could you make a gif or youtube video of this? I'm struggling to understand what exactly you are seeing, and I cannot reproduce anything that fits your description (or generally looking out of the ordinary).

@KevMags

This comment has been minimized.

Copy link

commented Apr 19, 2017

Macs using Safari (10.1.1) have "Autofill>Other forms" enabled by default which insists on altering the gcodes entered in the terminal tab. Adding a space to the end of newly entered text to make it a unique entry will allow the gcode to be sent/read properly. I pulled the few hairs that I have left out trying to figure out why the M119 gcode entries were not being sent to the terminal. Disabling "Autofill>Other forms" in Safari preferences fixes the problem.

Edit: Clearing the Autofill>Other entries will also fix the problem.

foosel added a commit that referenced this issue Apr 19, 2017

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 19, 2017

Ah, that setting being at fault was a good hint. That's (still?) disabled by default on BrowserStack's Safari. Enabling it got me a reproduction, disabling auto completion on that input field indeed solved the issue. Pushed to maintenance, soon devel, will be in the 1.3.3 release.

Thanks!

@foosel foosel added this to the 1.3.3 milestone Apr 19, 2017

@BillyBlaze

This comment has been minimized.

Copy link
Collaborator

commented May 3, 2017

Just a small heads-up; Chromium has started to ignore autocomplete="off" and other browser makers are following their policy. (See comment)

So this fix might be a temporary solution.

@foosel

This comment has been minimized.

Copy link
Owner

commented May 3, 2017

So setting this to autocomplete="gcode-command" should probably behave the same as "off"?

@foosel

This comment has been minimized.

Copy link
Owner

commented May 31, 2017

1.3.3 was just released. Unsure what to do about this though, considering that the solution will soon be killed off by browser vendors :/

@foosel foosel removed this from the 1.3.3 milestone May 31, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.