319141 - Copy from XHTML content always copies only plain text instead of formatted content (HTML or RTF)

Status: NEW

(Core :: DOM: Serializers, defect, P5)

Description

[Mikko Rantalainen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Copying content to clipboard no longer copies formatted content when the source is XHTML (application/xhtml+xml). Instead of HTML or RTF formatted content with embedded images I get just plain text. This used to work with FF 1.0.x.


Reproducible: Always

Steps to Reproduce:
1. Load any XHTML page (e.g. an error page in FF1.5)
2. Press CTRL+A (select all)
3. Press CTRL+C (copy)
4. Switch to another window (I'll use MS Word, for example)
5. Press CTRL+P (paste)

Actual Results:  
Only text content from the page is pasted. There's usually excessive white space, too.

Expected Results:  
Page contents with formatting should have been pasted.

Works with Firefox 1.0.7, doesn't work with Firefox 1.5.
Arguably, the current behavior is correct because UA isn't expected to do conversion from XHTML to HTML or RTF. The real problem is that MS Word doesn't allow importing of XHTML content. However, I think this should be fixed because this issue hinders the XHTML acceptance.

The problem can be seen with all XHTML (application/xhtml+xml) pages, not only with error page that was used in the example.

Comment 1

[Frank Wein [:mcsmurf]]

Looks like we broke this on purpose, see Bug 270145. I'm not sure if we want to invalidate this bug here, i would rather like to see XHTML like HTML copy mode working again.

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Confirming the bug.

I have the gut feeling the fix for bug 2710145 back in 2004 was a bad compromise
since pasting normal XHTML content to XHTML is currently broken: only text is
copied. This is not an acceptable behaviour for editor users.

I think we should

1. solve the issue described above ; this is a rather trivial change and I will
   take this bug in the coming days

2. reopen bug 270145 and find a better fix

Comment 4

[Boris Zbarsky [:bzbarsky]]

> I have the gut feeling the fix for bug 2710145 back in 2004 was a bad
> compromise

It just restored behavior we used to have back when XHTML didn't create an HTMLDocument.  I wasn't trying to fix XML copy in general; just unbreak XHTML copy to "no worse than it used to be".  Without that patch, copying parts of an XHTML document would just randomly fail, period.

The right fix is to fix the copy code to handle non-HTML, of course.  If you want to do that, sounds great!

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #4)

> Without that patch, copying parts of an
> XHTML document would just randomly fail, period.

Randomly fail, really... Can you please detail ?

I removed that patch in the current builds of BlueGriffon a week ago and
copy/paste in XHTML1/XHTML5 never fails. Well, I admit I have no CDATA
section in the content area of the documents I am editing, but let's admit it:
it's a really rare case.

Comment 6

[Boris Zbarsky [:bzbarsky]]

It'll fail if the range you selected has a CDATA section, certainly.  Happen to have a <script> wrapped in CDATA in the range you selected?  You silently lose.  It's totally random from the _user_'s point of view.

It'd also misbehave in various other ways; the CDATA case is just one where the misbehavior leads to nothing being copied instead of the copied stuff just being wrong.

Comment 7

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

(In reply to comment #6)
> It'll fail if the range you selected has a CDATA section, certainly.  Happen to
> have a <script> wrapped in CDATA in the range you selected?  You silently lose.
>  It's totally random from the _user_'s point of view.

You lose the script. You don't lose the visible content and that's the main
point of copy/paste... In other terms, it's still much better than the
current text plain copy even if it's not perfect. An acceptable compromise
from a wysiwyg editor's user point of view, certainly.

> It'd also misbehave in various other ways; the CDATA case is just one where the
> misbehavior leads to nothing being copied instead of the copied stuff just
> being wrong.

I am interested in details, please.

Comment 8

[Boris Zbarsky [:bzbarsky]]

I don't remember the details at this point, sadly.  I just recall at the time looking at all the things the HTML serializer does and thinking about how they'd work if you pass XHTML, and a bunch of them looked broken....

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Boris, I could perfectly understand if you tell me that the "compromise" I
outlined above is not enough for Firefox. But it _is_ enough for BlueGriffon.
Would you accept if the two IsHtml() tests in the patch are encapsulated for
instance in a #ifndef MOZ_STANDALONE_EDITOR or MOZ_BLUEGRIFFON or
something like that?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Daniel, I'm not the maintainer for this code.  Again, all I did was make the code go back to doing exactly what it was trying to do; it had just gotten broken by the fact that whether a document QIs to nsIHTMLDocument changed.

My gut feeling on introducing ifdefs like that is that (where we suddenly have a codepath that's not tested in normal Gecko, isn't security-audited, but we're somehow expected to maintain it) is that we'd rather not do that.  But maybe there's a particular reason why we want those headaches instead of just getting the copy code fixed?

Comment 11

[Remi Collet]

My 0.02€ : a build condition seems a bad solution as this will forbid to run BlueGriffon as a Xulrunner application.

Comment 12

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.