Download it now!
Bug 100626 - SID_NEWDOCDIRECT / .uno:AddDirect assigned N_MOD1 and File menu action, opens a new document but does not direct edit cursor focus into the document
Summary: SID_NEWDOCDIRECT / .uno:AddDirect assigned N_MOD1 and File menu action, open...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.5.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 104562 (view as bug list)
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2016-06-26 20:01 UTC by ken
Modified: 2017-12-11 18:58 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ken 2016-06-26 20:01:50 UTC
I hit Ctrl+N to open a new document.  It opens, but doesn't have focus.  I can hit Alt+Tab twice (i.e., switch away and back with the keyboard) and then focus will be correct.
Comment 1 V Stuart Foote 2016-06-26 20:14:04 UTC
Actually the new frame holding the new document does have focus. 

But to position edit cursor into the document <F10> is the more certain keyboard movement once to the main menu and again to enter document canvas. A mouse click into the document canvas works as well.

Don't see this as an issue.
Comment 2 ken 2016-06-26 20:21:45 UTC
Why is this not seen as an issue?

My workflow involves primarily the keyboard, and I rarely touch the mouse.

If I have a thought and want to start a new document, I hit Ctrl+N and start typing.

Your mention of F10 or clicking is immaterial.  OpenOffice behaved the correct way, but I switched to LibreOffice when I found that the bug they had ignored for years had been fixed by your team (that being, a Ctrl+Backspace eats the space after the previous word, so I always had to hit the space bar after Ctrl+Backspace, unlike any other interface).

It sounds like you're saying that I should just get used to an extra keystroke or mouse click for the LibreOffice interface.  I don't think that's providing good service.

Perhaps my initial description was too short.  I don't want a method of getting focus, I want this to behave the same way OpenOffice does -- the cursor should be sitting there blinking in the document right after I hit Ctrl+N.

Reopening.
Comment 3 V Stuart Foote 2016-06-26 21:46:09 UTC
On Windows 10 Pro 64-bit en-US with
Version: 5.2.0.1 (x64)
Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

Version: 5.1.2.2 (x64)
Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
Locale: en-US (en_US)

Version: 5.0.6.3 (x64)
Build ID: 490fc03b25318460cfc54456516ea2519c11d1aa
Locale: en-US (en_US)

Version: 4.4.6.3
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: en_US

Actually just compared launch in the earlier builds, and seems that starting with the 5.0 branch there is a subtle regression against 4.4.6 builds.

STR.

1. open to Start Center
2. <alt>+F to open main menu
3. N to open new menu
4. T to open new text document

Expected:
document frame active, and edit cursor in the document canvas with keyboard control (behavior through 4.4.6.3)

Result:
document frame active, no visible element has focus--keyboard movements not possible. *Keyboard trapped*. Mouse movement responds to position and GUI element--but a mouse click or <alt>+<Tab> away from the frame is needed.

Same related behavior as OP reports is -- a <ctrl>+N, or <alt>+<F> + N + T, opens new document and frame is active, but no visible element has focus. Keyboard trapped--have to use mouse, or move to another window and back to gain focus.

And, once launched one time from Start Center with a mouse action, subsequent document launch from Start Center will have edit cursor focus. 

The <ctrl>+n, or <alt>+F + N + T may, or may not gain edit cursor focus--seems erratic. But something is amiss...
Comment 4 ken 2016-06-26 22:02:59 UTC
Thank you.
Comment 5 Aron Budea 2016-06-26 23:11:04 UTC
I tried, and could not reproduce this at first, not even with the steps Stuart mentioned. However, these are consistent reproduction steps for me:

1. open to Start Center
2. press and release Alt, then Down, then Right, then Enter. (this will lead to the same menu item as Alt+F, N, T)

Still okay with 5.0.0.5.
Issue is reproducible with 5.0.5.2, 5.1.3.2, 5.2.0.1, master build (32-bit/64-bit versions mixed).
Comment 6 Jean-Baptiste Faure 2016-06-27 07:25:03 UTC
Please, do not set your own bug report to NEW. Each bug report should be independently confirmed.
Set back to UNCONFIRMED.

I do not reproduce the described problem under Ubuntu. Windows only issue?

Best regards. JBF
Comment 7 Aron Budea 2016-06-27 08:27:28 UTC
I could only reproduce in Windows with my method (Windows 7 in particular), but could reproduce it consistently.
So, confirming it in Windows.
Comment 8 V Stuart Foote 2016-06-27 12:42:48 UTC
Jean-Baptiste,

(In reply to Jean-Baptiste Faure from comment #6)
> Please, do not set your own bug report to NEW. Each bug report should be
> independently confirmed.
> Set back to UNCONFIRMED.

No, that is my fault. 

OP had reset NEW after I'd NAB'd it. And while poking at it some more I found what seems a regression pointing at the root cause (morphing the issue a bit), so to NEW was fine. Aron and I both confirm the restated issue.

Think we're on track here now.

Stuart
Comment 9 V Stuart Foote 2016-06-27 23:53:07 UTC
So, chasing this down a bit further and the common element between the cases seems to be behavior of the .uno:AddDirect SID_NEWDOCDIRECT action of the N_MOD1 shortcut or the assigned menu action.

This seems to only affect Windows. The "<Ctrl>+N" (N_MOD1) shortcut, or File -> New -> Text Document menu, which using the .uno:AddDirect action opens a new document, a Writer document from the Start Center (StartModule), or as reported by OP when opening a new document from Writer.

Both use the same .uno:AddDirect, and in both cases as the new document is opened, it does not receive edit cursor focus onto the document canvas.

Looks like it could be the work on SFX2--appopen.cxx or viewfrm2.cxx?
Comment 10 Aron Budea 2016-06-28 22:34:09 UTC
My curious observations after opening Start Center:

-I can't reproduce the issue by repeating Stuart's steps from Comment 3 (Alt+F, N, T),

-if I do nothing else, but press Ctrl+N right after launch, nothing happens, I have to Alt+Tab out and back, or click in the window, and then Ctrl+N opens new document.
Comment 11 V Stuart Foote 2016-06-28 23:23:14 UTC
(In reply to Aron Budea from comment #10)
> My curious observations after opening Start Center:
> 
> -I can't reproduce the issue by repeating Stuart's steps from Comment 3
> (Alt+F, N, T),
> 
> -if I do nothing else, but press Ctrl+N right after launch, nothing happens,
> I have to Alt+Tab out and back, or click in the window, and then Ctrl+N
> opens new document.

The <Ctrl>+N shortcuts have been disrupted by work on the <Alt> accelerator toggle for GTK3.

But, you can see this issue with the .uno:AddDirect if as the OP reported, you launch Writer from StartCenter on its initial launch--then open a second Writer instance with the <Ctrl>+N shortcut (or the File -> New -> Document menu).
Comment 12 raal 2016-10-01 03:50:32 UTC
no repro:Version: 5.3.0.0.alpha0+
Build ID: 73c7e0921d752df53004ed55735f3e8888cc592f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: en-US (cs_CZ); Calc: group
Comment 13 V Stuart Foote 2016-10-01 12:46:42 UTC
Concur. Resolving WFM

No longer able to reproduce (any of the STR), Windows 10 Pro 64-bit (ver 1607) en-US with either

Version: 5.2.2.2 (x64)
Build ID: 8f96e87c890bf8fa77463cd4b640a2312823f3ad
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US); Calc: group

or

Version: 5.3.0.0.alpha0+
Build ID: 89a3f825559753d6600807342ca96c169cd58c87
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-09-29_23:19:33
Locale: en-US (en_US); Calc: group
Comment 14 Aron Budea 2016-10-01 21:13:44 UTC
My method from comment 5 still results in the new document not getting the focus.
Tested with 5.2.2.2 and the below daily master build.

Version: 5.3.0.0.alpha0+
Build ID: cf4ff92144726a91508fcaf4be21170eac5cb99a
CPU Threads: 4; OS Version: Windows 6.1; UI Render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-10-01_00:13:03
Locale: hu-HU (hu_HU); Calc: group
Comment 15 V Stuart Foote 2016-10-01 23:10:51 UTC
(In reply to Aron Budea from comment #14)
> My method from comment 5 still results in the new document not getting the
> focus.

Confirmed, with 5.2.2.2 on Windows 10 Pro 64-bit en-US ( 8f96e87c890bf8fa77463cd4b640a2312823f3ad) but only on the launch case from the Start Center on initial launch, the more annoying launch of a subsequent New document from within an open document no longer has the glitch--cursor focus is into the canvas.
Comment 16 raal 2016-10-02 09:05:28 UTC
This seems to have begun at the below commit.
Adding Cc: to Aybuke Ozdemir; Could you possibly take a look at this one? Thanks

 Steps in comment 5:
1. open to Start Center
2. press and release Alt, then Down, then Right, then Enter. (this will lead to the same menu item as Alt+F, N, T)
Fails only on the launch case from the Start Center on initial launch.


author	Aybuke Ozdemir <aybuke.147@gmail.com>	2015-10-23 20:12:08 (GMT)
committer	Katarina Behrens <Katarina.Behrens@cib.de>	2015-10-27 15:48:24 (GMT)
commit	9b322ace3b8f316104f7138b082d2ffdb282c816 (patch)
tree	8b6af4882088744d1a1217cd4108889a0002a66f
parent	ce15c93cec284440244e63bea75a016e9f2c9f04 (diff)
tdf#88548 fontwork gallery always have transparent/checkered background.

    source sha:9b322ace3b8f316104f7138b082d2ffdb282c816
$ git bisect log
# bad: [05d11632892a322664fb52bac90b2598b7fb7544] source sha:5616d22b57a9a5e57d545e912e029162a230829b
# good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source sha:ab465b90f6c6da5595393a0ba73f33a1e71a2b65
git bisect start 'origin/master' 'oldest'
# good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source sha:4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f
git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f
# good: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source sha:1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2
git bisect good 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6
# bad: [11864a7db429a57aeea021e0b3f1fb1412282d32] source sha:e5b721a14c1c8e5261a70588b30353cbb5bd55c6
git bisect bad 11864a7db429a57aeea021e0b3f1fb1412282d32
# bad: [cec39174971f789b01d212afe8b5ffdd1ba466ca] source sha:76e75d2dd6dafe55fd1740693529640652ed6455
git bisect bad cec39174971f789b01d212afe8b5ffdd1ba466ca
# good: [a8a2139bffcee59cfb8887106ac3f9bc6569cf9a] source sha:1848581f4f3a3f22e2d104a2890699c26d35e1e8
git bisect good a8a2139bffcee59cfb8887106ac3f9bc6569cf9a
# bad: [51e0379831d38049a498ff5d6c70eb647c93dee8] source sha:ac630469789b8b1fd93d3ae90acae83ed463d756
git bisect bad 51e0379831d38049a498ff5d6c70eb647c93dee8
# good: [ac87de9d4ee0020419ad1961156de4ac0321ec02] source sha:7bcd8ed0faaefb8fe3783d6e31dea5c727eddc2a
git bisect good ac87de9d4ee0020419ad1961156de4ac0321ec02
# good: [f6420ff1264f1c468f3fbd5bf5429ff1b68b6b88] source sha:30cdd16cbfaaa34fd0da010bf4de18f9d649d22e
git bisect good f6420ff1264f1c468f3fbd5bf5429ff1b68b6b88
# good: [884b901996cd55a4df0bfce490d3e842a291868a] source sha:f99e8f84f5421076b6c0c10a592e43843eabd8ff
git bisect good 884b901996cd55a4df0bfce490d3e842a291868a
# bad: [1a5c56aa14e7b9a325cbb732a929b93eaebb7f1a] source sha:125f0c95b7f5613d71bcf107b73a0ba422d54643
git bisect bad 1a5c56aa14e7b9a325cbb732a929b93eaebb7f1a
# good: [77442162720ce0a97195319f3782dce9bdf9d33c] source sha:623f5b26ffd77041d0b06d7ce9c3b32d05625440
git bisect good 77442162720ce0a97195319f3782dce9bdf9d33c
# bad: [b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1] source sha:9b322ace3b8f316104f7138b082d2ffdb282c816
git bisect bad b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1
# good: [ad463231323943d069dae745ebc4b8eea2ced3ad] source sha:ce15c93cec284440244e63bea75a016e9f2c9f04
git bisect good ad463231323943d069dae745ebc4b8eea2ced3ad
# first bad commit: [b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1] source sha:9b322ace3b8f316104f7138b082d2ffdb282c816
Comment 17 Roland Illig 2016-12-10 19:30:05 UTC
*** Bug 104562 has been marked as a duplicate of this bug. ***
Comment 18 QA Administrators 2017-12-11 08:53:54 UTC Comment hidden (obsolete)
Comment 19 ken 2017-12-11 18:15:29 UTC
This is no longer an issue in Version: 5.4.3.2 (x64) for Windows (8.1 x64).

I am resolving my bug as "FIXED".  Thank you!
Comment 20 V Stuart Foote 2017-12-11 18:58:56 UTC
No specific commit identified in resolving this. But with 
Version: 6.0.0.0.beta1 (x64)
Build ID: 97471ab4eb4db4c487195658631696bb3238656c
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
Locale: en-US (en_US); Calc: group threaded

None of the STR reproduce. Seems WFM.