> I guess we want "white-space: pre-wrap" which keeps the old line breaks.

Yep. You're right. Thanks!

Hi. 

I am an IT guy of the AMS collaboration at CERN. We have been using your wonderful elog software for about 10 years now. Thanks! It served us so well that I guess we never got in touch with you. 

Recently we have upgraded it (probably for the first time in years) up to the version ELOG V3.1.4-4936b76.

Since then, we have a particular problem. And finally, I managed to reproduce it.

So, when I edit a record and click the "Submit" button it goes back to the summary view (as usual, as before) but it does not really save the entry. And it shows that the record is still being edited. I can actually click "back" in the browser and not to lose the modifications (otherwise, if I try to edit and steal the lock, it's lost). 

I will try to figure out where the problem is coming from. The most verbose mode of the elog server I've found is just GET-POST lines, not helpful. Is there a debug mode? 

Also, we ran httpd configured with the elogd as a virtual host (proxy).

Any help is very appreciated. 

Cheers, 

Andrey

Hi again. We have solved our problem! 

It was caused by a non-defined mod_auth_openidc configuration parameter:

# Interval in seconds after which the session will be invalidated when no interaction has occurred.

# When not defined, the default is 300 seconds.

#OIDCSessionInactivityTimeout <seconds>

As a guess... This somehow makes elogd to forget a user who is editing an entry. And then, clicking "Submit" button makes elogd to start a new session? 

I think this is a bug report. 
However, I am not sure whether the problem is in the new version of Apple's WebKit (15.4) or in the ELOG itself.

When we edit an ELOG record with Safari (as of version 15.4, new WebKit features added) the number of "newline" symbols (actually LF, 0xA) are doubled.

So, for instance, if I edit the following page (1 LF symbol between "aaa" and "bbb"):
```
aaa
bbb
```

then after a "Submit" (without actually any changes) the record becomes (2 LF symbols):

```
aaa

bbb
```

then after a "Submit" (without actually any changes) the record becomes (4 LF symbols in between):
```
aaa



bbb
```

NOTE: The LF symbol at the end (after the "bbb" line) does NOT get duplicated (it gets truncated, I believe).


Our current ELOG version is "ELOG V3.1.4-4936b76".
Could you please have a look? 

I have just setup a new ELOG server on another machine. I took the latest source code from here: http://elog.psi.ch/elog/download/tar/elog-latest.tar.gz. Compiled it and ran. 
Still the same problem with Safari.

> I think this is a bug report. 
> However, I am not sure whether the problem is in the new version of Apple's WebKit (15.4) or in the ELOG itself.
> 
> When we edit an ELOG record with Safari (as of version 15.4, new WebKit features added) there are extra "newline" symbols (actually ^M) being added after EACH line of the record.
> 
> So, for instance, if I edit the following page:
> ```
> aaa
> aaa
> aaa
> ```
> 
> then after a "Submit" (without actually any changes) the record becomes:
> ```
> aaa
> 
> aaa
> 
> aaa
> ```
> 
> Our current ELOG version is "ELOG V3.1.4-4936b76".
> Could you please have a look? 

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

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.