Dragging text files into Mail

[humdinger]

This is hrev33893.

When you drag and drop a file of MIME type "text/*" into the Mail window, there are certain issues. Any other filetype is automatically attached to the mail and isn't concerned by this. Depending where you drop a text/*-file, it's handled differently:

• dropped in the text area inserts the text
• dropped in a gray header area, attaches the file
• dropped into an address/subject textbox, inserts it there

This last bullet point can be critical, as long texts will overflow the limited subject line and cause problems when sending. If this feature should be kept (I'm againnit), the pasted text should be cropped to respect standards.

If that last option can be dropped, we could simply have a drag&drop in the text area "Paste" and anywhere else "Attach".

Alternatively, drag&drop of text/*-files could result in a context menu to "Paste {filename}" or "Attach {filename}". (Should Mail ever become a HTML aware abomination, graphic/* etc. could be added.) Since these context menus normally don't appear by themselves, those could also only be displayed when drag&dropping with the right mouse button as power users would be annoyed by the additional context menu step.

[axeld]

That's actually standard behaviour of any BTextControl. I wouldn't like to remove that feature, as it hurts consistency, and would also be annoying if you actually want to move text from one subject line to another (I've done so quite often already).

What problems would be caused when sending? Those should be fixed anyway.

OTOH it's indeed inconvenient that you have to drop text to the header in order to get attached. I like the suggested right mouse button drop behaviour, though.

[humdinger]

Replying to axeld:

What problems would be caused when sending? Those should be fixed anyway.

Today I accidentally drag&dropped a 10kb file into the subject line. I tripple clicked in order to select all and pressed DEL. I thought I killed everything, but apparently newlines weren't considered and unknowingly, I did try to send this mail with a huge subject line. (Though I can't determine if that really was the case).

Upon sending, one CPU maxed out and the mail was never sent. After half a minute I killed the mail_daemon. The mail was lost of course...

So: Pasting textfile contents into text boxes, OK. But limit the pasted contents to a sane amount. See ​RFC2822:

2.1.1. Line Length Limits

   There are two limits that this standard places on the number of
   characters in a line. Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

OTOH it's indeed inconvenient that you have to drop text to the header in order to get attached. I like the suggested right mouse button drop behaviour, though.

So do I. :)

[axeld]

I actually misunderstood - you mean drag&drop of actual text files, not just drag messages with text/* contents. That indeed seems to be a feature of BTextView (at least StyledEdit supports it, too) - we should definitely forbid that for BTextControls.

[humdinger]

Yep, contents of actual dragged text files.

WRT the long subject lines: Maybe a sane limit at least for the attribute representation would be still desirable. Subjects of [haiku-commit] messages can get pretty long. Have you ever doubleclicked on a subject column divider in a Tracker window to auto-size its width? The subject column becomes verrry wide and is only very tediously narrowed by much dragging and scrolling...

[jackburton]

I think part of the problem is this: BTextInput (the BTextView subclass used by BTextControl) should remove line breaks on Insert(). But the code in that method looks like this:

char* buffer = NULL;

	if (strpbrk(inText, "\r\n") && inLength <= 1024) {
		buffer = (char*)malloc(inLength);

		if (buffer) {
			strcpy(buffer, inText);

			for (int32 i = 0; i < inLength; i++) {
				if (buffer[i] == '\r' || buffer[i] == '\n')
					buffer[i] = ' ';
			}
		}
	}

	BTextView::InsertText(buffer ? buffer : inText, inLength, inOffset,
		inRuns);

So if the buffer is bigger than 1k it won't remove the line breaks. This should be changed, of course. I would simply reject buffers longer than 1k.

[axeld]

I think BTextControl should never accept any file drops (or rather, it should take over the URI, but not the contents).

Beyond that, there is a MaxBytes() setting that should be taken as a basis for cutting down the text. Only is that is not given, I would use some sensible defaults, like 1024 characters, or the like.

[jackburton]

Replying to axeld:

Beyond that, there is a MaxBytes() setting that should be taken as a basis for cutting down the text. Only is that is not given, I would use some sensible defaults, like 1024 characters, or the like.

MaxBytes() is set by default to MAX_INT. Would you consider that value as "not set" ?

[axeld]

I would guess so. 1024 bytes might actually be too small as a default for BTextControl, though -- better just filter out all newlines, or simply stop processing the text after the first newline (although that can also be annoying).