Open Bug 1276391 Opened 8 years ago Updated 3 months ago

Pasted content does not appear but is added to message if pasted HTML contains weird absolute positioning with crazy offsets

Categories

(Core :: DOM: Editor, defect, P3)

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

People

(Reporter: firstpeterfourten, Unassigned)

References

(
URL
)

Details

Tested with TB 45.1.0 (latest release) in Safe Mode.
Steps to reproduce:
1. Open a new Message Compose Window.
2. Visit sigmaxi.org and copy some simple body text from the page.
3. Click in the Compose window and CTRL+V to paste.

Expected results:
4. The copied text appears in the message compose window.
5. The cursor appears at the end of the pasted text.
6. When the message is sent, the recipient views the same text the sender viewed when sending it.

Actual results:
4. The cursor disappears.  No text is visible.
5. One can click around in the body area of the compose window, but will not get the cursor back.
6. One can right-click and choose Paste Without Formatting.
7. Then, the desired text appears, and the cursor is at the end of it.
8. One might then edit the message, remove irrelevant parts (including the " - See more at <link>" automatically appended even when the context has a link already), etc. and send the message, expecting the recipient to receive the same message that is visible when it's sent.
9. The recipient, especially if viewing plain text, sees the effect of prior Paste operations, including the "See more at" text and links, and sees content very differently than what the message sender thought they were sending.
URL: http://sigmaxi.org
I can confirm this. I went to https://www.sigmaxi.org/ and pasted
===
New Feature: Professional Collaboration Communities
An exciting opportunity for members to meet and interact online, regardless of their location, for professional collaboration and peer support. 
- See more at: https://www.sigmaxi.org/#sthash.FJoVtjGt.dpuf
===
into a new e-mail composition.

The compose window appears empty.

Using the ThunderHTMLedit add-on (https://addons.mozilla.org/en-us/thunderbird/addon/thunderhtmledit/) I inspected the HTML which is this:

<div style="position: absolute; top: -1999px; left: -1988px;" id="stcpDiv">

With these CSS settings, surely the text won't be displayed.

There is very little we can do about this. We already have bug 1263207 where the copied HTML contains line-height:0 leading to strange effects when replying.

But we can't bend over backwards to sanitise any strange HTML found in the wild and pasted into the composition window.

To me, this is a WONTFIX. Richard, Magnus?
Flags: needinfo?(richard.marti)
Flags: needinfo?(mkmelin+mozilla)
Summary: Pasted content does not appear but is added to message → Pasted content does not appear but is added to message if pasted HTML contains weird absolute positioning with crazy offsets
Strange, here it works. I see no off-screen positioning.

But yes, we can't sanitize every style which is inserted into composer. If we want to do this, we'd had to remove every style pasted in and this would also not be what the user wants. -> for me WONTFIX
Flags: needinfo?(richard.marti)
WOW.  A WONTFIX on this one is a big red flag that TB is absolutely NOT appropriate for use in any professional setting, because the message actually sent could be very different than the message the sender intended and sees, and that's not considered a bug that should be fixed?  I'd think this one would be a reasonably high priority.  

Is there any way the issue could at least be detected and the content not pasted in *at all* until pasted without formatting, so that at least there is a match between what the sender and recipient see?
(In reply to WBT from comment #3)
> Is there any way the issue could at least be detected ...
Many things can be done given time, money and staff, none of which we have.
WONTFIX simply means that we don't consider the issue important enough to warrant spending the scarce resources that he have.

What exactly has happened? The user wanted to send some text from an external website. So they copy/paste the text and it doesn't show up. Now, the appropriate reaction is *not* to press "Send" given that something has gone wrong here. But even if they press "Send", they are sending the text they intended to send, albeit in an unfortunate fashion.

If this is an e-mail to a colleague with the subject "read this", then it's not so bad, right? If it's an e-mail to a customer about a one-million-dollar deal, then they had better check that everything is above board before sending.

It's a bug like many other bugs, but the user has many ways to check the outgoing e-mail. We have worse bugs where bad things happen unnoticed and the user has no way to work around them.
> But even if they press "Send", they are sending the text
> they intended to send, albeit in an unfortunate fashion.
No, that's not true.  They are sending text they did not intend to send, along with some text they did intend to send.  

> If it's an e-mail to a customer about a
> one-million-dollar deal, then they had better check that everything is above
> board before sending.
And the sender has no way to do that when the Compose window is not displaying the message that will be sent. 

> It's a bug like many other bugs, but the user has many ways to check the
> outgoing e-mail. 
What are those ways, particularly accessible to the average user?  Clearly, the user expectation is that the body text displayed in the Compose window exactly matches the body text that will be sent.
(In reply to WBT from comment #5)
> > But even if they press "Send", they are sending the text
> > they intended to send, albeit in an unfortunate fashion.
> No, that's not true.  They are sending text they did not intend to send,
> along with some text they did intend to send.
Why did the paste it then? Just for fun?
 
> > If it's an e-mail to a customer about a
> > one-million-dollar deal, then they had better check that everything is above
> > board before sending.
> And the sender has no way to do that when the Compose window is not
> displaying the message that will be sent.
<control><shift><enter>. Sends to outbox, you can inspect it there. Or simply save a draft. Or use the said add-on.

> > It's a bug like many other bugs, but the user has many ways to check the
> > outgoing e-mail. 
> What are those ways, particularly accessible to the average user?
See above. What is average? Pasting external content is average? But to stop when something seems fishy is advanced, right?

> Clearly,
> the user expectation is that the body text displayed in the Compose window
> exactly matches the body text that will be sent.
That's a nice expectation. However, HTML is essentially code, so if you paste unknown code into the composition, you need to be careful. Or paste it without format.
Nothing stops you copying hidden content from a website, for example "Dear boss, I resign." If the boss views the message in a different way, you might lose your job.

If you type text in, then it will be sent as you saw it, unless you do some CSS trickery yourself.

Looks like you can't convince any developer to fix this, so either:
1) we mark this WONTFIX
2) you fix it yourself or hire someone to do it
3) it goes onto the pile.
1) and 3) are essentially the same.
> Why did the paste it then? Just for fun?
Because they intended to send a smaller subset of the content, and it's usually easier & more accurate to paste-superset-and-delete than retype. 

> <control><shift><enter>. Sends to outbox, you can inspect it there. Or
> simply save a draft. 
Sending to outbox, and looking at the message in the outbox, and you can inspect it to verify that the content is what you think it's going to be, and it shows you that, but does NOT show you the message text the recipient sees.  Same goes for saving as draft, and looking at the draft, or even reopening the draft. The sender just can't see the content that is going to be sent.  Your proposed workarounds don't work. 

> See above. What is average? Pasting external content is average? But to stop
> when something seems fishy is advanced, right?
I think operations like copy and paste and inspect the message one's composing while composing it are within the realm of the "average" user; installing an HTML-inspector add-on and relying on the user to inspect HTML is not.  It's also not necessarily clear that something fishy has necessarily happened.  Maybe the person thinks the paste action just didn't register (slow computer, sticky keyboard, etc.) and can't visibly detect that anything has happened, because nothing's showing, so they Paste Without Formatting and move on with composition.  

> Nothing stops you copying hidden content from a website, for example "Dear
> boss, I resign." If the boss views the message in a different way, you might
> lose your job.
This is an attack vector against TB users.  To see that it's *considered just fine, perfectly normal functioning of the e-mail client* to have it send messages that don't match the message the sender typed in or saw, shows that TB is not appropriate for use in professional settings, or by people who value being able to know and control just what message they are actually e-mailing out.
>> Why did the paste it then? 
It's also worth pointing out that some of the pasted text may not have been copied in the first place, such as the " - See more at <long URL>" that is automatically appended to copied text.

Here's a story from this weekend's "This American Life" about the perils of e-mailing a superset of what one intended to send, as a result of not taking the proper steps with one's e-mail client to prevent that.  There are plenty of other examples where professionalism is important in communication, and demonstrating lack of control over what messages one is sending can be very bad for a person who wants to keep their job.  However, this is just one timely story that very recently had a US national audience.

http://www.thisamericanlife.org/radio-archives/episode/587/the-perils-of-intimacy?act=3
I took the time of listening to the story. A comedian reports having sent dozens of drafts instead of just the final version. Technically this is of course not possible; neither with a desktop client nor via the web interface can you inadvertently send a draft and keep editing. Also, this story has nothing to do with the issue here.

Surely we can fill this space with hundreds of stories where people made mistakes while sending e-mail much to their detriment. <humour>While we're here, lets abolish knives, since they don't only cut vegetables.</humour>
This is similar to bug 504748 (but really about paste, not copy). 
What we could do is have an option for stripping styles altogether, which would in general be useful so you don't mess up your composition with a lot of awful mixed styles from say Word. I think that's the only thing we could do here.
Flags: needinfo?(mkmelin+mozilla)
(In reply to Magnus Melin from comment #10)
> This is similar to bug 504748 (but really about paste, not copy). 
> What we could do is have an option for stripping styles altogether, which
> would in general be useful so you don't mess up your composition with a lot
> of awful mixed styles from say Word. I think that's the only thing we could
> do here.

There is a Paste Without Formatting option that does that and is the correct solution to paste in the content, but that doesn't solve the issue that the message body displayed to the user doesn't match what's sent and viewed by a recipient. 

Are there good use cases for absolute positioning and negative offsets like what's seen here, in an e-mail, which are more important to support than meeting the user expectation that the text sent matches the text shown?  If not, could we just detect and strip out those styles on paste?
Paste is handled by M-C.
(In reply to WBT from comment #11)
> Are there good use cases for absolute positioning and negative offsets like
> what's seen here

It's not just negative offsets; positive ones larger than the size of the compose window might have the same effect.
(In reply to WBT from comment #11)
> There is a Paste Without Formatting option that does that and is the correct
> solution to paste in the content, but that doesn't solve the issue that the
> message body displayed to the user doesn't match what's sent and viewed by a
> recipient. 

How would that be possible? As what you paste is then plain text.

> Are there good use cases for absolute positioning and negative offsets like
> what's seen here, in an e-mail, which are more important to support than
> meeting the user expectation that the text sent matches the text shown?  If
> not, could we just detect and strip out those styles on paste?

It's all or nothing I think.
(In reply to Magnus Melin from comment #14)
> (In reply to WBT from comment #11)
> > There is a Paste Without Formatting option that does that and is the correct
> > solution to paste in the content, but that doesn't solve the issue that the
> > message body displayed to the user doesn't match what's sent and viewed by a
> > recipient. 
> 
> How would that be possible? As what you paste is then plain text.

I'm not quite sure how to parse the question.  Right-click in any Compose window and choose Paste Without Formatting or press CTRL+SHIFT+V to paste as plain text as if you'd just typed those characters in.  This little option isn't obvious, but I use it a lot, especially because there's no format painter.  My point in comment #11 paragraph 1 is "making a Paste Without Formatting option available is (a) already done and (b) not a sufficient solution to this bug." 

> > Are there good use cases for absolute positioning and negative offsets like
> > what's seen here, in an e-mail, which are more important to support than
> > meeting the user expectation that the text sent matches the text shown?  If
> > not, could we just detect and strip out those styles on paste?
> 
> It's all or nothing I think.

It might be all or nothing on "use of absolute positioning in the body of an e-mail" but it seems like we should be able to distinguish that from other kinds of styling (e.g. bold or italic).
(In reply to WBT from comment #15)
> > How would that be possible? As what you paste is then plain text.
> 
> I'm not quite sure how to parse the question.  Right-click in any Compose
> window and choose Paste Without Formatting or press CTRL+SHIFT+V to paste as
> plain text 

Yes, that's what I meant. Paste Without Formatting is a solution to your problem. But you say it's not.

> It might be all or nothing on "use of absolute positioning in the body of an
> e-mail" but it seems like we should be able to distinguish that from other
> kinds of styling (e.g. bold or italic).

Not worth doing it at all since it easily gets extremely complicated. You could have semi-transparent text, hidden text, text that's showing maybe just a few bits, text that's obscured by several layers on top of each other and what not.
(In reply to Magnus Melin from comment #16)
> Paste Without Formatting is a solution to your
> problem. But you say it's not.
Paste Without Formatting is an option that already exists.  Yet, so does the issue described here: a disconnect (and one hidden from the user) between what TB shows them they are about to send or have sent, and what the recipient sees as the message that was sent.  

> Not worth doing it at all since it easily gets extremely complicated. You
> could have semi-transparent text, hidden text, text that's showing maybe
> just a few bits, text that's obscured by several layers on top of each other
> and what not.

Am I hearing this right? "Getting everything right is hard, so we should instead adopt the philosophy of just not doing it at all, because we don't believe it's important for users to be able to know what message they are actually sending."  

If it really is the view of the TB development team, that it's just not important to support user expectations that the text of a message displayed to its drafter/sender match the text that is actually sent, this view needs to be broadcast.  It needs to be made available to people who are making a decision about whether or not to start/continue using TB, so that they can make a more informed decision, which may also take into account how much they care about being able to know what messages they're actually sending.
What I said was it's all or nothing regarding style, or you can't fix it right.
(In reply to Magnus Melin from comment #18)
> What I said was it's all or nothing regarding style, or you can't fix it
> right.

Do you think we really just cannot distinguish between bold text and absolute positioned content rendered outside the view frame of the message?  
I kind of doubt that, given that clearly somewhere in the code the two are distinguished, and the code determines what text will be rendered, which text won't be rendered but would given an alternative scroll bar position, and which text will not be rendered on the screen at all.
See comment #12: Paste is handled in Mozilla Core code also used in Firefox. This is *NOT* a Thunderbird specific problem.
Of course to a certain degree anything is doable with enough effort, but drawing the line what should be preserved would be hard and the effort unreasonably high.
I think that if there exists anything in the third group from the end of Comment 19, the user should at least be alerted "This message contains hidden text" in the same ways as when they have attachment keywords but no attachment.  I would also support the default behavior that if a paste action would change that state, Paste Without Formatting be used instead.  

Surely, the code already exists for parsing styles and deciding what text will be displayed.  If it doesn't, how does that regularly happen?
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #20)
> See comment #12: Paste is handled in Mozilla Core code also used in Firefox.
> This is *NOT* a Thunderbird specific problem.

The Product can be changed, but which Component is it that contains Paste?  The problem does not exist e.g. when pasting into a text box like this one.
Visit http://www-archive.mozilla.org/editor/midasdemo/ in Firefox and paste your content there. Then click "View HTML source".

Now visit the same page in Google Chrome and paste your content there.

Both browsers show nothing.

I'm not sure which component in Mozilla handles "paste", but since were are talking about pasting into a contenteditable element and modifying the pasted content, the Mozilla core component that is responsible for that is Core::Editor.

Here some light reading on Core::Editor to show you that the result will be comment #6 (very bottom) option 3) "it goes onto the pile".

https://groups.google.com/d/msg/mozilla.dev.platform/GKZX7CrUbnY/b1sxG9ZpBgAJ
https://groups.google.com/d/msg/mozilla.governance/-0sAFE-_Us4/8zvhqcrRCAAJ
Component: Message Compose Window → Editor
Product: Thunderbird → Core
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #24)
> Here some light reading on Core::Editor to show you that the result will be
> comment #6 (very bottom) option 3) "it goes onto the pile".
> 
> https://groups.google.com/d/msg/mozilla.dev.platform/GKZX7CrUbnY/b1sxG9ZpBgAJ
> https://groups.google.com/d/msg/mozilla.governance/-0sAFE-_Us4/8zvhqcrRCAAJ

Thanks for these links.  Most of what I would say here, you said at the start of the second one.  Thanks for doing that.
Severity: normal → major
So I ran into this bug, and was mightily embarrassed.  You see, I had been using my IM client.  Then I went over to my thunderbird email compose window.  Apparently I accidentally bumped the paste button on the mouse, but I didn't notice since nothing extra was shown in the compose window.  All my recipients (a distro list at work) saw my private IM (bug 1387203).  I propose a preference option that forces "always text-only paste (no html)".  But since the paste is apparently transparent to Thunderbird (handled by some external library?) well that's an unfortunate non-optimal situation ...
Priority: -- → P3
See Also: → 1720311

Hey WBT,
Can you still reproduce this issue or should we close it?
I tried with the site you've given as example and I can copy paste from it and into an email compose message without issues.

Flags: needinfo?(firstpeterfourten)

I was still dealing with issues like this for years, and then gave up on Thunderbird entirely, so I don't know.

Flags: needinfo?(firstpeterfourten)

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: major → --

(In reply to Magnus Melin [:mkmelin] from comment #14)

It's all or nothing I think.

CSS sanitizers to handle this sort of thing definitely exist. We could do it. We just don't currently have the capability in-tree.

Severity: -- → S3

At my place of work we have just encountered this issue in a slightly different context: the Nextcloud Plugin for BigBlueButton puts a HTML formatted text into the clipboard when copying the password of a BBB room. It looks like this:

$ xclip -o -selection clipboard -t text/html
<meta http-equiv="content-type" content="text/html; charset=utf-8"><span style="border-block: unset; border-inline: unset; border-start-start-radius: unset; border-start-end-radius: unset; border-end-start-radius: unset; border-end-end-radius: unset; overflow-inline: unset; overflow-block: unset; overscroll-behavior-inline: unset; overscroll-behavior-block: unset; margin-block: unset; margin-inline: unset; scroll-margin-block: unset; scroll-margin-inline: unset; padding-block: unset; padding-inline: unset; scroll-padding-block: unset; scroll-padding-inline: unset; inset-block: unset; inset-inline: unset; block-size: unset; min-block-size: unset; max-block-size: unset; inline-size: unset; min-inline-size: unset; max-inline-size: unset; contain-intrinsic-block-size: unset; contain-intrinsic-inline-size: unset; background: unset; background-blend-mode: unset; border: unset; border-radius: unset; box-decoration-break: unset; -moz-float-edge: unset; display: unset; position: fixed; float: unset; clear: unset; vertical-align: unset; baseline-source: unset; overflow: unset; overflow-anchor: unset; transform: unset; rotate: unset; scale: unset; translate: unset; offset: unset; scroll-behavior: unset; scroll-snap-align: unset; scroll-snap-type: unset; scroll-snap-stop: unset; overscroll-behavior: unset; isolation: unset; break-after: unset; break-before: unset; break-inside: unset; resize: unset; perspective: unset; perspective-origin: unset; backface-visibility: unset; transform-box: unset; transform-style: unset; transform-origin: unset; contain: unset; container: unset; appearance: unset; -moz-orient: unset; will-change: unset; shape-image-threshold: unset; shape-margin: unset; shape-outside: unset; touch-action: unset; -webkit-line-clamp: unset; scrollbar-gutter: unset; columns: unset; column-fill: unset; column-rule: unset; column-span: unset; content: unset; counter-increment: unset; counter-reset: unset; counter-set: unset; opacity: unset; box-shadow: unset; clip: rect(0px, 0px, 0px, 0px); filter: unset; backdrop-filter: unset; mix-blend-mode: unset; font: unset; font-synthesis: unset; font-palette: unset; math-depth: unset; math-style: unset; visibility: unset; writing-mode: unset; text-orientation: unset; print-color-adjust: unset; image-rendering: unset; image-orientation: unset; dominant-baseline: unset; text-anchor: unset; color-interpolation: unset; color-interpolation-filters: unset; fill: unset; fill-opacity: unset; fill-rule: unset; shape-rendering: unset; stroke: unset; stroke-width: unset; stroke-linecap: unset; stroke-linejoin: unset; stroke-miterlimit: unset; stroke-opacity: unset; stroke-dasharray: unset; stroke-dashoffset: unset; clip-rule: unset; marker: unset; paint-order: unset; border-collapse: unset; empty-cells: unset; caption-side: unset; border-spacing: unset; color: unset; text-transform: unset; hyphens: unset; -moz-text-size-adjust: unset; text-indent: unset; overflow-wrap: unset; word-break: unset; text-justify: unset; text-align-last: unset; text-align: unset; letter-spacing: unset; word-spacing: unset; white-space: pre; text-shadow: unset; text-emphasis: unset; text-emphasis-position: unset; tab-size: unset; line-break: unset; -webkit-text-fill-color: unset; -webkit-text-stroke: unset; ruby-align: unset; ruby-position: unset; text-combine-upright: unset; text-rendering: unset; text-underline-offset: unset; text-underline-position: unset; text-decoration-skip-ink: unset; hyphenate-character: unset; forced-color-adjust: unset; -webkit-text-security: unset; text-wrap: unset; cursor: unset; pointer-events: unset; -moz-user-input: unset; -moz-user-modify: unset; -moz-user-focus: unset; caret-color: unset; accent-color: unset; color-scheme: unset; scrollbar-color: unset; list-style: unset; quotes: unset; margin: unset; overflow-clip-margin: unset; scroll-margin: unset; outline: unset; outline-offset: unset; page: unset; padding: unset; scroll-padding: unset; top: 0px; right: unset; bottom: unset; left: unset; z-index: unset; flex-flow: unset; place-content: unset; place-items: unset; flex: unset; place-self: unset; order: unset; width: unset; min-width: unset; max-width: unset; height: unset; min-height: unset; max-height: unset; box-sizing: unset; object-fit: unset; object-position: unset; grid-area: unset; grid: unset; gap: unset; aspect-ratio: unset; contain-intrinsic-size: unset; vector-effect: unset; stop-color: unset; stop-opacity: unset; flood-color: unset; flood-opacity: unset; lighting-color: unset; mask-type: unset; clip-path: unset; mask: unset; x: unset; y: unset; cx: unset; cy: unset; rx: unset; ry: unset; r: unset; d: unset; table-layout: unset; text-overflow: unset; text-decoration: unset; ime-mode: unset; scrollbar-width: unset; user-select: text; -moz-window-dragging: unset; -moz-force-broken-image-icon: unset; transition: unset; animation: unset; animation-composition: unset; -moz-box-align: unset; -moz-box-direction: unset; -moz-box-flex: unset; -moz-box-orient: unset; -moz-box-pack: unset; -moz-box-ordinal-group: unset;">jDdXFXme</span>

(I've changed the real password now, obviously.)

When pasting this into a HTML mail being composed this shows up as nothing. At this point I would think that something must have gone wrong when copying the password and would try again. If I don't use the copy button in Nextcloud and instead highlight it and ctrl+c, then everything is fine. As already said in this thread, at this point the compose window no longer shows the message as it will be send out and displayed for others (e.g. OWA does display the above password), and even saving as draft and looking at the mail there will also not display this with the normal HTML view. The simplified HTML and plain text views will, though.

In this specific case I will report this as a bug to the Nextcloud BBB app as well, but I also think this is a security issue in Thunderbird.

Since a website can put potentially arbitrary things into the clipboard when copying it could trick a user into sending an email with different content than they intend to. Since Thunderbird does not show this potentially evil content in the compose window or a normal HTML view it is impossible to do a visual inspection of the mail and check that it is correct. Always checking the source of the mail being written before it is sent is something that I would expect no one to actually do, especially not an average user.

I think Thunderbird should treat the clipboard content as potentially evil third-party input and always sanitize HTML that is being pasted into an email or just strip off any formatting that is there. Just like any website should handle user provided HTML content.

I am using Thunderbird 115.6.0.

You need to log in before you can comment on or make changes to this bug.