Bug 54743 - [FORMATTING] Shift+F3 works unexpected (uppercase and lowercase)
Summary: [FORMATTING] Shift+F3 works unexpected (uppercase and lowercase)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.0.beta1
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Character CaseFolding
  Show dependency tree / graph
 
Reported: 2012-09-10 18:42 UTC by Kü
Modified: 2022-05-18 14:07 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Visualization of work (17.84 KB, image/gif)
2019-01-17 05:56 UTC, Дмитрий 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Kü 2012-09-10 18:42:19 UTC 
Working with Shift+F3 for rotation of uppercase and lowercase acts unexpected. A word with lowercase is sometimes working correct:

example -> Example -> EXAMPLE -> example -> etc.

Sometimes it happens, that it is working as followed:

example -> EXAMPLE -> example -> Example -> EXAMPLE -> example -> etc.

A word with uppercase also is sometimes working correct:

Example -> EXAMPLE -> example -> etc.

But sometimes happens the following:

Example -> Example -> EXAMPLE -> example -> etc.

After one passage it is always working correct. It is working correct too if you rotated a word in the past and rotate it later again.

With this functionality you always must look what happens, and can't typing blind.
Comment 1 dhirenjani 2012-12-14 12:02:43 UTC 
I can confirm this bug on platform Windows Vista with 4.0 beta1

Note: It is not happening every time, but rather when a new line or new word is entered and the action attempted.
Test:
1. Create a new document
2. Write a word in CAPS and use Shift+F3
Expected Rotation: CAPS->caps->Caps->CAPS
Actual Rotation: CAPS->Caps->CAPS->caps->Caps->CAPS
Comment 2 QA Administrators 2015-01-05 17:52:22 UTC Comment hidden (obsolete)
Comment 3 Kü 2015-01-05 18:31:12 UTC 
The behavior is the same as reported.

Tested on Debian Testing (jessie) amd64 with:
- version 4.3.3.2 from Debian repository, Build-ID: 430m0(Build:2)
- version 4.3.5.2 in parallel, Build-ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5
- version 4.4.0.1 in parallel, Build-ID: 1ba9640ddd424f1f535c75bf2b86703770b8cf6f
Comment 4 QA Administrators 2016-01-17 20:05:03 UTC Comment hidden (obsolete)
Comment 5 Kü 2016-01-18 06:46:34 UTC 
I can't reproduce it with the first example, it works correct for me:

example -> Example -> EXAMPLE -> example -> etc.

The second example has reliable the wrong(?) behavior of:

Example -> Example -> EXAMPLE -> example -> etc.

Tested with 5.0.4.2, 5.1.0.1 and 5.2.0.0.alpha (from 2016-01-04).
Comment 6 QA Administrators 2017-03-06 14:35:37 UTC Comment hidden (obsolete)
Comment 7 Kü 2017-09-17 03:49:43 UTC 
The bug is still present in current versions. Tested with LO 5.4.1.2 from Debian repository and LO-Dev 6.0 (2017-07-20) in parallel.
Comment 8 QA Administrators 2018-09-18 02:49:54 UTC Comment hidden (obsolete)
Comment 9 Дмитрий 2019-01-17 05:56:33 UTC 
Created attachment 148383 [details]
Visualization of work
Comment 10 Dominik Lenné 2019-03-13 11:50:23 UTC 
confirmation in V. 6.2.0.3 (x64) on Windows10.

select word "start"
hit sh+f3   --> "START"
hit sh+f3   --> "start" (goes back to where it started)
hit sh+f3   --> "Start" (which is what I wanted)
select other word "end"
hit sh+f3   --> "start" "end" (first change has been reversed!) *
hit sh+f3   --> "END"
hit sh+f3   --> "end"  (again goes back to where it started)
hit sh+f3   --> "End"

* Interestingly, every word with capital first letter in the same sentence preceding "start" is changed to all-lowercase!
Comment 11 Mihail Balabanov 2021-02-09 12:16:27 UTC 
Since the current built-in behavior is not likely to be changed any time soon, I wrote a Basic macro for Cycle Case which honors the selection, autoselects only a single word when there is no selection, uses the current case of the selected text for a starting point instead of a counter, and can cycle the case of word the user just typed (including when there is already a space between it and the cursor).

https://extensions.libreoffice.org/en/extensions/show/4036
Comment 12 Stéphane Guillou (stragu) 2021-12-15 13:27:34 UTC 
Reproduced, although slightly differently, in:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 06ac18e6302d666c363740644a7976e8c22d1113
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

My steps:
1. New document
2. Add three lines with the following words respectively: START, start, Start
3. With cursor in each, cycle with the Shift + F3 shortcut until you see the repeated pattern.

Results (in square brackets is the sequence that repeats):

START > [Start > Start > START > start]
start > [start > Start > Start > START]
Start > [start > Start > Start > START]

So, for all three cases, the sequence that repeats is the same, but the first modification (or lack thereof) is inconsistent. It's as if the original form was not detected properly.

The issue with it affecting surrounding words is described in Bugs 144851, 145121, and probably others.
Comment 13 LeroyG 2022-05-17 20:15:44 UTC 
In a new Writer document, select "TEXT text Text tExt" (sentence after "0. "), and press "Shift+F3"

Actual/Expected results:
0. TEXT text Text tExt - original
1. Text Text Text Text - Title Case
2. Text text text text - Sentence case
3. TEXT TEXT TEXT TEXT - UPPERCASE
4. text text text text - lowercase
The cycle returns to 1.

In a new Writer document, select "TEXT" (first word after "0. "), and press "Shift+F3"

Actual results:
0. TEXT text Text tExt - original
1. Text text Text tExt - Title Case
2. Text text text text - Sentence case
3. TEXT text text text - UPPERCASE inherits the error
4. text text text text - lowercase inherits the error
1. Text text text text - Title Case inherits the error

Actual/Expected results:
2. Text text text text - actual
2. Text text Text tExt - expected

Tested with:
Version: 7.2.7.2 (x86) / LibreOffice Community
Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: es-MX (es_MX); UI: en-US
Calc: threaded

Tested with:
Version: 7.3.2.2 (x86) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: es-MX (es_MX); UI: es-ES
Calc: threaded
Comment 14 Michael Warner 2022-05-18 14:07:41 UTC 
The report in Comment 13:

> Actual/Expected results:
> 2. Text text text text - actual
> 2. Text text Text tExt - expected

Sounds like a duplicate of Bug 49033, which was fixed in 7.3.0. So, if it also occurs in 7.3.2.2 that would be a regression. There has been more work on this code since then, so please re-test with the 7.4.0 alpha available here: 
https://www.libreoffice.org/download/download/?type=mac-x86_64&version=7.4.0&lang=en-US

If it occurs in 7.4.0, open a new bug report and mark it as a regression. Because  this was/is a different bug from what is reported in Comment 0 (where the rotation isn't consistent), so I am not marking this BZ item as a duplicate.