Duplicated \n in "plain" format with new WebKit, posted by Andrey on Tue Dec 27 12:44:52 2022
|
Dear Stefan,
There is a problem with editing an Elog page in "plain" format with the following "User Agent" :
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15"
It duplicates the newline symbols such that "1<CRLF>2" becomes "1<CRLF><CRLF>2". If edited again - "1<CRLF><CRLF><CRLF><CRLF>2".
I blame the new version of the Apple WebKit.
It works fine with Chrome (user agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36"). But fails with Safari.
Could you please have a look?
Thank you in advance,
Andrey Pashnin
AMS collaboration
|
bug report to webkit.org , posted by Andrey on Wed Dec 28 16:09:30 2022
|
It shound't be a "bug report", sorry. I have changed the category to "Info".
It seems to be really a bug in the WebKit core. I have created a bug report there. For reference: https://bugs.webkit.org/show_bug.cgi?id=249923
I am going to try to patch the ELOG code to handle the content of the textarea in the "plain" format.... it doesn't seem possible though. |
a hack around, posted by Andrey on Thu Dec 29 20:26:11 2022
|
FYI.
Removing "wrap=hard" on the line #11461 in the elogd.cxx file resolves my problem.
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);*/
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
|
a hack around, posted by Konstantin Olchanski on Fri Dec 30 00:46:03 2022
|
- rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
+ rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
my vote is to remove "wrap=hard":
1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
3) this bug (introduced in recent safari, the best I can tell)
K.O. |
webkit bug, posted by Andrey Pashnin on Mon Jan 2 12:32:13 2023
|
FYI
They seem to have accepted the bug report:
https://bugs.webkit.org/show_bug.cgi?id=249923 |
a hack around, posted by Stefan Ritt on Wed Jan 4 09:33:25 2023
|
> - rsprintf("<textarea rows=%d cols=%d wrap=hard name=\"Text\">\n", height, width);
> + rsprintf("<textarea rows=%d cols=%d name=\"Text\">\n", height, width);
>
> my vote is to remove "wrap=hard":
>
> 1) I try to read the specs and my head explodes: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea
> 2) textarea should just accept input typed by user, should not try to "neatify" it. if user wants long lines, we should let them.
> 3) this bug (introduced in recent safari, the best I can tell)
>
> K.O.
I agree with K.O. Does anybody see a problem in removing "wrap=hard"?
It was there more for historical reasons. In the old days screens were not so wide and wrapping was more of an issue.
People tended to write longer lines and complained that the long lines got reformatted differently for different screen
sizes. So by adding hard CRLF the formatting looked the same on different screens. These days this is not such an issue
any more and I agree with 2) above. If the user wants a long line, the user should get it.
Stefan |
a hack around, posted by Stefan Ritt on Wed Jan 4 09:39:38 2023 
|
Ahh, now I remember. Well, the I put that in like 25 years ago ;-)
Let's assume the user write a very long line and relies on the wrapping of the text box. So the input might look like the
first attachment. Then the user hits submit and gets just one long line (second attachment) and has to scroll one kilometre
to the right to see the full line. So there is an inconsistency between the entry form and what the user sees after the
submission. Having "wrap=hard" tells the browser to put CRLF where the wrapping in the textarea happens, so the text looks
the same during entry and after submission. If we remove the "wrap=hard", we would be back to the situation below in the two
attachments.
Opinions?
Stefan |
editing on a smartphone, posted by Andrey Pashnin on Wed Jan 4 10:05:38 2023
|
oh! so, that's the cause of another problem I faced a while ago.
When people edited an ELOG page on a narrow screen device (a.k.a smartphone) it put the extra CRLF and made the page look like the attachment below
(it broke the original formatting).
I had to "fix" this by setting the width of the textarea to a huge number...
However, removing "wrap=hard" solves both these problems! ;) |