64647 - "Paste without Formatting" (plain text) on context menus and edit menu (e-mail & composer)

Status: RESOLVED FIXED

(MailNews Core :: Composition, enhancement, P2)

Description

[Peter Lairo]

cut and paste from one email to another ruins formatting.

When pasting text from a received mail into one I want to SEND, the text is
pasted as "preformat" and not as regular ("body")text. This messes up the entire
composition of the mail.

Pasted text should be pasted as "normal" text and ideally assume the formatting
of the location where it is pasted.

Maybe a rightclick could yield and option to either "paste" or "paste without
formatting". Corel WordPerfect has this since version 6 (4 years old) and is an
excellent feature.

Comment 1

[Keyser Sose]

I am going to change this to an enhancement request since the other option is
marking it as a duplicate. We have a lot of bugs already on formatting problems
but I like the reporters idea about Paste  Without formatting Option.

Comment 2

[Jesse Ruderman]

See also bug 67142, where I suggested a similar option when copying.

Comment 3

[Jean-Francois Ducarroz]

-->varada

Comment 4

[Charles Manske]

This must be duped of bug 46459. Whatever happens in HTML message composer has
to happen in web composer.

*** This bug has been marked as a duplicate of 46459 ***

Comment 5

[Peter Lairo]

Attachment: Context menu of WordPerfect showing the Paste and "Paste without Formatting" options.

WP is the god of context menus - "nobody does it better". ;)

Comment 6

[Jesse Ruderman]

Bug 46459 covers a more complex version of this feature, which would be more
like "Paste Special..." in some word processors.

Comment 7

[Kathleen :Brade]

*** Bug 157065 has been marked as a duplicate of this bug. ***

Comment 8

[Peter Lairo]

"Paste Special..." (as in MS Word 97) sucks (IMO). It forces the user to click
4-times (Edit -> Paste Special... -> select paste option -> OK) instead of
2-times (right-click -> Paste without formatting), and that *at* the location of
the cursor. Plus, paste special (in Word) gives options that are irrelevant most
of the time (e.g., paste as graphic, RTF,...) and only serves to confuse the user.

There are only two scenarios that are relevant:
1. The user will either want to paste using the formatting of the copied text
(me: almost never), or 
2. The user will want the pasted text to have the formatting of the text it's
being pasted into (me: almost always).

Comment 9

[Jesse Ruderman]

AOL Instant Messenger for Windows has "Paste Plaintext" in its context menu but
not in its menubar menu.

Comment 10

[scalkins]

Changing product to Browser/editor as it appears throughout other Netscape apps
also.

Comment 11

[Syd Logan]

nsbeta1+ per buffy triage

Comment 12

[Matthias Versen [:Matti]]

*** Bug 163106 has been marked as a duplicate of this bug. ***

Comment 13

[saari (gone)]

topembed+ as this is requested by an embedding customer

Comment 14

[varada]

re-assigning to default owner of module.

Comment 15

[Akkana Peck]

The original description isn't very clear about what's happening -- is this copy
from a plaintext message and paste into an html compose window?  Joe, is the
copy picking up a <pre> even though not the whole contents of the pre are
selected?  Seems like only text should show up in the paste, not the <pre>
container.

Comment 16

[Jerry Baker]

I can't speak for the original poster, but the problem in the bug I reported
(Bug 157065) is that there is no way to copy text from a Web page and paste it
into a mail message without getting the formatting from the page along with the
text. I ran into this by searching for quotes about a particular subject, and my
intention was to pull a small quote from several sites and paste it into an
email. I got 7 quotes and 7 different fonts and attributes in my mail message.

Comment 17

[Peter Lairo]

It doesn't matter if you are copying from HTML or from plain text, and it
doesn't matter if you are pasting to HTML or to plain text - the pasted text
should always be in the same format as the text at the insertion point.

Comment 18

[Peter Lairo]

Attachment: Screenshot of how "Paste without formatting" should look.

This screenshot shows how "Paste without formatting" should look when pasting
from HTML or plaintext to plaintext or HTML.

Basically, the pasted text should always match the format of the insertion
point.

Comment 19

[Charles Manske]

Peter: I definitely do not agree with claim that pasted HTML-formated text should
*always* match the styles at the insertion point. A user may have copied a 
large section of paragraphs with lots of formating and they certainly wouldn't 
want to loose that when pasting. That effectively means that "paste without
formatting" always happens.
I *do* agree that "Paste without formating" as a menuitem is a good idea. 
The user should which way they want to paste.

Comment 20

[Charles Manske]

Obviously Joe will have to do some core work, but I'll take this bug now and 
do the UI part.

Comment 21

[Jerry Baker]

I think what Peter meant was that pasted text should take on the attributes of
text at the insertion point, but not necessarily the structure. I don't see
anything wrong with copying the structure of the text (CRLFs, etc.) - it's just
copying the style that is at issue here. The separation of presentational markup
from structural markup inherent in the CSS model should make this relatively
easy for Moz...no?

I should mention that when copying text, soft returns (places where text wraps)
should not be hard copied, but hard returns (actual CRLFs in plain text, and
<br> in HTML) should be copied.

Comment 22

[Peter Lairo]

Charls: This bug is requesting "Paste without formatting" in *addition* to
regular "Paste" on context menus and edit menu. Regular "Paste" will still keep
all formatting.

Jerry: Yes, "Paste without formatting" should keep the "structure" (hard returns).

Comment 23

[Joe Francis]

When plasting into a "plaintext" mail composer window, copied html should be 
pasted as plaintext.  If it isn't right now that is a bug and should be easy to 
fix.  I should be able to attach a patch tonight or this weekend.  We need no 
menu item for this, since the user is always expecting plaintext when pasting 
into a plaintext editor.

If you also want different behavior in the html flavor of the editor, that is 
more problematic.  We decided to make copy/paste in html editing be WYSIWYG.  
Doing this gives very well-defined behavior.  While it may seem strange that a 
single unstyled word would remain unstyled when pasted into a run of bold text, 
it starts to make a lot more sense when you consider larger pastes that have 
style changes and even structure changes within the copied data.

If we want to do anything different here I recommend that we:
1) very carefully spec out the behavior
2) make it an option, rather then the default way to paste.

If we can't come up with a good spec or a good name for a menu item, that's 
probably a sign that we just shouldn't go there at all.

You might think that it's easy: simply inherit styles (frm the paste location) 
when the copied data is plaintext, and the paste target is html.  The problem 
with this approach is that the user does not know when their copy is plaintext.  
Plenty of text in a web page looks like plaintext but is really html, and may 
have font styles that we pick up on copy.  If they get different behavior for 
different copy/pastes into the same document with no apparent (to them) reason, 
that will be bad and we will get bug reports on it.

Comment 24

[Joe Francis]

Not sure if Roger cared about this issue or not.  CC'ing him in case...

Comment 25

[Jerry Baker]

I don't think people expect text styles to be inherited from the insertion point
only on plain text. I think they expect it for all text regardless of how it was
formatted where they copied it from. I can't think of a reason to copy style
attributes of text even when pasting into an HTML message. People would
generally have their own formatting in such a message and I can't imagine why
they would want to introduce other formatting simply by pasting.

Comment 26

[Peter Lairo]

Please keep in mind that this bug is *not* talking about what the default
behavior should be. The default "Paste" should always keep the original (source)
formatting.

This bug is about the _choice_ to paste using the format of the target.

Here is my attempt at a *Spec for Paste without Formatting*

Plaintext Mail Compose Window (e.g., for Newsgroups):
----------------------------------------------------
SOURCE     TARGET     PASTE RESULT
----------------------------------
plaintext  plaintext  plaintext
HTML       plaintext  plaintext
plaintext  HTML       <>        <-- scenario doesn't exist
HTML       HTML       <>        <-- scenario doesn't exist

HTML Mail Compose Window (e.g., for e-mail):
-------------------------------------------
SOURCE     TARGET     PASTE RESULT
----------------------------------
plaintext  plaintext  plaintext
HTML       plaintext  plaintext
plaintext  HTML       HTML (format of insertion point)
HTML       HTML       HTML (format of insertion point)


For the sake of completeness, here the *Spec for regular Paste*

Plaintext Mail Compose Window (e.g., for Newsgroups):
----------------------------------------------------
SOURCE     TARGET     PASTE RESULT
----------------------------------
plaintext  plaintext  plaintext
HTML       plaintext  plaintext (and add text-formatting-symbols "*bold*" ...?)
plaintext  HTML       <>        <-- scenario doesn't exist
HTML       HTML       <>        <-- scenario doesn't exist

HTML Mail Compose Window (e.g., for e-mail):
-------------------------------------------
SOURCE     TARGET     PASTE RESULT
----------------------------------
plaintext  plaintext  plaintext
HTML       plaintext  HTML (same as source)
plaintext  HTML       plaintext (fixed width?)
HTML       HTML       HTML (format of source)

NOTE: since in the _Plaintext Mail Compose Window_ the regular "paste" and
"paste without formatting" do the same thing, we can probably hide the "paste
without formatting" in the Plaintext Mail Compose Window.

Comment 27

[Jerry Baker]

Of course none of us will agree on what should be the default. IMO, when I press
CTRL+V, I want it to behave as Peter's "paste without formatting" cases, and I
would want that in all cases regardless of whether I am using HTML or plaintext
composition. This is the behavior I have come to expect from all other
applications I use that paste formatted text. Can we make a pref for the default
paste behavior?

Comment 28

[Peter Lairo]

WordPerfect, MS Word, and Mozilla Composer all do a (regular) "paste" as I have
described (same as source; not as target) when pressing CTRL-V or selecting Edit
> Paste.

Comment 29

[Kathleen :Brade]

Jerry (comment 27)--are you saying that when you cut (or copy) some formatted
text from the message you are writing to paste it elsewhere in the same message,
you want it to paste without any of the formatting?  Or do you never have any
formatting to lose?

Comment 30

[Jerry Baker]

I don't think I've ever had the occasion to copy something from the very same
message I am pasting it into. My problem is consistently with the HTML
composition and copying text from Web pages.

Comment 31

[Akkana Peck]

I very frequently copy/paste from the same document, with the intention of
preserving formatting: for example, I'll use an old document as a template for a
new document, edit the new document and move blocks of html around as suits the
needs of the new document.  Sure, I could do the same thing by having two edit
windows, one on a blank new document and one on the old document, and copying
between them, but in practice it's easier to have just one window open; and in
any case, I'd want to preserve formatting either way.

This is not by any means to argue against offering a "paste without formatting"
option (I have no problem with that) or even to argue which should be the
default (though my hunch is that if people are seeing what they're describing,
enclosing block containers being copied along with the copied text, then we may
have a bug in the copy-context code, and identifying and fixing that might be
better than defaulting to "all-plaintext, all the time", since preserving inline
formatting can be awfully convenient and intuitive).

Comment 32

[Charles Manske]

I'll do the UI for this today.

Comment 33

[Charles Manske]

Taking bug for UI checkin

Comment 34

[Charles Manske]

Attachment: patch for UI and commands v1

Implemented command code for embedding and UI for Composer app.
For now, it simply pastes just like normal paste command.

Comment 35

[mjudge]

Comment on attachment 101839 [details] [diff] [review]
patch for UI and commands v1

looks good to me. straightforward implementation of command.

Comment 36

[Darin Fisher]

Comment on attachment 101839 [details] [diff] [review]
patch for UI and commands v1

>Index: composer/src/nsComposerCommands.cpp

>+nsPasteNoFormattingCommand::IsCommandEnabled(const char * aCommandName, nsISupports *refCon, PRBool *outCmdEnabled)
>+{
>+  nsCOMPtr<nsIHTMLEditor> htmlEditor = do_QueryInterface(refCon);

nit: prefer "nsCOMPtr<nsIHTMLEditor> htmlEditor(do_QueryInterface(refCon));" as
it generates less code / demands less of the optimizer.  same pattern repeats
below.


>+  if (htmlEditor)
>+  {
>+    nsCOMPtr<nsIEditor> editor = do_QueryInterface(htmlEditor);

nit: what if this QI fails?  is any component implementing nsIHTMLEditor
guaranteed to also implement nsIEditor?  this code seems fragile and
is repeated below.


>+    editor->CanPaste(nsIClipboard::kGlobalClipboard, outCmdEnabled);

nit: what if CanPaste fails?  or, are we ok assuming it'll never fail?


>+nsPasteNoFormattingCommand::DoCommand(const char *aCommandName, nsISupports *refCon)
>+{
>+  nsresult rv = NS_ERROR_NOT_IMPLEMENTED;
>+  nsCOMPtr<nsIHTMLEditor> htmlEditor = do_QueryInterface(refCon);
>+  if (htmlEditor)
>+    rv = htmlEditor->PasteNoFormatting(nsIClipboard::kGlobalClipboard);
>+
>+  return rv;
>+}

nit/suggestion: avoid extra assignment to |rv|.

{
  nsCOMPtr<nsIHTMLEditor> htmlEditor(do_QueryInterface(refCon));
  if (!htmlEditor)
    return NS_ERROR_NOT_IMPLEMENTED;
  return htmlEditor->PasteNoFormatting(nsIClipboard::kGlobalClipboard);
}

this pattern repeats below.


>+nsPasteNoFormattingCommand::GetCommandStateParams(const char *aCommandName, nsICommandParams *aParams, nsISupports *refCon)
>+{

>+    aParams->SetBooleanValue(STATE_ENABLED, enabled);

what if aParams is null?  can that never happen?


>Index: idl/nsIHTMLEditor.idl

>+  /** paste the text in the OS clipboard at the cursor position, replacing
>+    * the selected text (if any), but strip out any HTML styles and formatting
>+    */
>+  void pasteNoFormatting(in long aSelectionType);
>+

comment style doesn't conform to convention:

  /**
   * text goes...
   * here.
   */

same here:

>   /** Rebuild the entire document from source HTML
>    *  Needed to be able to edit HEAD and other outside-of-BODY content


>Index: ui/composer/content/ComposerCommands.js

>-  // dump("Updating commands for " + commandset.id + "\n");
>+   // dump("Updating commands for " + commandset.id + "\n");

nit: remove extra space


>+<!ENTITY pasteNoFormatting.label "Paste Without Formatting">
>+<!ENTITY pasteNoFormatting.accesskey "W">

have these changes gone through some sort of UE review?  i don't know
the exact policy these days, and frankly i deal so little with the
frontend code, but i thought that any UE change had to go through 
some sort of UE review.

at any rate, the code itself seems fine to me modulo these few
nits.  fix'em up and sr=darin.

Comment 37

[Charles Manske]

Attachment: patch for UI and commands v2

Fixed all issues pointed out by darin.

Comment 38

[Darin Fisher]

Comment on attachment 101850 [details] [diff] [review]
patch for UI and commands v2

sr=darin

Comment 39

[Charles Manske]

patch for UI and commands v2 checked into 1.2beta trunk.
Over to Joe for implementation of nsIHTMLEditor::PasteNoFormatting()

Comment 40

[Peter Lairo]

One more thing that is important, and perhaps not obvious for the specs in
comment #26:

Msg compose seems to switch from plaintext to HTML (without the user sometimes
really getting clear feedback about this :( ) as soon as HTML text is pasted
into a previously plaintext message.

So here goes:
If a user copies an HTML textblock and pastes it "without formatting" into his
currently plaintext message, then the message must remain plaintext!!!

Comment 41

[Joe Francis]

Peter, I am unable to get html to paste into plaintext mail compose as anything
other than plaintext.  I was going to file a bug on that issue but I cannot
reproduce the bug.  I tried on trunk and also on NS7.

If anyone can get html to poaste into plaintext mail compose as anything other
than text, please open a bug against me with a testcase.  thanks.

Comment 42

[Frank Burleigh]

I am unsure whether this is standardized, but I've come to expect Ctrl+Shift+V
to do Paste Unformatted (at least from wordperfect).

Comment 43

[Peter Lairo]

My comment wans't clear enough. Sorry.

When composing mail in the HTML-enabled editor, but as long as you don't enter
any HTML codes (e.g., bold), the mail will be sent as plain text. This is (for
me at least) the most common scenario.

Therefore, pasting without formatting should not cause a _potentially_ (but not
yet) HTML mail to become HTML. Clear as mud? :-\

Comment 44

[Charles Manske]

The Ctrl+Shift+V soulds ok with me. Doesn't seem to do anthing else that I can
find.
About pasting HTML into plaintext. We actually don't editor "plaintext" perse,
but edit within <pre> tags, so it's not surprising that pasting HTML would 
"wake up" full HTML editing on the pasted content. 
Joe can explain better and figure out what to do. Maybe we should always call
"PasteNoFormatting() when pasting within a plaintext context?

Comment 45

[Peter Lairo]

> ... always call "PasteNoFormatting() when pasting within a plaintext context?

No, because users will expect (and often specifically want) a regular paste to
maitain the source formatting (as is does in all their other applications).

Also, users are often not aware that they are still in "plaintext mode" and
would be confused if they couldn't properly "paste" formatted text.

That is (also) why we need "paste without formatting".

Comment 46

[Jerry Baker]

> No, because users will expect (and often specifically want) a regular paste to
> maitain the source formatting (as is does in all their other applications).

That doesn't make any sense. When I paste from WordPerfect into Notepad, I never
expect that the text will have the format of the source text. It is plain text,
and I expect that.

I still think it is odd to expect a paste to ever have the properties of the
source text in any situation, but I can see how some people might want that.

Comment 47

[Peter Lairo]

Notepad *cannot* do anything but plaintext. Mozilla has the pref "compose
messages in HTML format". Mozilla (in HTML mode) can operate as *both* an HTML
composer *and* as a plain text composer. That is why your example is meaningless.

(Fortunately) Mozilla will send an e-mail as plain text, as long as no
formatting has been added to the message, even with the "HTML" pref set.

[OT]
Jerry, every one of your comments (except the first two) have demonstrated your
lack of understanding of this bug. I (kindly) urge you to read the comments more
carefully. 
AHA! I just saw your duped bug 157065. You don't want formatting to be copied.
Well, THIS bug is requesting just THAT, except that you seem to want the
"regular copy" to paste without formatting. That is an unrealistic wish, because
it is non-standard copy behavior (as explained multiple times here already -
"WordPerfect, Word,...). This bug will ADD the functionality you want (in
ADDITION to paste WITH formatting). If you would stop posting incorrect and
misleading comments here, this bug might get fixed, and you would get what you
wanted. ;)
[/OT]

Comment 48

[Jerry Baker]

Dude. You're being a spaz. Notepad can do HTML. Try it. Type <h1>Text</h1> in
Notepad and save it. But, following your reasoning, Mozilla's plain text compose
doesn't do HTML either, and you are asking it to. Why?

Comment 49

[Peter Lairo]

Nope, notepad in win98 just shows "<h1>Text</h1>" (no formatting), but this was
not the relevant point anyhow.

> Mozilla's plain text compose doesn't do HTML either, and you are asking it to.

Jerry, please read my comment #26 very carefully and slowly (particularly the
first table (of the four): "Plaintext Mail Compose Window").

Comment 50

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 51

[Joe Francis]

Attachment: patch to editor/libeditor/html/nsHTMLDataTransfer.cpp

implementation of PasteNoFormatting()

Comment 52

[Joe Francis]

need reviews for small patch

Comment 53

[Simon Fraser [no longer active]]

+    // Get the Data from the clipboard  
+    if (NS_SUCCEEDED(clipboard->GetData(trans, aSelectionType)) && IsModifiable())

Are we always sure that the passed-in aSelectionType will correspond with a data
type in the transferable?

+      rv = InsertFromTransferable(trans, nsAutoString(), nsAutoString());

I think using nsString() is more efficient than nsAutoString, since empty
nsString()s share a static buffer.

Otherwise, looks good.

Comment 54

[Akkana Peck]

Comment on attachment 104580 [details] [diff] [review]
patch to editor/libeditor/html/nsHTMLDataTransfer.cpp

Personally I much prefer the
rv = ...;
NS_ENSURE_SUCCESS(rv, rv);
style rather than multiple levels of (if (NS_SUCCEEDED(rv)) nesting, but I
guess you're the one who spends the most time maintaining this code, so your
call. 

If !IsModifiable(), we'll return NS_OK without having inserted anything; is
that the intent?

r=akkana regardless, it's certainly closer than what's currently there ...

Comment 55

[Joe Francis]

heh, I prefer Akkana's approach as well.  I was keeping the same style as the
original code in Paste().  I thought about factoring it out but it didn't seem
to cross the (number of uses) * (number of lines) threshold.  I guess I could
change both places, or do a pass on the whole file.  :-)

Thanks for the tip in nsString construction, Simon.  I'll change that.

As for aSelectionType, that is an oddly named param - again, I recycled the name
from Paste(). It really means which clipboard to get the data from.  I'm not
sure what you mean by your comment: if we ask for a clipboard that isn't
available, we'll get an error, which is detected.  Is there something more you
think should be done?  It doesn't have anything to do with the data type for the
transferable: that is specified in the transferable itself.  That info is filled
out in PrepareTransferable() which you can see in the patch is called prior to
GetData().

This param is passed in from outside the editor, so I don't have much control
over it.  I believe it's only use is to allow the calling code to specify that
the "selection clipboard" is to be used on linux/unix for middle mouse paste (or
whichever shortcut they use).

Comment 56

[Joe Francis]

fix landed on trunk

Comment 57

[Christian :Biesinger (don't email me, ping me on IRC)]

>NS_ENSURE_SUCCESS(rv, rv);
>style rather than multiple levels of (if (NS_SUCCEEDED(rv)) nesting

You should be aware that NS_ENSURE_SUCCESS is not equivalent to if (NS_FAILED
(rv)) return rv; because ENSURE_SUCCESS includes an ASSERTION(NS_SUCCEEDED
(rv)), which might not always be what you want.

Comment 58

[Peter Lairo]

This bug is marked fixed and comment 56 form 7.11. says: "fix landed on trunk".
However, the nightly build from 11.11.2002 (win98, sea) doesn't have "Paste
without Formatting" in the context menu or the edit menu. :-\ Why?

Also, please see bug 169586 comment 13 for a possible contradiction between
these two bugs.

Comment 59

[Charles Manske]

Peter: are you using a Mail Composer or Web Composer?

Comment 60

[Joe Francis]

Note that there is no reason why Paste and Paste Without Formatting can't give
the same result in some cases, or alternatively, Paste Without Formatting could
be disabled if Paste would give the same result (I prefer the former though).

Comment 61

[Peter Lairo]

Charles: I use (and and talking primalily about) the e-mail composer.

JF: yes, paste & paste without formatting *can* (rarely) give the same results
(I have stated this in my specs table in comment 26. For example (HTML compose):

SOURCE     TARGET     PASTE RESULT
----------------------------------
plaintext  plaintext  plaintext

By "plaintext" in an HTML document I mean the pasted text should appear as if
the user had selected the text and selected: Format > Remove all text styles.

Comment 62

[Charles Manske]

Peter: The Mail Composer has a completely different context menu, so please 
file a bug on "MailNews", component="Composition" to request that they add
the "Paste without formating" item to their menu.

Comment 63

[Peter Lairo]

HUH, *I* filed this bug explicitly to add "paste without formatting" to e-mail!

I may have filed it into the wrong component almost two years ago, but my *very
first* summary is quite clear as to which component was meant: 

> cut and paste from one *email* to another ruins formatting.

Is there any way to remedy this unfortunate situation? I would hate to have to
file a new bug and go through all this again.

Comment 64

[Charles Manske]

Peter: Filing a new bug isn't a very big deal, but I'll be happy to reopen this
and redirect to the mailnews component :)

Comment 65

[Joe Francis]

over to mail

Comment 66

[Joe Francis]

assigning to mail folks

Comment 67

[Peter Lairo]

JF: I don't mind filing a new bug for this. Which would be motre likely to
expedite a fix for mail-compose (new bug or leave here)?

Comment 68

[Bryce Mozilla Nesbitt]

Yes please, we need "paste as plain text" everywhere rich text is used.

For email "convert message to plain text" would also help (as opposed to the
less powerful "discontinue text styles" option).  I often find a table, or other
html, gets pasted into email.  I end up retyping stuff to avoid Mozilla's
attempt to paste HTML.

Comment 69

[Jean-Francois Ducarroz]

Comment on attachment 104580 [details] [diff] [review]
patch to editor/libeditor/html/nsHTMLDataTransfer.cpp

this patch has already benn checked in

Comment 70

[Jean-Francois Ducarroz]

reassign to varada for adding the menuitem in message compose

Comment 71

[Peter Lairo]

Varda, since all the code is already there (in composer), do you think we can
expect this useful feature soon?

Comment 72

[(not reading, please use [e-mail] instead)]

taking all of varada's bugs.

Comment 73

[Jesse Ruderman]

Filed bug 192330, "keyboard shortcut (Ctrl+Shift+V) for 'paste without formatting'."

Comment 74

[Peter Lairo]

This would be great for 1.3

Comment 75

[Jesse Ruderman]

See also bug 192359, "typing after pasting should not use formatting of pasted
text".  Fixing that would reduce (but not eliminate) the need for "paste without
formatting" and would be helpful for users who don't know about the "paste
without formatting" command.

Comment 76

[Peter Lairo]

Fixing bug 192359 would not reduce the need for "Paste without Formatting" for
me at all. I usually don't want the formatting of the copied text at all.

Comment 77

[Asa Dotzler [:asa]]

Peter, please don't nominate new features for fixing in a final cycle. Final
cycles are for polish and cleanup, not for feature work.

Comment 78

[Charles Rosendahl]

No longer an enhancement. Now a regular bug. Nominating topembed - please
contact me as to why.

Comment 79

[Kathleen :Brade]

I disagree that this bug is an embedding issue.  This bug is a mozilla UI issue.
 Embedders have an api that they can use.  If that api is insufficient, a new
bug should be filed.

Comment 80

[Kathleen :Brade]

resetting to enhancement; this is an enhancement/feature

Comment 81

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 82

[Jesse Ruderman]

*** Bug 200895 has been marked as a duplicate of this bug. ***

Comment 83

[Robert La Ferla]

I am sick of Mozilla pasting tables when I just want the text.  We need this
feature.

Comment 84

[Joachim Noreiko]

I would like an option to *always* paste as plain text into emails.

This is particularly annoying when copying from a web page, and the email
compose box acquires GIANT H1 text.

What is needed is an option "Compose emails in plain text", which changes the
bahaviour of the compose box. 

The vertical blue lines that marked quoted text behave oddly too -- I get spare
lines above and below, and removing them sometimes makes several paragraphs or
lines become "unquoted" -- The "Compose emails in plain text" setting should
provide old-fashioned ">" characters to mark quotation.

Comment 85

[Robert La Ferla]

"The vertical blue lines that marked quoted text" problem should be filed as a
separate bug.  E-mail me the new bug # because I want to be on the CC for it.  I
find it highly annoying but the original problem of always pasting w/formatting
is *MOST* annoying.

Comment 86

[kinmoz]

> What is needed is an option "Compose emails in plain text", which changes the
> bahaviour of the compose box. 

In a mail window select Edit->Mail & Newsgroup Account Settings... menu item. In
the window that comes up, click on the name of the mail account you want "plain
text" composing to be active in, and make sure the "Compose messages in HTML
format" checkbox is unchecked.

-or-

Hold down the shift key when pressing the "Compose" button on the mail toolbar
and that will bring up a compose window that is the opposite of the "Compose
messages in HTML format" checkbox's current setting.

Comment 87

[[e-mail]]

Attachment: Message Compose portion of patch

This should be all that's necessary to get PWF into message compose.

I put it between paste and paste quote but it could easily be moved.

Comment 88

[[e-mail]]

Comment on attachment 131175 [details] [diff] [review]
Message Compose portion of patch

cmanske thoughtfully put the label and accesskey on the command thus unlike the
rest of the context menu we don't have to duplicate them. Woohoo!

Comment 89

[[e-mail]]

Fix checked into the trunk, feel free to request this for 1.4/1.5

Comment 90

[Uri Dor]

please forgive my ignorance, but how do I request it for 1.4/1.5 ?

Comment 91

[Peter Lairo]

Removing request to block 1.4.1 and 1.5
Added request to approve patch in 1.4.1 and 1.5 (sorry for bugspam)

Comment 92

[Jerry Baker]

Why is "Paste without formatting" only available in the HTML compose and not in
the plain-text compose window?

Comment 93

[Robert La Ferla]

I do not know the answer but I would hope that in a plain-text compose window,
the paste command would default to "without formatting".

Comment 94

[Asa Dotzler [:asa]]

Comment on attachment 131175 [details] [diff] [review]
Message Compose portion of patch

It's too late for features.

Comment 95

[Karsten Düsterloh]

The accesskey W collides with the often used "Rewrap" entry of this menu in the
plain text editor. Spinning off new bug 220272.

Comment 96

[Peter Lairo]

It seems that "Paste Without Formatting" is now available in Thunderbird's
e-mail compose. WOOHOO. :) I haven't tested Mozilla Suite yet, anyone know?

Comment 97

[Olivier Vit (just a reporter)]

available in Mozilla 1.6a also
Great news !!

Comment 98

[Peter Lairo]

For those of who might be interested in having a keyboard shortcut
(Ctrl+Shift+V) for "Paste Without Formatting" (since while composing your hands
are usualy already on the keyboard), see bug 273008 (Thunderbird) and bug 192330
(Suite) (to CC, vote and/or code). ;-)

Comment 99

[James Lampert]

It seems to me that this whole issue is between the keyboard and the chair.

ALL paste operations should be unformatted, because ALL email should be pure text: HTML is for web pages, NOT for email. Anybody whose email reader is configured to display HTML by default is just begging to be sent something with a nasty payload, and anybody who has it configured to send HTML by default is just wasting bandwidth.

And this business of remapping an already-established keyboard shortcut into a menu item that's of questionable utility (I have yet to see a situation in which it isn't grayed-out!), without providing a built-in way to revert it, makes me think somebody's been DRINKING a little too much T-Bird. Didn't anybody even consider that the entirely new function should be the one to get an entirely new keyboard shortcut?

Thankfully, "keyconfig" still seems to work just fine on T-Bird 17. It just has to be downloaded to a file, then installed from a file.

Comment 100

[Peter Lairo]

(In reply to James Lampert from comment #99)

> because ALL email should be pure text

My ears are bleeding. Someone from the early 90s has timewarped into the present and wants to take us back with them.

Dude, this bug is FIXED (and has been discussed extensively). Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html particularly the part "Unless you have something *new* to contribute".

Welcome to 2013 where our gmail accounts have 10 GB and our DSL is 16 MB/sec. Bandwidth? Who needs to conserve bandwidth? And if you (few) do: View / Message Body As / Plain Text.

OK, now ... Back to the Future.