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.
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.
Assignee: nobody → dom-to-text
Component: General → DOM to Text Conversion
Product: Firefox → Core
QA Contact: general
Summary: Regression: Copy from XHTML content always copies only plain text instead of formatted content (HTML or RTF) → Copy from XHTML content always copies only plain text instead of formatted content (HTML or RTF)
Version: unspecified → Trunk
Assignee: dom-to-text → nobody
QA Contact: dom-to-text
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
> 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!
(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.
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.
(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.
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....
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?
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?
My 0.02€ : a build condition seems a bad solution as this will forbid to run BlueGriffon as a Xulrunner application.
You need to log in before you can comment on or make changes to this bug.