Closed Bug 410986 Opened 17 years ago Closed 14 years ago

Add ability to paste HTML as plain text

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- -

People

(Reporter: NicolasWeb, Assigned: ehsan.akhgari)

References

(Blocks 1 open bug)

Details

(Whiteboard: [parity-chrome])

Attachments

(4 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; fr; rv:1.9b2) Gecko/2007121014 Firefox/3.0b2

Adding the ability to adapt text formating when pasting text will improve inline editing (blog, wiki) user experience.

Reproducible: Always

Steps to Reproduce:
1.Copy rich text (with color, high, font)
2.Past it in a blog post text editor like TinyMCE (Joomla! use it)
3.
Actual Results:  
Paste with initial format and give no way to change it

Expected Results:  
Give a way to change the pasted format, maybe with a floating & mouse over control (like in MS Office or Acrobat Pro) :
 - by enabling/disabling attributes like bold, italic, h1, ... (maybe with a way to uncheck all at the same time)
 or
 - by level of rich complexity : plain text, RTF, ... (like in OOo)
Version: unspecified → Trunk
I think it mustn't be done by a browser, because the text editing and displaying is leaved to the web application (TinyMCE etc). IMO this bug should be resolved as WONTFIX or INVALID.
Lucas, I don't think the technical point of view is the best one (even if I understand it structure things).
In a user point of view and for user experience, like for ones that use blogs, it could be very useful.
The browser is able to copy and paste yet, but the function should be enhanced due to news internet uses (blogs).
Wait a moment, maybe I've misunderstood your problem: your problem is you can't paste rich text as HTML code in plain text areas, because it's pasted as plain text?
I'm not sure to well understand your question : I do not edit HTML, but when I paste rich text on a blog writing control, it keep it format. So, yes the HTML code keep the text format.

To solve this, I write my text in OOo (I need a non-web version of the text), copy-paste in plain text editor, copy to my blog and then use the blog editor to format it. I just want to be able to directly paste it as plain text in the browser.
If this can make my problem more clear...

OK, the text editing and displaying is leaved to the web application (TinyMCE etc), but the copy/paste function is integrated to the browser (you can do it on any control and any page)
Severity: enhancement → normal
Blocks: cuts-control
The problem do not only happen with text editor like TinyMCE, but even with "large" text field like the one I'm writing in. So I don't think it's a text editor problem... (should be NEW ? ;-))
This was just added to Chrome via CTRL+SHIFT+P.

It would be very useful, especially considering:
a) Mozilla's currently-buggy HTML editor implementation (especially pasting block content into inline elements).
b) The amount of garbage HTML that comes out of other applications like Microsoft Office that is a mess to clean up.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: parity-chrome
Whiteboard: parity-chrome → [parity-chrome]
blocking2.0: --- → ?
--> Core::Editor, I think. Ehsan, if this is actually something you'd need us to do in the front end with clipboard handling, feel free to bounce it back.

Definitely doesn't block Firefox 4, though.
blocking2.0: ? → -
Product: Firefox → Core
QA Contact: general → general
I'll consider this.  I don't think that it's too hard, but I won't make any promises for it to get into Firefox 4.  :-)
Assignee: nobody → ehsan
Component: General → Editor
QA Contact: general → editor
Summary: Add ability to adapt text formating when pasting text → Add ability to paste HTML as plain text
Attached patch Patch (v1)Splinter Review
Actually it seems like the functionality has been there for a long time, we just need to expose it through Cmd/Ctrl+Shift+V.
Attachment #477204 - Flags: review?(roc)
Attachment #477204 - Flags: approval2.0?
(In reply to comment #8)
> I'll consider this.  I don't think that it's too hard, but I won't make any
> promises for it to get into Firefox 4.  :-)

Nice ! Thanks ! :D

I believe that pasting HTML as plain text should be the default behaviour. But I don't know if pasting some formated text is usefull in some cases and for some people. That's why in comment 1 I suggest to add a floating button to change the formatting of the pasted text (maybe you have a better suggestion for UI ;-)).
Should I fill (for a future release) a following bug about that ?

Do your implementation will considerate pasting plain text from anything else than an HTML editor (that could be embedded, like TinyMCE as of comment 1) : OOo, MS Office, Smultron... ?
Should I fill (for a future release) a following bug about that too ?
(In reply to comment #9)
> Created attachment 477204 [details] [diff] [review]
> Patch (v1)
> 
> Actually it seems like the functionality has been there for a long time, we
> just need to expose it through Cmd/Ctrl+Shift+V.

It should be integrated too in the old menu and the Firefox button too. Or find a way to expose this to the user to make it discoverable. I can fill a following bug about that if you agree.
(In reply to comment #10)
> I believe that pasting HTML as plain text should be the default behaviour.

Certainly not, as it's almost never what the average user wants.

> But
> I don't know if pasting some formated text is usefull in some cases and for
> some people.

Pasting formatted text is almost always what's useful to people.

> That's why in comment 1 I suggest to add a floating button to
> change the formatting of the pasted text (maybe you have a better suggestion
> for UI ;-)).

We do not have any built-in UI for any editor operation.  You're confusing this with editor widgets (such as TinyMCE).  You should file this bug against those widgets.

> Should I fill (for a future release) a following bug about that ?

No, as it's out of the scope for Firefox.

> Do your implementation will considerate pasting plain text from anything else
> than an HTML editor (that could be embedded, like TinyMCE as of comment 1) :
> OOo, MS Office, Smultron... ?

It will paste plain text data from whatever source which puts plain text data on the clipboard.
(In reply to comment #11)
> It should be integrated too in the old menu and the Firefox button too. Or find
> a way to expose this to the user to make it discoverable. I can fill a
> following bug about that if you agree.

You can file a bug, but I'm not inclined to add another type of Paste menu item for this.  Does Chrome expose this through some sort of a UI?
Attachment #477204 - Flags: review?(roc)
Attachment #477204 - Flags: review+
Attachment #477204 - Flags: approval2.0?
Attachment #477204 - Flags: approval2.0+
Attached patch TestSplinter Review
Let's also get a test for this!
Attachment #477393 - Flags: review?(roc)
Comment on attachment 477393 [details] [diff] [review]
Test

So all our tests are guaranteed to run in US-English mode?
Attachment #477393 - Flags: review?(roc) → review+
(In reply to comment #15)
> Comment on attachment 477393 [details] [diff] [review]
> Test
> 
> So all our tests are guaranteed to run in US-English mode?

There has been talks about running tests in localized builds for a long time, but as far as I know, there are no plans to actually make that happen any time soon.  But why is that important here?
I noticed that the try server test for this bug fails on Linux.  When I debugged it locally, I figured out that the platformHTMLBindings.xml file that we use on Linux only #includes the base handler bindings for the browser, and not for inputs, textareas, and contenteditable fields.  This is pretty broken, and so far we've been lucky that most of the key combinations in those fields are already defined in the browser bindings, but this patch fixes the issue for real.
Attachment #477998 - Flags: review?(roc)
Attachment #477998 - Flags: approval2.0?
Attachment #477998 - Flags: review?(roc)
Attachment #477998 - Flags: review+
Attachment #477998 - Flags: approval2.0?
Attachment #477998 - Flags: approval2.0+
Whiteboard: [parity-chrome] → [parity-chrome][needs landing]
Sorry for my off time.
As this bug is landing, I've filled bug 599769 to fix the OSX shortcut to the default one that is used in this os : Cmd+Option+Shift+V
Depends on: 599769
No longer depends on: 599769
Attachment #478833 - Attachment description: Part 4: Switch the keyboard shortcut on Mac" → Part 4: Switch the keyboard shortcut on Mac
Attachment #478833 - Attachment is patch: true
Attachment #478833 - Attachment mime type: application/octet-stream → text/plain
Attachment #478833 - Flags: review?(bzbarsky)
Attachment #478833 - Flags: approval2.0?
(In reply to comment #13)
> (In reply to comment #11)
> > It should be integrated too in the old menu and the Firefox button too. Or find
> > a way to expose this to the user to make it discoverable. I can fill a
> > following bug about that if you agree.
> 
> You can file a bug, but I'm not inclined to add another type of Paste menu item
> for this.  Does Chrome expose this through some sort of a UI?

About the new menu of Firefox button :
Adding a new menu button to the "Edit" item is maybe not the best solution. But I still believe that it should be discoverable by the user.
My first idea (maybe you've got a better one) is to make pasting button a dropdown one (like in OOo).

For the old menu (used in OSX, and maybe Linux depending on decision about bug 585370) :
At least, for OSX, TextEdit expose a pasting without formating menu item, so it's not a strange idea to expose on in Firefox too as they both share these basics edition features.
Will Linux be the unlucky OS ? ;-) Adding it to Linux will make this feature UI cossplatform. And discoverable.
Comment on attachment 478833 [details] [diff] [review]
Part 4: Switch the keyboard shortcut on Mac

This seems fine, but why is it needed?
(In reply to comment #22)
> Comment on attachment 478833 [details] [diff] [review]
> Part 4: Switch the keyboard shortcut on Mac
> 
> This seems fine, but why is it needed?

Boris, see comment 18 please.
Comment on attachment 478833 [details] [diff] [review]
Part 4: Switch the keyboard shortcut on Mac

Perfect, thanks.  Sorry I missed that when reading the bug.  :(
Attachment #478833 - Flags: review?(bzbarsky) → review+
Hmm, can I just assume that the granted approval includes this last bit as well?
Comment on attachment 478833 [details] [diff] [review]
Part 4: Switch the keyboard shortcut on Mac

a=me, just in case. ;)
Attachment #478833 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Is this bug responsible for why when I paste something into Thunderbird, and it is formatted as a table, I can't type any message? If I type my message first, then paste, it works fine. This is mainly a problem if I've addressed it to multiple people, because the solution is to just resend a new email.
That sounds like one of the HTML editor bugs, not this one.
Status: RESOLVED → VERIFIED
(In reply to comment #28)
> Is this bug responsible for why when I paste something into Thunderbird, and it
> is formatted as a table, I can't type any message? If I type my message first,
> then paste, it works fine. This is mainly a problem if I've addressed it to
> multiple people, because the solution is to just resend a new email.

I have a hard time believing that this bug has anything to do with what you're describing.
Target Milestone: mozilla2.0b8 → mozilla2.0b7
For the reference: bug 476837 is about adding context menu for this.
(In reply to :Ehsan Akhgari from comment #30)
> (In reply to comment #28)
> > Is this bug responsible for why when I paste something into Thunderbird, and it
> > is formatted as a table, I can't type any message? If I type my message first,
> > then paste, it works fine. This is mainly a problem if I've addressed it to
> > multiple people, because the solution is to just resend a new email.
> 
> I have a hard time believing that this bug has anything to do with what
> you're describing.

FYI, I still see this from time to time; especially in Yahoo mail.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: