Closed Bug 64647 Opened 24 years ago Closed 21 years ago

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

Categories

(MailNews Core :: Composition, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Peter, Assigned: sspitzer)

References

Details

(Whiteboard: Code is already available in "Composer" (simple fix?))

Attachments

(3 files, 3 obsolete files)

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.
Keywords: mozilla0.8
Whiteboard: DUPEME
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.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: cut and paste from one email to another ruins formatting → [RFE] Paste w/out Formatting Option
Whiteboard: DUPEME
See also bug 67142, where I suggested a similar option when copying.
-->varada
Assignee: ducarroz → varada
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Summary: [RFE] Paste w/out Formatting Option → [RFE] "Paste without Formatting" Option (context menus & Edit menu)
WP is the god of context menus - "nobody does it better". ;)
Bug 46459 covers a more complex version of this feature, which would be more like "Paste Special..." in some word processors.
Blocks: 46459
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: [RFE] "Paste without Formatting" Option (context menus & Edit menu) → [RFE] Paste without Formatting (on context menus and edit menu)
Keywords: mozilla1.1
Summary: [RFE] Paste without Formatting (on context menus and edit menu) → [RFE] Paste without Formatting (plain text) on context menus and edit menu
*** Bug 157065 has been marked as a duplicate of this bug. ***
Blocks: 158464
"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).
AOL Instant Messenger for Windows has "Paste Plaintext" in its context menu but not in its menubar menu.
Changing product to Browser/editor as it appears throughout other Netscape apps also.
Component: Composition → Editor: Composer
Product: MailNews → Browser
Keywords: nsbeta1
nsbeta1+ per buffy triage
No longer blocks: 46459
Severity: enhancement → critical
Status: REOPENED → ASSIGNED
Depends on: 46459
Keywords: nsbeta1nsbeta1+
Target Milestone: --- → mozilla1.2alpha
Summary: [RFE] Paste without Formatting (plain text) on context menus and edit menu → [RFE] "Paste without Formatting" (plain text) on context menus and edit menu
*** Bug 163106 has been marked as a duplicate of this bug. ***
topembed+ as this is requested by an embedding customer
Keywords: topembed+
re-assigning to default owner of module.
Assignee: varada → syd
Status: ASSIGNED → NEW
QA Contact: pmock → sujay
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.
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.
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.
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.
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.
Assignee: syd → cmanske
Target Milestone: mozilla1.2alpha → mozilla1.2beta
Obviously Joe will have to do some core work, but I'll take this bug now and do the UI part.
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.
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).
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.
Not sure if Roger cared about this issue or not. CC'ing him in case...
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.
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.
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?
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.
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?
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.
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).
I'll do the UI for this today.
Assignee: cmanske → jfrancis
Taking bug for UI checkin
Assignee: jfrancis → cmanske
Whiteboard: [FIX IN HAND] need r=,sr=
Attached patch patch for UI and commands v1 (obsolete) (deleted) — Splinter Review
Implemented command code for embedding and UI for Composer app. For now, it simply pastes just like normal paste command.
Comment on attachment 101839 [details] [diff] [review] patch for UI and commands v1 looks good to me. straightforward implementation of command.
Attachment #101839 - Flags: review+
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.
Attachment #101839 - Flags: needs-work+
Attached patch patch for UI and commands v2 (obsolete) (deleted) — Splinter Review
Fixed all issues pointed out by darin.
Attachment #101839 - Attachment is obsolete: true
Comment on attachment 101850 [details] [diff] [review] patch for UI and commands v2 sr=darin
Attachment #101850 - Flags: superreview+
patch for UI and commands v2 checked into 1.2beta trunk. Over to Joe for implementation of nsIHTMLEditor::PasteNoFormatting()
Assignee: cmanske → jfrancis
Attachment #101850 - Attachment is obsolete: true
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!!!
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.
I am unsure whether this is standardized, but I've come to expect Ctrl+Shift+V to do Paste Unformatted (at least from wordperfect).
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? :-\
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?
> ... 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".
> 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.
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]
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?
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").
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: critical → enhancement
Summary: [RFE] "Paste without Formatting" (plain text) on context menus and edit menu → "Paste without Formatting" (plain text) on context menus and edit menu
implementation of PasteNoFormatting()
need reviews for small patch
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2beta → M1
+ // 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 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 ...
Attachment #104580 - Flags: review+
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).
fix landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago22 years ago
Resolution: --- → FIXED
>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.
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.
Peter: are you using a Mail Composer or Web Composer?
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).
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.
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.
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.
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 :)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
over to mail
Component: Editor: Composer → Composition
Product: Browser → MailNews
Target Milestone: M1 → ---
Version: Trunk → other
assigning to mail folks
Assignee: jfrancis → ducarroz
Status: REOPENED → NEW
QA Contact: sujay → esther
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)?
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 on attachment 104580 [details] [diff] [review] patch to editor/libeditor/html/nsHTMLDataTransfer.cpp this patch has already benn checked in
Attachment #104580 - Attachment is obsolete: true
reassign to varada for adding the menuitem in message compose
Assignee: ducarroz → varada
Whiteboard: [FIX IN HAND] need r=,sr=
Varda, since all the code is already there (in composer), do you think we can expect this useful feature soon?
taking all of varada's bugs.
Assignee: varada → sspitzer
Keywords: topembed+
Whiteboard: Code is already available in "Composer" (simple fix?)
Filed bug 192330, "keyboard shortcut (Ctrl+Shift+V) for 'paste without formatting'."
This would be great for 1.3
Flags: blocking1.3b?
Flags: blocking1.3?
Flags: blocking1.3b?
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.
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.
Peter, please don't nominate new features for fixing in a final cycle. Final cycles are for polish and cleanup, not for feature work.
Flags: blocking1.3? → blocking1.3-
No longer an enhancement. Now a regular bug. Nominating topembed - please contact me as to why.
Severity: enhancement → normal
Keywords: topembed
Priority: -- → P2
Whiteboard: Code is already available in "Composer" (simple fix?) → edt_x3; Code is already available in "Composer" (simple fix?)
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.
resetting to enhancement; this is an enhancement/feature
Severity: normal → enhancement
Keywords: topembed
Whiteboard: edt_x3; Code is already available in "Composer" (simple fix?) → Code is already available in "Composer" (simple fix?)
Mail triage team: nsbeta1-
Keywords: nsbeta1+nsbeta1-
*** Bug 200895 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.3
Flags: blocking1.3- → blocking1.4b?
Flags: blocking1.4b? → blocking1.4b-
I am sick of Mozilla pasting tables when I just want the text. We need this feature.
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.
"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.
> 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.
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 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!
Attachment #131175 - Flags: superreview?(bienvenu)
Attachment #131175 - Flags: review?(scott)
Attachment #131175 - Flags: superreview?(bienvenu) → superreview+
Attachment #131175 - Flags: review?(scott) → review+
Fix checked into the trunk, feel free to request this for 1.4/1.5
Status: NEW → RESOLVED
Closed: 22 years ago21 years ago
Resolution: --- → FIXED
please forgive my ignorance, but how do I request it for 1.4/1.5 ?
Flags: blocking1.5?
Flags: blocking1.4.1?
Summary: "Paste without Formatting" (plain text) on context menus and edit menu → "Paste without Formatting" (plain text) on context menus and edit menu (e-mail & composer)
Attachment #131175 - Flags: approval1.5?
Attachment #131175 - Flags: approval1.4.1?
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)
Flags: blocking1.5?
Flags: blocking1.4.1?
Why is "Paste without formatting" only available in the HTML compose and not in the plain-text compose window?
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 on attachment 131175 [details] [diff] [review] Message Compose portion of patch It's too late for features.
Attachment #131175 - Flags: approval1.5?
Attachment #131175 - Flags: approval1.5-
Attachment #131175 - Flags: approval1.4.1?
Attachment #131175 - Flags: approval1.4.1-
The accesskey W collides with the often used "Rewrap" entry of this menu in the plain text editor. Spinning off new bug 220272.
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?
available in Mozilla 1.6a also Great news !!
Product: MailNews → Core
No longer blocks: 158464
Blocks: 158464
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). ;-)
Product: Core → MailNews Core
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.
(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.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: