Bug 51306 - EDITING: Frame contents in particular document can not be reached by mouse click
Summary: EDITING: Frame contents in particular document can not be reached by mouse click
Status: RESOLVED DUPLICATE of bug 52182
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: Other Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-06-21 09:36 UTC by Rainer Bielefeld Retired
Modified: 2012-10-11 10:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Original "Poison" Word Document (35.50 KB, application/msword)
2012-06-21 10:16 UTC, LibreRay
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2012-06-21 09:36:45 UTC
Steps how to reproduce with "LibreOffice 3.5.5.1  German UI/Locale [Build-ID: c9944f7-48b7ff5-0507789-54a4c8a-8b242a8] on German WIN7 Home Premium (64bit) 

1. From Bug 43892 (showing similar symptoms) open obsoleted attachment 63313 [details]
2. Try to click into Frames with text contents "Can't Edit Me!"
   Expected: Caret appears at clicked place between characters
   Actual: Nothing

Already reproducible with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit), it seems the problem appeared with 3.5

Still [Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+   - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 8d39b7]" (tinderbox: W2008R2@16-minimal_build, pull time 2012-06-20 04:38:46) 

Worked fine with 
"LibreOffice 3.4.5 RC1  - WIN7 Home Premium (64bit) English UI [Build ID: OOO340m1 (Build:501)]"
"LibreOffice 3.3.3  German UI/Locale [OOO330m19 (Build:301) tag libreoffice-3.3.3.1] on German WIN7 Home Premium (64bit), 
so Regression

@LibreRay:
With what Operating System did you test?
Can you tell us some more concerning history of that document? Are you able to create such a document from the scratch (may be with an old OOo version)?

@Cédric:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 1 LibreRay 2012-06-21 10:16:48 UTC
Created attachment 63316 [details]
Original "Poison" Word Document

This is the original Word document that produces the un-editable frames in the file when converted. I just edited the document to remove some customer data and saved it with Word 2010 in compatibility mode.

I tried importing it with LibreOffice:

LibreOffice 3.5.4.2 
Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18

The problem occurs with the freshly imported file.

The Word document is quite old - I have been using it since 2005, and I did not originally create the document, it started as an invoice template. I converted it to ODT with "OpenOffice.org/3.1$Unix OpenOffice.org_project/310m11$Build-9399" back in 2009-05-13 and have been using it in that format with various versions of OO.org (and LibreOffice) ever since.
Comment 2 LibreRay 2012-06-21 10:19:17 UTC
My OS is Windows 7 Pro 64-bit with SP1. I have access to a Mac as well and will try that if you would like me to.
Comment 3 LibreRay 2012-06-21 18:48:26 UTC
Checked this on my Mac, and the problem also exists there:
LibreOffice 3.5.4.2 
Build ID: 165a79a-7059095-e13bb37-fef39a4-9503d18

Mac OS X 10.7.2 (Lion)
Comment 4 Rainer Bielefeld Retired 2012-06-21 21:15:52 UTC
Although the creation process for the documents might be interesting, AOOo 3.4 also has no problem with reporter's document (neither .odt not .doc), and so we should find a way to handle it, too.
Nop  problems with .doc for MS WORD Viewer.

Cédric:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
Comment 5 Michael Stahl (allotropia) 2012-10-11 10:41:45 UTC
the uneditable frames all have "Wrap" set to "In Background".

*** This bug has been marked as a duplicate of bug 52182 ***