Closed Bug 537414 Opened 10 years ago Closed 10 years ago
pasting clipboard content to Open
Office Writer broken
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091230 Minefield/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091230 Minefield/3.7a1pre If I highlight anything (happens on every page I have tried) and select copy, then go to the Open Office Writer document I want to copy the text into, there is no option to paste the text. It is as if it was never copied to the clipboard or something Reproducible: Always Steps to Reproduce: 1.Visit this website http://www.einvestigator.com/links/lists/list_of_us_presidents.htm 2.Highlight some text, right click and hit "copy" 3.Go into Open Office Writer and right click and see if there is a "paste" option. Actual Results: No paste option appears and even when one enters the "edit" menu at the top of the window, the paste option is grayed out. Expected Results: The text should have been copied and then pasted into the Open Office program. I am using the latest test build of Minefield.
I can confirm it with Fx3.6 Rc1 [Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2) Gecko/20100105 Firefox/3.6] on Windows7 Ultimate x64 and OpenOffice 3.1.1. You can not paste an copied text from Fx3.6 Rc1 to OpenOffice!
this regressed on MC within: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e4e23cc1f527&tochange=88ee36d9eb53 and on 1.9.2 within: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=23054aa8df66&tochange=d82ce930bef3 (and therefore is present in Fx3.6RC1) overlap points to: Bug 533691 (maybe also related Bug 528731?)
Status: UNCONFIRMED → NEW
Component: General → Widget: Win32
Ever confirmed: true
OS: Windows 7 → Windows XP
Product: Firefox → Core
QA Contact: general → win32
Summary: Cannot copy/paste from Minefield to a Word Document → pasting clipboard content to OpenOffice Writer broken
Version: Trunk → 1.9.2 Branch
Probably too late to block, but nominating anyways.
Bug 533691 is almost certainly responsible. Luckily, that means the fix should be easy :-)
I can confirm this on trunk. I have a theory as to why this is happening.
Assignee: nobody → me
Status: NEW → ASSIGNED
I don't have open office to test, but I'd guess this is the cause. Regardless, this needs to be addressed. Let's plan on adding tests for this object in in addition to the data object tests we're working on.
I can confirm that Jim's patch fixes the bug. My theory was that we were hitting an integer overflow at http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/IEnumFE.cpp#129 (Next(ULONG_MAX, ...); seems like a good way to get all of the FORMATETCs out at once) so we'll want to fix that too even if it's not the cause.
Assignee: me → jmathies
Attachment #420902 - Flags: review?(roc) → review+
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
(In reply to comment #7) > I can confirm that Jim's patch fixes the bug. My theory was that we were > hitting an integer overflow at > http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/IEnumFE.cpp#129 > (Next(ULONG_MAX, ...); seems like a good way to get all of the FORMATETCs out > at once) so we'll want to fix that too even if it's not the cause. Lets file that out as a separate bug from this one.
This code didn't land on 1.9.0 or 1.9.1 yet. I'll make a note to include it in bug 533691 so we don't have to request two sets of approvals.
blocking1.9.1: ? → ---
Depends on: 538891
Target Milestone: --- → mozilla1.9.3a1
Version: 1.9.2 Branch → Trunk
I have no idea where whether there are plans for an RC2 or not, but if there's any opportunity for this to block it should. It's a serious regression in user facing features.
(In reply to comment #11) > I have no idea where whether there are plans for an RC2 or not, but if there's > any opportunity for this to block it should. It's a serious regression in user > facing features. And the fix is trivial.
I don't think this blocks, but we'd take it as a ridealong. Otherwise: 3.6.1. Jim: what other applications do we think are affected, here? Adding a relnote ...
(In reply to comment #13) > I don't think this blocks, but we'd take it as a ridealong. Otherwise: 3.6.1. > > Jim: what other applications do we think are affected, here? Adding a relnote > ... I haven't seen any anomalies in other apps, but I'm with Kyle, this should get into the final and not wait on a point release. The bug will likely cause some problems that haven't surfaced yet, and the fix is very safe to take.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a1pre) Gecko/20100111 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4) V.Fixed.
Status: RESOLVED → VERIFIED
Attachment #420902 - Flags: approval126.96.36.199?
Lanikai 3.1a1pre (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100113 Lanikai/3.1a1pre) has the same issue. I assume the fix should be in this build?
(In reply to comment #18) > Lanikai 3.1a1pre (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) > Gecko/20100113 Lanikai/3.1a1pre) has the same issue. I assume the fix should be > in this build? No. This has not been pushed to the 1.9.2. branch yet.
Comment on attachment 420902 [details] [diff] [review] idx bug a192=beltzner, please land on mozilla-1.9.2 and GECKO192_20100105_RELBRANCH
Attachment #420902 - Flags: approval188.8.131.52? → approval1.9.2+
Landed on 1.9.2 and the 1.9.2 GECKO192_20100105_RELBRANCH for RC2: https://hg.mozilla.org/releases/mozilla-1.9.2/rev/c451b7c96a16 https://hg.mozilla.org/releases/mozilla-1.9.2/rev/60d02a5d02a3
Target Milestone: mozilla1.9.3a1 → mozilla1.9.2
Nominated to block older branches because it's a regression from bug 533691 which is nominated.
Flags: blocking184.108.40.206? → blocking220.127.116.11-
You need to log in before you can comment on or make changes to this bug.