Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 727 of 808  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
icon4.gif   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

 

    icon2.gif   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. 

    icon2.gif   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);

    icon2.gif   a hack around, posted by Konstantin Olchanski on Fri Dec 30 00:46:03 2022 
- rsprintf(&quot;&lt;textarea rows=%d cols=%d wrap=hard name=\&quot;Text\&quot;&gt;\n&quot;, height, width);
+ rsprintf(&quot;&lt;textarea rows=%d cols=%d name=\&quot;Text\&quot;&gt;\n&quot;, 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.
    icon2.gif   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
    icon2.gif   a hack around, posted by Stefan Ritt on Wed Jan 4 09:33:25 2023 
> - rsprintf(&quot;&lt;textarea rows=%d cols=%d wrap=hard name=\&quot;Text\&quot;&gt;\n&quot;, height, width);
> + rsprintf(&quot;&lt;textarea rows=%d cols=%d name=\&quot;Text\&quot;&gt;\n&quot;, 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
    icon2.gif   a hack around, posted by Stefan Ritt on Wed Jan 4 09:39:38 2023 Screenshot_2023-01-04_at_9.38.51_.pngScreenshot_2023-01-04_at_9.39.09_.png
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
    icon2.gif   editing on a smartphone, posted by Andrey Pashnin on Wed Jan 4 10:05:38 2023 Screenshot_2023-01-04_at_10.06.02.png
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! ;)
ELOG V3.1.5-3fb85fa6