Messages/replies cut off when sent together with files

[ninavizz]

Description

When I send a lot of text as a source, the Client shows only some of that text as the received message. :((

STR

1. Send a 480cc message to the SuperFun instance, as a source.

• Either as a follow-up message from an existing Source, or as a new Source.
• Either with or without a file.

I sent the following:

Hello, and thank you for participating in the SecureDrop Workstation’s pilot. Below is a survey to collect some basic information about your skills and experience.

This information will only be shared among the user research and support teams (so, 5 individuals, total). If you previously filled-out a similar survey for a past research effort, we ask that you please take a moment to complete this one—as we do not retain individual survey responses past each study’s completion.

2. Check Source convo in client on workstation.

Expected

Complete text of message shows in client.

Actual

Message cut-off after the word research

[eloquence]

I'm unable to reproduce this issue either in git master or in 0.2.3-deb (prod build), but note that both of those versions are different from your nightly. I'm able to receive long messages without cut-off.

[rocodes]

I was able to repro this and found that both the source message and a long reply could be truncated/cut off.

I was also able to repro some inconsistency with this--on a subsequent run of the client, more of the messages were available (2 lines), but some was still truncated, and some long messages are not truncated at all.

[rocodes]

and my first one (with only 1 line showing) was https://user-images.githubusercontent.com/22777700/77966868-f39aae80-72b1-11ea-8678-1bd9767f5fc0.png

[redshiftzero]

I can repro by repeating 0123456789abcdef0123456789abcdef0123456789abcdef with no whitespaces:

[redshiftzero]

there might be other issues, but at least we're seeing a regression from #815

[rocodes]

STR: Truncation of messages for both source and journalist related to attachment submissions

1. As a source:
   Submit a long message containing whitespaces. Observe it not be truncated.
2. As a journalist: Submit a long reply containing whitespaces. Observe it not be truncated.
3. As a source: submit a message and an attachment.
4. As a journalist: observe truncation of previously non-truncated messages in the UI, as well as new replies

[sssoleileraaa]

I'm able to repro. Thank you for this STR!

[redshiftzero]

After following that STR (this was with my client a reduced size), I don't see the truncation like #998 (comment), instead:

but I do see another (also bad) behavior upon resizing, squished message bubbles:

[rocodes]

STR: Truncation of messages for both source and journalist related to attachment submissions

1. As a source:
   Submit a long message containing whitespaces. Observe it not be truncated.
2. As a journalist: Submit a long reply containing whitespaces. Observe it not be truncated.
3. As a source: submit a message and an attachment.
4. As a journalist: observe truncation of previously non-truncated messages in the UI, as well as new replies

A further update is that, if I resize the client window (was previously full-screened in the screenshots above), it redraws such that:

• less of the text is truncated
• the "download file size" is not placed above the attachment name/download button
  
  (which may be related to text/bubble being truncated).

[eloquence]

Retitled this issue for clarity, and reopened #815; these two issues can be resolved independently, and this one is higher priority.

For the record, I can reproduce this issue outside Qubes as well, and observe similarly different rendering outcomes depending on client window size.

[conorsch]

The STR that @rocodes provided were spot-on. Following those STR, was able to reproduce on test hardware, running securedrop-client v0.1.5 & securedrop-workstation-dom0-config v0.2.4.

[sssoleileraaa]

"eloquence moved this from I am a temporary column, ignore me to Done"

should i ignore this whole thing?

[eloquence]

Sorry, use of temporary columns is to ensure that GitHub does not archive the most recent issues when using the "Archive all" feature. Will use a more descriptive name in future.