Bug Hunting Session
Bug 125887 - Double click works differently to 'Select Word' .UNO command
Summary: Double click works differently to 'Select Word' .UNO command
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-12 17:55 UTC by TorrAB
Modified: 2019-07-14 07:14 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
file with 3 words (13.48 KB, application/vnd.oasis.opendocument.text)
2019-06-12 17:55 UTC, TorrAB
Details
file with 5 words to select (13.77 KB, application/vnd.oasis.opendocument.text)
2019-07-01 23:51 UTC, TorrAB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description TorrAB 2019-06-12 17:55:48 UTC
Created attachment 152141 [details]
file with 3 words

Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate).
Open words.odt; put cursor near
	 A or B, hit ~w: 'AB' is selected: OK;
	 M or N, hit ~w: 'MN' is selected: OK;
	 C or D, hit ~w: comma is selected! Double-click works, with hardblank included.
Comment 1 Dieter Praas 2019-06-24 19:16:27 UTC
(In reply to TorrAB from comment #0)
> Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate).

Can't find the command InsertWord. Do you mean Select Word?
Comment 2 TorrAB 2019-06-24 23:01:59 UTC
(In reply to Dieter Praas from comment #1)
> (In reply to TorrAB from comment #0)
> > Assign a key (eg, ~w) to InsertWord (Tools>Customize kbd>Navigate).
> 
> Can't find the command InsertWord. Do you mean Select Word?

Yes! Sorry about that.
Comment 3 Dieter Praas 2019-06-29 08:14:56 UTC
I confirm that beaviour with

Version: 6.2.5.1 (x64)
Build-ID: 9a940173fab1747f02322bc89779759d52b3a086
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

and

Version: 6.4.0.0.alpha0+ (x64)
Build ID: ae823e4633a76d13cebc6432b9e44b9b2862326b
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-26_23:06:07
Locale: de-DE (de_DE); UI-Language: en-US
Calc: threaded


I think the reason is the protected space between comma and CD => I changed bug summary a little.
Comment 4 V Stuart Foote 2019-06-29 12:40:45 UTC
Not sure this is a bug.

Use of the NBS (U+00a0) depends on placement relative to punctuation. That is when prepended (i.e. following the comma) is included with a "double click" mouse selection.  Likewise is included when the NBS is appended (i.e. preceding the closing parehnthesis ). And again included with the "double click" mouse selection, or the "Select Word" UNO action.

So this handling of NBS is either hard coded in edit engine, or is an ICU lib function (have not checked src).

Believe it is wrapped up in the way we handle selection at ICU 'word' bounds. And we have at least three UNO actions that can be used.

1. double mouse click
2. Select Word (assigned by OP, but action of double mouse click) 
3. Select to Beginning of Word (assigned <Ctl>+<Shift>+<L cursor>)
4. Select to Word Right (assigned <Ctl>+<Shift>+<R cursor>)

Anyhow the handling is consistent--the NBS is included with the correct word depending on leading or trailing punctuation. So Not A Bug?

And, to select the literal of the middle word, rather than double click or the "Select Word" action--position cursor and select to begining of Word, or select to end of Word (labeled as Select to Word Right)--both of which have assigned keyboard shortcuts.
Comment 5 V Stuart Foote 2019-06-30 13:14:38 UTC
The edit engine handling of the selections at word bounds is done in impedit2.cxx, no special logic for NBS or other NPC noted. Meaning, IIUC the word boundary is as provided by ICS lib.

https://opengrok.libreoffice.org/xref/core/editeng/source/editeng/impedit2.cxx?&r=a682d129&h=1412#1480
Comment 6 V Stuart Foote 2019-06-30 16:52:03 UTC
s/ICS/ICU
Comment 7 TorrAB 2019-07-01 23:51:05 UTC
Created attachment 152495 [details]
file with 5 words to select
Comment 8 Eike Rathke 2019-07-09 17:10:53 UTC
(In reply to V Stuart Foote from comment #5)
> The edit engine handling
The Writer text core doesn't use EditEngine to determine word boundaries though..
Comment 9 Heiko Tietze 2019-07-13 07:28:56 UTC
(In reply to V Stuart Foote from comment #5)
> Meaning, IIUC the word boundary is as provided by ICS lib.

So NAB/NOB?

Protected space as well as non-breaking spaces or any other special space are formatting aids, they don't separate one word from the other. Like sticking units to the number. What I mean, I don't see the scenario where protected space is used and word selection is expected as requested.
Comment 10 TorrAB 2019-07-13 16:51:08 UTC
(In reply to Heiko Tietze from comment #9)
> (In reply to V Stuart Foote from comment #5)
> > Meaning, IIUC the word boundary is as provided by ICS lib.
> 
> So NAB/NOB?
> 
> Protected space as well as non-breaking spaces or any other special space
> are formatting aids, they don't separate one word from the other. Like
> sticking units to the number. What I mean, I don't see the scenario where
> protected space is used and word selection is expected as requested.

'non-breaking spaces or any other special space […] don't separate one word from the other'. True.
But, try this again: Put cursor between f and g, hit ~w: the 4 dashes are selected, but 'efgh' (which was targeted) is NOT! NAB, really?
Comment 11 V Stuart Foote 2019-07-13 17:48:47 UTC
(In reply to TorrAB from comment #10)
> (In reply to Heiko Tietze from comment #9)

The valid 'bug' here is difference in behavior of Word selection.

A double mouse click correctly selects to full word bounds, with correct handling of NPC as expected.

A customized shortcut assigned the 'Select Word' UNO action does not. And in fact is loosing its position passing over the NPC and selecting the preceeding word's text run!

With shortcut assigned for Select Word, open attachment 152495 [details]

Position text cursor to the word 'efgh' and enter the shortcut. Selection jumps backward to the '---- ' word. Whilst a double mouse click will select the ' efgh'.

Similar misbehavior if positioned at ' CDEF'. A double mouse click will select the word, but using the shortcut 'Word Select' will jump backward and select ',;:!* '

=-testing-=
Windows 10 Home 64-bit en-US (1809) with
Version: 6.4.0.0.alpha0+ (x64)
Build ID: 2f2f4767089512c34514896bc37823f9310e9dd4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-07-10_02:13:57
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded

or with

Version: 6.2.5.2 (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 12 Heiko Tietze 2019-07-14 07:14:57 UTC
(In reply to V Stuart Foote from comment #11)
> ...
> A double mouse click correctly selects to full word bounds, with correct
> handling of NPC as expected.
> 
> A customized shortcut assigned the 'Select Word' UNO action does not. And in
> fact is loosing its position passing over the NPC and selecting the
> preceeding word's text run!

True, that's a nasty bug. Removing UX.