Not sure but it looks recent :
It seems that file manager’s editor now translates on-the-fly html characters to utf-8… pretty annoying while redacting, since the next save flattens everything, so strikes all special characters.
Did not try with another browser, but latest FF here…
Is it my setup or can you confirm this on your end ?
Thank you for your message. Try to insert any html character with an accent like “è” or even an innocent " ", I might add… Save your file with file manager, close Webmin (or not), re-open it.
Then, open the file manager’s editor and tell us if your html codes are still in place in the editor’s output or if you see them directly as characters with accent. Problem is if you select, you copy this new output instead of the expected characters…
At least this thing is happening with the submitted config.
To put it short, I am wondering what’s wrong that the editor can save, but not properly open a text file as it is on disk, and converting directly the output…
Perhaps it is my setup, but wanted to know if any one is facing such stuff…
Mmmh, thank you very much for your prompt assistance. So disabling this should let me copy original characters as they were written on disk. Never had this stuff until now with the editor. Thank you again for the hint.
Thank you again for your hint. Look, I did what you said but I am still hitting the same problem.
I even restarted webmin after saving the changes for this setting but still no luck…
Whether ISO, UTF-8 or other charset, the editor always open the file and immediately convert all html special characters to their corresponding symbols.
As I said before, even non breaking spaces (ampersandnbsp;) are converted to spaces, and copy-pasted as spaces, instead of being in their corresponding html form.
I am pretty sure that this was not happening like 2 months before.
Again, pasting html characters and saving them is working however the problem is happening only while opening the file. For example, if I open a page and immediately save it, all my html special characters will be written to disk directly as their displaying form instead of their html form (check the attached image).
Thank you for your time. That’s the problem, I need this è to stay in its html form (egrave; and not è) in the editor. Try to replace this è by its html counter part (egrave;), save and close the file. Then re-open it and it will show as “è” again instead of staying “egrave;”. And if you copy it, you will copy è instead of egrave; too. If you save it again, “è” will be written to disk instead of egrave; hence loosing the html code forever in the favor of è. It is very weird and totally surprising, I am having hard time to explain this behavior because there is no reason why the editor should do this. This problem makes the webpage render wrong, which is normal because è is not in its html form anymore. It may render correctly in some cases depending the web server charset setting, however pure html should be kept in the text file to make sure the character always show correctly whatever the web server setting. Thanks
Everything stay as is, everything I paste stay like I paste it. when I reload, no difference. Also that renderers on webpage as egrave; not that funny è. Maybe staff can work it out. Good luck with it.
Thanks, you need to write è in html. Add an ampersand “&” before “egrave;”. Save, close and reopen the file and you may notice that the “&”+“egrave;” has been replaced by “è”, so striping out “&” and “egrave;”.
I’m not sure what you’re trying to confirm by copy/pasting into the forum? The forum shares no code with Webmin or the File Manager or editor. How it behaves with encodings isn’t relevant to the conversation, I think?
Just wondering if there is some commonly used library or code involved. I just saw another one on /. Of course much of the front page commentary is cut and pasted from other sources. I visit two discourse forums frequently and it occurs to me I’ve never seen it on one of them.
But, still, I’m seeing more and more of this on other sites as well. I personally don’t have much need to use a browser based text transfer tool.