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)
MailNews Core
Composition
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)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
patch
|
mscott
:
review+
Bienvenu
:
superreview+
asa
:
approval1.4.1-
asa
:
approval1.5-
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•24 years ago
|
Keywords: mozilla0.8
Updated•24 years ago
|
Whiteboard: DUPEME
Reporter | ||
Updated•24 years ago
|
Comment 1•24 years ago
|
||
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
Keywords: helpwanted,
mail6,
mozilla0.8,
nsbeta1
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
QA Contact: esther → pmock
Comment 4•23 years ago
|
||
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
Reporter | ||
Updated•23 years ago
|
Summary: [RFE] Paste w/out Formatting Option → [RFE] "Paste without Formatting" Option (context menus & Edit menu)
Reporter | ||
Comment 5•23 years ago
|
||
WP is the god of context menus - "nobody does it better". ;)
Comment 6•23 years ago
|
||
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)
Reporter | ||
Updated•23 years ago
|
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
Comment 7•22 years ago
|
||
*** Bug 157065 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 8•22 years ago
|
||
"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•22 years ago
|
||
AOL Instant Messenger for Windows has "Paste Plaintext" in its context menu but
not in its menubar menu.
Comment 10•22 years ago
|
||
Changing product to Browser/editor as it appears throughout other Netscape apps
also.
Component: Composition → Editor: Composer
Product: MailNews → Browser
Comment 11•22 years ago
|
||
nsbeta1+ per buffy triage
Reporter | ||
Updated•22 years ago
|
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
Comment 12•22 years ago
|
||
*** Bug 163106 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
topembed+ as this is requested by an embedding customer
Keywords: topembed+
Comment 14•22 years ago
|
||
re-assigning to default owner of module.
Assignee: varada → syd
Status: ASSIGNED → NEW
QA Contact: pmock → sujay
Comment 15•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 17•22 years ago
|
||
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.
Reporter | ||
Comment 18•22 years ago
|
||
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•22 years ago
|
||
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
Comment 20•22 years ago
|
||
Obviously Joe will have to do some core work, but I'll take this bug now and
do the UI part.
Comment 21•22 years ago
|
||
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.
Reporter | ||
Comment 22•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Not sure if Roger cared about this issue or not. CC'ing him in case...
Comment 25•22 years ago
|
||
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.
Reporter | ||
Comment 26•22 years ago
|
||
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•22 years ago
|
||
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?
Reporter | ||
Comment 28•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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 33•22 years ago
|
||
Taking bug for UI checkin
Assignee: jfrancis → cmanske
Whiteboard: [FIX IN HAND] need r=,sr=
Comment 34•22 years ago
|
||
Implemented command code for embedding and UI for Composer app.
For now, it simply pastes just like normal paste command.
Comment 35•22 years ago
|
||
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 36•22 years ago
|
||
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+
Comment 37•22 years ago
|
||
Fixed all issues pointed out by darin.
Attachment #101839 -
Attachment is obsolete: true
Comment 38•22 years ago
|
||
Comment on attachment 101850 [details] [diff] [review]
patch for UI and commands v2
sr=darin
Attachment #101850 -
Flags: superreview+
Comment 39•22 years ago
|
||
patch for UI and commands v2 checked into 1.2beta trunk.
Over to Joe for implementation of nsIHTMLEditor::PasteNoFormatting()
Assignee: cmanske → jfrancis
Updated•22 years ago
|
Attachment #101850 -
Attachment is obsolete: true
Reporter | ||
Comment 40•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
I am unsure whether this is standardized, but I've come to expect Ctrl+Shift+V
to do Paste Unformatted (at least from wordperfect).
Reporter | ||
Comment 43•22 years ago
|
||
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•22 years ago
|
||
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?
Reporter | ||
Comment 45•22 years ago
|
||
> ... 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•22 years ago
|
||
> 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.
Reporter | ||
Comment 47•22 years ago
|
||
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•22 years ago
|
||
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?
Reporter | ||
Comment 49•22 years ago
|
||
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•22 years ago
|
||
[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
Comment 51•22 years ago
|
||
implementation of PasteNoFormatting()
Comment 52•22 years ago
|
||
need reviews for small patch
Status: NEW → ASSIGNED
Target Milestone: mozilla1.2beta → M1
Comment 53•22 years ago
|
||
+ // 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•22 years ago
|
||
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+
Comment 55•22 years ago
|
||
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•22 years ago
|
||
fix landed on trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
Comment 57•22 years ago
|
||
>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.
Reporter | ||
Comment 58•22 years ago
|
||
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•22 years ago
|
||
Peter: are you using a Mail Composer or Web Composer?
Comment 60•22 years ago
|
||
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).
Reporter | ||
Comment 61•22 years ago
|
||
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•22 years ago
|
||
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.
Reporter | ||
Comment 63•22 years ago
|
||
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•22 years ago
|
||
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 → ---
Comment 65•22 years ago
|
||
over to mail
Component: Editor: Composer → Composition
Product: Browser → MailNews
Target Milestone: M1 → ---
Version: Trunk → other
Comment 66•22 years ago
|
||
assigning to mail folks
Assignee: jfrancis → ducarroz
Status: REOPENED → NEW
QA Contact: sujay → esther
Reporter | ||
Comment 67•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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
Comment 70•22 years ago
|
||
reassign to varada for adding the menuitem in message compose
Assignee: ducarroz → varada
Whiteboard: [FIX IN HAND] need r=,sr=
Reporter | ||
Comment 71•22 years ago
|
||
Varda, since all the code is already there (in composer), do you think we can
expect this useful feature soon?
Reporter | ||
Updated•22 years ago
|
Whiteboard: Code is already available in "Composer" (simple fix?)
Comment 73•22 years ago
|
||
Filed bug 192330, "keyboard shortcut (Ctrl+Shift+V) for 'paste without formatting'."
Reporter | ||
Comment 74•22 years ago
|
||
This would be great for 1.3
Flags: blocking1.3b?
Flags: blocking1.3?
Reporter | ||
Updated•22 years ago
|
Flags: blocking1.3b?
Comment 75•22 years ago
|
||
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.
Reporter | ||
Comment 76•22 years ago
|
||
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•22 years ago
|
||
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-
Comment 78•22 years ago
|
||
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?)
Comment 79•22 years ago
|
||
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•22 years ago
|
||
resetting to enhancement; this is an enhancement/feature
Updated•22 years ago
|
Whiteboard: edt_x3; Code is already available in "Composer" (simple fix?) → Code is already available in "Composer" (simple fix?)
Comment 82•22 years ago
|
||
*** Bug 200895 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Keywords: mozilla1.3
Reporter | ||
Updated•22 years ago
|
Flags: blocking1.3- → blocking1.4b?
Updated•22 years ago
|
Flags: blocking1.4b? → blocking1.4b-
Comment 83•21 years ago
|
||
I am sick of Mozilla pasting tables when I just want the text. We need this
feature.
Comment 84•21 years ago
|
||
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•21 years ago
|
||
"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•21 years ago
|
||
> 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•21 years ago
|
||
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•21 years ago
|
||
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)
Updated•21 years ago
|
Attachment #131175 -
Flags: superreview?(bienvenu) → superreview+
Updated•21 years ago
|
Attachment #131175 -
Flags: review?(scott) → review+
Comment 89•21 years ago
|
||
Fix checked into the trunk, feel free to request this for 1.4/1.5
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Comment 90•21 years ago
|
||
please forgive my ignorance, but how do I request it for 1.4/1.5 ?
Reporter | ||
Updated•21 years ago
|
Flags: blocking1.5?
Flags: blocking1.4.1?
Reporter | ||
Updated•21 years ago
|
Keywords: mozilla1.0.2,
nsbeta1-
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)
Reporter | ||
Updated•21 years ago
|
Attachment #131175 -
Flags: approval1.5?
Attachment #131175 -
Flags: approval1.4.1?
Reporter | ||
Comment 91•21 years ago
|
||
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?
Comment 92•21 years ago
|
||
Why is "Paste without formatting" only available in the HTML compose and not in
the plain-text compose window?
Comment 93•21 years ago
|
||
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•21 years ago
|
||
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-
Comment 95•21 years ago
|
||
The accesskey W collides with the often used "Rewrap" entry of this menu in the
plain text editor. Spinning off new bug 220272.
Reporter | ||
Comment 96•21 years ago
|
||
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•21 years ago
|
||
available in Mozilla 1.6a also
Great news !!
Updated•20 years ago
|
Product: MailNews → Core
Reporter | ||
Comment 98•19 years ago
|
||
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). ;-)
Updated•16 years ago
|
Product: Core → MailNews Core
Comment 99•12 years ago
|
||
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.
Reporter | ||
Comment 100•12 years ago
|
||
(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.
Description
•