Closed Bug 195260 Opened 21 years ago Closed 21 years ago

Often refuses to paste from Microsoft Office XP Clipboard

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jc, Assigned: nisheeth_mozilla)

References

(
URL
)

Details

(Whiteboard: [need info] EDITORBASE+)

Attachments

(1 file)

txt file of the word doc, with all of the underlying code
10.96 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

Often when I try to copy from a document in Word XP and paste into the body of
an HTML email, it refuses - inserting nothing. Other snippets from the same
document will go in, while others will not. Inserting into other non-Microsoft
applications seem to not have this problem.

Reproducible: Always

Steps to Reproduce:
1. Select ALL the attached Word document
2. Copy it to clipboard
3. Try pasting it into an email body.

Actual Results:  
Nothing inserted

Expected Results:  
Inserted the text.

The web links to a word file you can download to see the problem.
Loading your link took down my mozilla twice. Not gonna try that again.
MS Office implements copy/paste a bit different than regular apps. The Office
Clipboard can hold 24 items. The Windows Clipboard only one. 

Possibly this MS break of its own MS standards causes your problems? What
happens if you disable Office Clipboard?


WFM 2003022704 (latest-1.3) Windows 98, Microsoft Word 2000 SP-3. 

Reporter, can you narrow it down a little more? Can you paste even a single
character? Exactly what in the Word document triggers the problem?
It's a mystery. Copying and pasting some fragments of the text will work, and
then adding one more character will blow it.

Disabling Office clipboard definitely solves the problem - but that's hardly a
solution for the office-using world out there. I can find no other non-office
applications that have this same problem.
Correction to my prior comment - I know of no way to disable the Office XP
Clipboard short of removing Office XP. All I know is that Office 97 did not have
this problem.

Right click on the URL above - save the word file on your disk - open it in Word
XP and try to copy and paste it all. It won't. Then try to just copy and paste
the first unbolded paragraph. That works fine.

Then try something weird try the Paragraph that reads "You will be met..." up to
"country director for" - that works - but then try again adding one more word
"India" and it won't.
QAwanted. Could another person with Office XP test this so that we can confirm
it? TIA.
Keywords: qawanted
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030228

I can confirm this.  Copying and pasting from a wordxp document- sometimes it
works, sometimes it doesn't.  In fact, there was a particular word (Daniel) that
it wouldn't copy- if that word was in the selection, it wouldn't paste, if it
wasn't, then it would usually (but not always) would paste.  Something strange
is going on there.
Thanks! Confirming. Should block 1.4 alpha as this represents a serious
interoperability issue.

Are you able to paste from Office XP to a textarea in the Mozilla browser, such
as the "Additional Comments" box in this bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.4a?
Keywords: qawanted
Yes, problem here as well.  Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.3) Gecko/20030308 on Office XP SP1.  

Agrees that problem is a bit inconsistent - it works if you copy bits of text
but not the whole document.  Tested with other (my own) documents too so it is
not a problem with the specific document.

Pasting into "additional comments" box is absolutely fine.  Even when copying
and pasting whole documents, or when there are multiple things in the Office
Clipboard.

Appears to be Mail/News problem then.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
Office XP sp2

I can confirm this too. Pasting stopped working for me when I switched from
Mozilla 1.2.1 to 1.3 so something must have changed between versions. It does
seem to be quite random.
Keywords: nsbeta1
Mail triage team: need info.  Esther to see if this a problem in composer as well.
Whiteboard: [need info]
Yes, I've just checked using the 1.3 release - it is indeed a problem in
composer as well. In fact, that's probably where the problem resides, since mail
just users composer, yes?
Mail triage team: appears to be a composer issue.  Over to composer for triage.
Assignee: ducarroz → composer
Component: Composition → Editor: Composer
Product: MailNews → Browser
QA Contact: esther → petersen
Flags: blocking1.4a? → blocking1.4a-
Joe--should this bug be reassigned to you?
We need this to maximize our compatibility with the major office software suite.
Flags: blocking1.4b?
Summary: Often refuses to paste from Office XP Clipboard → Often refuses to paste from Microsoft Office XP Clipboard
Ok, I don't have Office XP but Office 2000. Using the steps provided (and the
attached document), I can't reproduce this issue. Looks like I need to get
Office XP  for further testing. Tested with the 2003-04-10-08 trunk build under
Windows XP.
Yes, a user at my company found this bug independently.  Same issue: sometimes a
cut and paste works from Microsoft Word 2002, sometimes it doesn't.  Windows
2000 SP3 + many preSP4 code.  Mozilla 1.3 release.  He claims it was working for
a few weeks, and then when he composed another e-mail, it was broken.  Very
strange, but very TRUE!

The same problem is true in COMPOSER, not just in the mail Composer.

In a text window of the NAVIGATOR (BROWSER), I can paste normally the same text
that is unpasted into composer.  Also, composing e-mail in text form WFM.  Only
HTML composition is broken.
Editor triage team: appears to be a core issue.
Assignee: composer → jfrancis
Component: Editor: Composer → Editor: Core
QA Contact: petersen → sairuh
Flags: blocking1.4?
Can anyone point me at a utility for examining the data on the clipboard on a
windows xp box?
MS changed the old utility to "Clipbook Viewer."

http://www.andyrathbone.com/tips/clipbrd.html
Whiteboard: [need info] → [need info] EDITORBASE
I am using the following to test with:
OS Name: Microsoft Windows 2000 Professional
Version: 5.0.2195 Service Pack 3 build 2195
Word: Microsoft Word 2000 (9.0.2720)
Word properties have been set to the default values

I tested on:
Build ID: 2003041609

I could not reproduce this problem
taking...
Assignee: jfrancis → nisheeth
Alrighty, with MS Word 2002 (10.2627.2625) I can reproduce the problem. I will
start the debug process for you now that I can reproduce it.
In the head area of the Word document, is a series of smartTag definitions:
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="date"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>

If those are removed, the document loads fine. I will attach a text file that
shows the underlying code. To test, save the text file and resave as a doc file. 
Oddly, if I save the txt file as an html file and render it in the browser and
then select edit, the document renders within composer just fine (and the smart
tags are viewed as question marks in the Show All Tags mode). If I display that
new html file in IE, save it out as a .doc file and then try to drop it in
composer it will not render -- now is that weird or what?
EDITORBASE+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [need info] EDITORBASE → [need info] EDITORBASE+
So, we are getting bit by bug 167493 here.  The <o:SmartTagType> tag is a child
of the HEAD tag and is interpreted with a tag type of eHTMLTag_userdefined. 
This tag type isn't defined as a valid HEAD kid and causes the parser to place
it on a misplaced tag stack.  Now, comments are valid HEAD kids only when the
misplaced tag stack isn't populated.  Once something is on the misplaced tag
stack, the parser starts pushing the comments encountered within the HEAD onto
the misplaced tag stack.  STYLE tags are valid HEAD kids, so the only tag that
gets inserted as a child of the HEAD tag is the single STYLE tag that isn't
enclosed within a comment.

So, you end up with a document fragment that looks like (see attachment 122019 [details]):

<HTML>
<HEAD>
  <META>
  <META>
  <META>
  <META>
  <LINK>
  <STYLE> ... </STYLE>
</HEAD>
<BODY>
  <o:SmartTagType>
  <o:SmartTagType>
  <Comment 1>
  <Comment 2>
  <Comment 3>
</BODY>
</HTML>

The extra content in the BODY causes problems in document fragment processing
logic further upstream.  Specifically, nsHTMLEditor::CreateListOfNodesToPaste()
in nsHTMLDataTransfer.cpp returns an error because its call to SetEnd() on the
document fragement range fails:

  res = docFragRange->SetEnd(aEndNode, aEndOffset);

Harish and I tested the simple version of the fix attached to bug 167493.  With
that fix, cut n paste from Office XP into mail compose and composer work fine.

But, the simple fix had caused a regression and needed to be backed out.  Harish
just attached a better fix to bug 167493 which doesn't cause that regression
which also fixes this bug.  Thanks for the quick turnaround, Harish!

Once Harish lands his new fix, I'll mark this bug fixed.  Setting bug dependency
 for now.
Status: NEW → ASSIGNED
Depends on: 167493
cool beans!  
FYI: Fix for bug 167493 has landed. 
Marking bug fixed now that bug 167493 has been fixed...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 203719 has been marked as a duplicate of this bug. ***
Flags: blocking1.4b?
Flags: blocking1.4?
Tested with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030513
Netscape/7.02+ (ax) and MS Word 2002 (10.2627.2625)

This now works fine, marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: