Hi, can nous describe exactly what doesn't by providing a step by step description and a document to reproduce your issue. Thanks! Sophie

Created attachment 96308 [details]
dont work copy and paste in input field

Created attachment 96309 [details]
dont work copy and paste in input field

version 2 file with input field with corrected field

Testing on 4.2.3.2: Ctrl-c and Ctrl-x work in a input field, only Ctrl-v fails.

Confirmed that only ctrl+v failed, tested with 4.2.3.3 Ubuntu 13.10 - Change OS to all - Set as New - Sophie

Thanks to the devs for Libreoffice, but...

Just fyi, while this bug may not be considered a BLOCKER by the developers, but it is a BLOCKER for us.

I started rolling out 4.2.4 the weekend before last, and got about 25 workstations done over the weekend.

Then, during the week, I discovered this bug, and had to start rolling everyone back very quickly to 4.1.6 due to the wailing and gnashing of teeth.

We have many templates with many Input fields on them, and running headlong into this dramatically changed behavior (for anyone with lots of templates with Input fields on them) was jarring enough, but being unable to paste into the Input fields is simply a show-stopper for us.

So we cannot upgrade past 4.1 until this is fixed.

I'd also really like to see consideration given to my bug 79877 to bring back the old pop-up behavior as an option (I'm fine with the new behavior as the default).

https://bugs.freedesktop.org/show_bug.cgi?id=79877

Almost filed a new bug report on this.

To reproduce:

1. Create any input field.
2. Copy any text.
3. Click on the input field.
4. Hit Ctrl+V.

Current behaviour: After step 4 nothing happens and the field remains selected, containing whatever it had before, awaiting typed input.

Expected behaviour: After step 4 the field is updated to contain the pasted text.


I have quite a few templates based on the old behaviour where I could copypaste numerous long, tedious strings of data very quickly. Now I'm stuck either going through the list in the Fields menu (extremely error-prone without the visual aid especially when you must manually click the checkmark to save each item) or typing everything out (with all the room for error that creates).

I only need to worry about myself so I'm staying with 4.2.5 for now, but I'm keeping a copy of LibreOffice_4.1.6_Win_x86.msi handy just in case.

(In reply to comment #7)
> Almost filed a new bug report on this.
> 
> To reproduce:
> 
> 1. Create any input field.
> 2. Copy any text.
> 3. Click on the input field.
> 4. Hit Ctrl+V.

In LO 4.1.6 after the step 3 (the mouse cursor becomes an hand over the input field) I get a new window named "Input Field" in which I can type or paste text.
In LO 4.2 and next 4.3 when clicking on the input field (when the mouse cursor becomes an hand as for an hyperlink in web browsers) nothing happens.

Best regards. JBF

Hi

I reproduce on windows 7/64 & Version: 4.3.0.3
Build ID: 08ebe52789a201dd7d38ef653ef7a48925e7f9f7

To reproduce:
1. File> New> Text
2. Insert> Fields> Others> Function tab> Input field> Insert
3. The input field dialog opens. Type "some text" in the text box> Ok> Close the Fields dialog
4. Type Enter (create a new paragraph), type "Foo", Select Foo, Copy
5. Click behind the input field, use the left arrow to bring the cursor between "some" & "text"

Verify that the Edit> Cut/Copy/Paste... are grayed out (inactive)

6. Hit Ctrl+V : Nothing is pasted

Regards
Pierre-Yves

(In reply to comment #9)
>
> Verify that the Edit> Cut/Copy/Paste... are grayed out (inactive)
> 

(In reply to comment #8)
>
> In LO 4.2 and next 4.3 when clicking on the input field
> (when the mouse cursor becomes an hand as for an hyperlink
> in web browsers) nothing happens.
>

That is disturbing because that's even worse than what I see (4.2.5.2 Win7 64-bit).

When I click on the input field, the entire field is selected, and under the Edit drop-down menu Cut and Copy are still available.

Is this a regression or has it been around forever. In the future please don't add bugs to MAB without knowing the procedure, just because it's "very annoying" to you, does not make it a MAB. That being said, additional tests would be helpful.

1. Is it a regression (did it ever work) - if you don't know, please check by downloading previous version of LibreOffice and trying (this is what we do in QA to add things to MAB list)

2. Set the priority to highest (not high)

3. Explain on the MAB list why you think it belongs there (on the tracker itself bug 65675)

In the old format, before the inline, you can

1. Copy any text
2. Click on any input field
3. Paste the text into the window that pops up
4. Hit Ctrl+Enter to save the new value


Now there is no way to do that just by clicking on the input field - you have to either:

a) go into the Variables tab of the Fields window (Ctrl+F2, then open the Variables tab, then hunt down the correct variable);

b) hit Ctrl+F9 and keep tapping "Next" until you find the correct variable (unreliable since you can easily overshoot your mark, forcing you to start all over again, AND the name of the variable is not displayed anywhere); or

c) double-click on a non-input field representing the same variable (which may not exist, or may be on a different page altogether).


Is it a "regression"? Certainly so from the user end, given we've lost a functionality that had previously been there, and what was once a very simple function is now an undue hassle requiring numerous clicks and item-hunting where a single click on the field was once sufficient. From a development end, however, it doesn't seem that pasting was ever implemented as a function in these new inline fields, but I could be wrong - which version was the first to introduce the new inline input fields?

Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3f26ab24e0bfd27645c97ff7915fba2db409930a

fdo#76565 Allow pasting into input fields



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Thanks Jan-Marek!!

Question though... target = 4.4?

Please tell me we're not going to have to skip all of the 4.3 release as well as the 4.2 release?

Hopefully this bug will be fixed in the 4.3 release?

Thanks again...

Please don't update the version field - it reflects the oldest version not the newest.

Anyone going to fix this bug in version 4.3? Working with this error is very stressful.

Feel free to submit a patch - we're powered by volunteers. Adding additional comments that don't add any detail other than "this bug sucks" just clutters the bug report. Again, feel free to (1) submit a patch, (2) find a developer to submit a patch, (3) pay a developer to submit a patch, or if all of these fail (4) wait for a volunteer to voluntarily tackle the issue.

Tested in Version: 4.4.0.0.alpha0+
Build ID: 8e4defe4b59a72fbe82f94b26e233ba36640c739
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2014-09-02_01:46:56

Is OK there.

(In reply to Charles from comment #14)
> Question though... target = 4.4?
> 
> Please tell me we're not going to have to skip all of the 4.3 release as
> well as the 4.2 release?

Bugs are first fixed in the master branch, and then backported to previous branches. It has been backported already to libreoffice-4-3, so expect a commit notification soon.

Great news, thank you Adolfo!

Ok, confirmed fixed for me too...

Thanks Jan-Marek and Adolfo!

adding target:4.3.3 for http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3-3&id=dfde5b967b27d9a44f35ce96cf99554722985bc5