There has been an update to firefox within the last 2-3 months that has resulted in no line breaks getting added to an issue message.

This results in the message box for an issue continuing on 1 line and scrolling to the right of the screen.

This does not happen with Chrome of Internet Explorer.

Hi Matt:

Can you check the html textarea using your browser's debugging tools. It should look something like:

<textarea name="@note" rows="10" cols="72" edit_id="eta_0" wrap="hard"></textarea>

note the presence of wrap="hard". If this is missing, please edit
the issue.item.html template in the html directory of the tracker
and add the wrap="hard" to the template.

Also when you have no line breaks in the message, are you using the return key to add line breaks when you create the message?

Hi John

Thanks for the reply, I have checked the HTML source and it does include the wrap="hard" tag:

<tr>
 <th>Change Note</th>
 <td colspan="3">
  <textarea name="@note" wrap="hard" rows="5" cols="80"></textarea>
 </td>
</tr>

When line breaks are added using the return key, they are all present and correct. The ones that are missing are the "automatic" ones that are added when the line wraps after getting to the edge of the text area.

When typing in the text area, the text wraps correctly in the browser pane. It is after hitting the submit changes button, and this is posted and then displayed below as a message.

After posting that reply, the functionality is working correctly in *this*  issue tracker... So it must be something my end...

The issue has now resolved itself...

I have performed a diff on my HTML folder and the 1.6.1 source HTML folder and recreated all differences. As I have customised the tracker with extra fields and lookups, I have only ever updated the HTML as advised in the upgrade document not performed a complete source refresh...

The most likely looking candidate was this missing declaration in the style.css file:

pre {
  white-space: pre-wrap;
}

Now when adding a message, the text no longer is getting truncated with hard returns. Instead word wrap seems to be correctly handled by the browser depending on the size of the text area.

I have kept the original HTML folder, with the issue, if you would like me to do any more investigation...

One thing I clearly didn't appreciate when reading the instructions to upgrade to version 1.6.0 was that the following CSRF hidden fields should be added to all the forms:

<input name="@csrf" type="hidden"
           tal:attributes="value python:utils.anti_csrf_nonce()">

This was the other major change a performed on the HTML.

If it is necessary to update all forms with this field, perhaps the upgrade document could be made more explicit with this instruction?

Kind regards

Matt...

Hi Matt:

In message <1568908191.0.0.280891749173.issue2551060@roundup.psfhosted.org>,
Matt writes:
>The issue has now resolved itself...
>
>I have performed a diff on my HTML folder and the 1.6.1 source HTML
>folder and recreated all differences. As I have customised the
>tracker with extra fields and lookups, I have only ever updated the
>HTML as advised in the upgrade document not performed a complete
>source refresh...
>
>The most likely looking candidate was this missing declaration in the
>style.css file:
>
>pre {
>  white-space: pre-wrap;
>}
>

Ah that could be it. I don't have access to mercurial from here to see
when that change was added.

Also can you check the actual message file. It should be in
$tracker_home/db/files/msg/#/msg<msgnum>

So if you are looking at msg101, it will be in 

   $tracker_home/db/files/msg/0/msg101

for message 3303 it will be in

   $tracker_home/db/files/msg/3/msg3303

for message 31300 it will be in

   $tracker_home/db/files/msg/31/msg31300

etc. if you have 100000 messages the # will be 100.

Find one of your messages and see if it is line wrapped in the actual
file. If so then the problem was in display and not in generating the
data.

Why this changed all of sudden in firefox I am not sure.

Maybe a change to the default syle sheet? Seems to be a bit odd that
that would happen but...

>Now when adding a message, the text no longer is getting truncated
>with hard returns. Instead word wrap seems to be correctly handled by
>the browser depending on the size of the text area.

It looks like pre-wrap according to mozilla
(https://developer.mozilla.org/en-US/docs/Web/CSS/white-space?v=example)
is defined as:

  pre-wrap
    Sequences of white space are preserved. Lines are broken at
    newline characters, at <br>, and as necessary to fill line boxes.

so I would expect that newlines in the source msg file would be
preserved in the web view.

>I have kept the original HTML folder, with the issue, if you
>would like me to do any more investigation...

I can see the css change as the cause for your original issue. I
appreciate your keeping the original source but I don't think it is
needed for followup.

If you are happy with the current state, please close this as fixed.

Thanks to your report we have this ticket to point to if somebody else
comes up with the same issue.

Members of my group experienced this problem with other browsers (don't remember which) on the old 1.5 roundup. When we upgraded to the latest roundup version the lines started getting wrapped again. We are currently 5 patches behind the roundup's tip.

A couple of people were able to reproduce the problem on the old roundup. When doing the same thing a few minutes later using the same browser on the new tracker, the lines were wrapped.

Hi again Matt:

In message <1568908191.0.0.280891749173.issue2551060@roundup.psfhosted.org>,
Matt writes:
>pre {
>  white-space: pre-wrap;
>}
>
Looks like this was added in:

  changeset:   4862:7ed1893ea3ac
  user:        Thomas Arendsen Hein <thomas>
  date:        Tue Mar 11 10:13:58 2014 +0100
  files:       CHANGES.txt share/roundup/templates/classic/html/style.css share/ro
  description:
  issue2550793: Wrap messages with very long lines in the web interface.

  Applied to templates classic, devel, minimal and website/issues.
  jinja2 and responsive should already have this through bootstrap.

so it's been there since 1.5.1.

Hi Matt:

In message <1568908644.07.0.208859850186.issue2551060@roundup.psfhosted.org>,
Matt writes:
>Matt added the comment:
>

>One thing I clearly didn't appreciate when reading the instructions
>to upgrade to version 1.6.0 was that the following CSRF hidden fields
>should be added to all the forms:
>
><input name="@csrf" type="hidden"
>           tal:attributes="value python:utils.anti_csrf_nonce()">
>
>[...]
>If it is necessary to update all forms with this field,

If you use the standard context/submit templating item then the hidden
field is added automatically. So you must not add the html snippet
otherwise the same field is defined twice. See checkin 4d32fa88c5d2
for a fix for an overeager automated addition of the @csrf field.

>perhaps the upgrade document could be made more explicit with
>this instruction?

What wpuld you suggest for wording?

  If you have forms using the POST method that are not using
  the standard submit routine, you should add the following field to all
  forms:

   <input name="@csrf" type="hidden"
      tal:attributes="value python:utils.anti_csrf_nonce()">

Would replacing "should add" by "must add" be sufficient?

The message files that previously exhibited the issue, did not have the "automatically" added Line breaks within long passages of text. And without the css element the display was not correct.

Of course any message files with text with the line breaks did not expand off the screen as they "automatically" wrapped.

I suppose the question is how were the "automatic" line breaks previously getting added (that masked this issue) and why did they stop getting added?

I think it is a better solution to not add line breaks into the message files, instead handle the wrapping at the display.

Regarding the csrf hidden fields... When I read the update document, I assumed I was using the "standard context/submit templating item" and did not have to amend the HTML...

It was when I did the diff between my HTML and the 1.6.1 HTML that i noticed the missing csrf fields in my HTML and presumed they needed adding...

If the new CSRF fields in the 1.6.1 HTML were added in error, and have been removed with that checkin (sorry I couldn't workout how to view checkins) then the documentation is correct.

I will now remove these hidden CSRF fileds I added in error.

Thanks for all your help and advise.

And I would like to say we have been using Roundup Issue tracker since 2009, it is a great bit of software and I would like to say a big thanks for all the effort you and your team put into developing it. Thank you.

Matt...

Hi Matt:

In message <1568970663.14.0.808392598651.issue2551060@roundup.psfhosted.org>,
Matt writes:
>It was when I did the diff between my HTML and the 1.6.1 HTML that i
>noticed the missing csrf fields in my HTML and presumed they needed
>adding...

There are places where you do need the @csrf token in your templates.
E.G. the original classic templates had forms that did actions where
the default submit button was not suitable (e.g. removing messages
from an issue).

>If the new CSRF fields in the 1.6.1 HTML were added in error, and
>have been removed with that checkin (sorry I couldn't workout how to
>view checkins)

Wow this is not as easy as I expected. To see checkins you can go to:
https://sourceforge.net/p/roundup/code/ (linked from the roundup
website at: http://roundup-tracker.org/code.html)

Click on the code tab and that will take you to something like:

    https://sourceforge.net/p/roundup/code/ci/08b241c9fea4e9a349bb80c6964da5c15dfcafb9/

To see checkin  4d32fa88c5d2 edit the URL so it looks like

 https://sourceforge.net/p/roundup/code/ci/4d32fa88c5d2/

and load that url. Yeah I am amazed at how difficult this is.

>I will now remove these hidden CSRF fileds I added in error.

I would suggest you don't do that. If you merged the changes in from
the classic tracker templates, I claim that they are needed. I would
use your tracker with the additional @csrf elements. If you see the
dreaded:

  File "/home/roundup/lib/python2.6/site-packages/roundup/cgi/client.py",
  line 1154, in handle_csrf
  key=self.form['@csrf'].value
  AttributeError: 'list' object has no attribute 'value'

issue in your logs, look for the @csrf hidden input along with /submit
in the same form. If you find that then remove the @csrf input.

It looks like there were 9 @csrf fields added to the classic
templates in revision c8bf4e9912ed

    https://sourceforge.net/p/roundup/code/ci/c8bf4e9912ed/

It's a little difficult to advise you on this as I don't know if you
have added extra forms to the default templates.

>Thanks for all your help and advise.  And I would like to say we have
>been using Roundup Issue tracker since 2009, it is a great bit of
>software and I would like to say a big thanks for all the effort you
>and your team put into developing it. Thank you.

I am glad you have found it useful. A lot of people have made roundup
what it is including Richard, the original author.

Have a great weekend.

I think this can be closed. It does point out that release docs may need some work going forward.