Closed Bug 718592 Opened 12 years ago Closed 12 years ago

Copy/Paste from Office (Microsoft, Open, Libre) stopped working since version 9

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 714115

People

(Reporter: RNicoletto, Assigned: bbondy)

Details

Attachments

(1 file)

When copying/pasting content FROM Office (Microsoft Office, OpenOffice, LibreOffice) TO Firefox/Thunderbird >= 9.x all styles are lost.

It seems a (huge?) regression in version 9, since the problem it's not reproducible with previous versions (but it can be reproduced with latest nightly).

Step to reproduce on Firefox:
1. Open a formatted document with your preferred Office Suite.
2. Copy the document or a part of it in the clipboard.
3. Open Firefox and visit http://www-archive.mozilla.org/editor/midasdemo/
4. Copy the clipboard content in MIDAS editor

Expected result: document styles (font families, font colors, font size, paragraph, etc...) are the same as original document.
Actual result: all document styles are lost.
NOTE 1 - I'm unable to test it on OS different than Microsoft Windows so I'm not sure "Platform: ALL" flag is correct.

NOTE 2 - I found others bugs possibly related to this:
Bug 407983 - Add support clipboardData object for the onpaste event
Bug 437217 - Paste problem when composing new e-mail (images from Microsoft Word or Excel)
Bug 437966 - Pasting graph from office apps doesn't work 
Bug 591995 - Copy/Paste form Open Office will broke styles in e-mail
Bug 648797 - Copying from OpenOffice spreadsheet and pasting in Message Compose window causes font to shrink
Bug 682438 - When pasting from OpenOffice, crossed-out characters are pasted as normal
Bug 714508 - Copy & paste bmp image from Openoffice / Libroffice doesn't works

None of these it's a dupe of this bug. This bug is a REGRESSION (cannot replicate with Firefox 8.x or Firefox 3.6.x) and it's a CORE bug (reproducible with both Firefox and Thunderbird).
This looks like a dupe of bug 714115, can you try a trunk/nightly build?
Alternatively, change decimal point in regional settings from ',' to '.'
(see bug 714115 comment #22).
(In reply to rsx11m from comment #2)
> This looks like a dupe of bug 714115, can you try a trunk/nightly build?
> Alternatively, change decimal point in regional settings from ',' to '.'
> (see bug 714115 comment #22).

As reported in comment 0, bug is reproducible with latest nightly.

I don't think decimal point in Regional Settings have anything to do with this bug. As you can see RTF test document don't have any number. However, I just verified it on Windows XP with both Microsoft Office 2003 and LibreOffice 3.4.4 and obtained the same result with "." and "," decimal point.
(In reply to RNicoletto from comment #3)
> As reported in comment 0, bug is reproducible with latest nightly.

My bad, sorry. I only saw "9.x" showing up and the description matches that bug which is fixed with the January 15 trunk nightly.

> I don't think decimal point in Regional Settings have anything to do with
> this bug. As you can see RTF test document don't have any number.

It had in that case, given that a version string was expected to have a ',' rather than a '.' in its string and the remainder of the CF_HTML part was ignored.

Anyway, looks like a different thing then.
Brian: is this a dupe of what you fixed a couple of days ago?
> I don't think decimal point in Regional Settings have anything to do with 
> this bug. As you can see RTF test document don't have any number. 

The document you copy does not need a decimal point in it.  The decimal point is internal to the CF_HTML format. 

I would say this is a dupe yes.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
That was my first impression as well, but comment #3 may suggest otherwise, assuming that (a) the trunk build used contained the fix for bug 714115, and (b) the regional settings were set correctly for testing the workaround with the application restarted to pick it up...
RNicoletto, which exact nightly build are you seeing this problem in?
> RNicoletto

Can you confirm if you tried this by shutting down the browser and restarting it after changing the regional settings?
(In reply to Boris Zbarsky (:bz) from comment #8)
> RNicoletto, which exact nightly build are you seeing this problem in?

Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120116 Firefox/12.0a1
OK, reopening.  That certainly postdates the checkin for bug 714115.

Brian, could you please look into this?
Assignee: nobody → netzen
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(In reply to Brian R. Bondy [:bbondy] from comment #9)
> > RNicoletto
> 
> Can you confirm if you tried this by shutting down the browser and
> restarting it after changing the regional settings?

Gotcha! Shutting down the browser and restarting it after changing the regional settings (from "," to "." as decimal point) solves the problem!
Assignee: netzen → nobody
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → DUPLICATE
Sorry for the mid-air collision.
Still reopening; doesn't sounds like this is fixed in the default regional settings for this user....
Assignee: nobody → netzen
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
> Still reopening; doesn't sounds like this is fixed in the default 
> regional settings for this user....

I think that when he performed this test originally he was using a build before the fix.  

> RNicoletto

Can you please confirm tat you cannot reproduce even if the regional setting is "," or "." in the latest nightly. (You have to restart the browser between both tests)
> I think that when he performed this test originally he was using a build before the
> fix.  

Comment 10 seems pretty clear... Maybe it's just incorrect?
I am not sure that it was retested at the time of writing Comment 10.  RNicoletto please confirm.
i.e. I suspect maybe an update happened in between (which may have been completely silent).
Sorry for the confusion. I would like to clarify my test results.

Firefox 9.0.1 - Standard Regional Settings = K.O.
Firefox 9.0.1 - Modified Regional Settings = O.K. (comment 12)
Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120117 Firefox/12.0a1 - Standard Regional Settings = O.K.

So the bug looks FIXED to me.
Does K.O. mean not O.K.?

And your standard regional settings for v12.0a1 is set to "," right?
(In reply to Brian R. Bondy [:bbondy] from comment #20)
> Does K.O. mean not O.K.?

Yes. 
O.K = Works fine.
K.O. = Doesn't work as expected.

> 
> And your standard regional settings for v12.0a1 is set to "," right?

Right.
Just FYI.

1) Copying LibreOffice content to MIDAS works fine, but copying the same content to others online editor (such as those mentioned in bug 714115 comment 0) doesn't work (almost all styles are lost, except "bold" and "italic"). For reference, Google Chrome 18.xx and Opera Browser 11.60 work fine.

2) Copying Microsoft Office 2003 content to MIDAS works fine, except "Main Title" (Heading 1) and "Title" (Heading 3). This problem occurs with Chrome and Opera too, only Internet Explorer 8 keeps all the MS Office styles.
Re comment 21:
Thanks for clarifying.


Re comment 22:
Could you confirm this is the same functionality as in Firefox 8?
I think this comment is in reference to a really old bug, bug 137450 which I want to eventually do (sooner than later).
(In reply to Brian R. Bondy [:bbondy] from comment #23)
> Re comment 22:
> Could you confirm this is the same functionality as in Firefox 8?

I cannot test Firefox 8 right now but I hope to do that tomorrow.
We sanitize the clipboard contents before pasting, so the 2nd point in comment 22 can be a result of that.
Pretty sure this is not related to a new potential regression but instead is just our existing handling.  If this is the case please close after verifying in Firefox 8.
(In reply to Brian R. Bondy [:bbondy] from comment #23)
> Re comment 22:
> Could you confirm this is the same functionality as in Firefox 8?

OK, I just verified the problem with online WYSIWYG editors other than MIDAS with Firefox 8.0.1 and I can reproduce comment 22, so it's not a regression.
Boris, can this bug be re-duped against bug 714115, given RNicoletto's previous comment #27 that the other issue he observed was unrelated to this?
Oops, s/Boris/Brian/ and doing so per his comment before:

(In reply to Brian R. Bondy [:bbondy] from comment #26)
> Pretty sure this is not related to a new potential regression but instead is
> just our existing handling.  If this is the case please close after
> verifying in Firefox 8.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: