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.
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.
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.
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...
Thank you.
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).
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
I could only reproduce in Windows with my method (Windows 7 in particular), but could reproduce it consistently. So, confirming it in Windows.
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
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?
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.
(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).
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
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
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
(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.
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 9b322ace3b8f316104f7138b082d2ffdb282c816 $ git bisect log # bad: [05d11632892a322664fb52bac90b2598b7fb7544] source 5616d22b57a9a5e57d545e912e029162a230829b # good: [c1efd324c6ad448ac9edb030dc9738b9e6899e4d] source ab465b90f6c6da5595393a0ba73f33a1e71a2b65 git bisect start 'origin/master' 'oldest' # good: [97526ab777da7e58ce283c05498262ecdd4d6f7f] source 4ea70f87f7a2b61eda6e5ab1f48debf6fcfadc1f git bisect good 97526ab777da7e58ce283c05498262ecdd4d6f7f # good: [86fee7ded76d9c2756ccab6aef160a2d7fab0ab6] source 1b62841b1859ae3443e2bf1ebe99ec3d6afb6cc2 git bisect good 86fee7ded76d9c2756ccab6aef160a2d7fab0ab6 # bad: [11864a7db429a57aeea021e0b3f1fb1412282d32] source e5b721a14c1c8e5261a70588b30353cbb5bd55c6 git bisect bad 11864a7db429a57aeea021e0b3f1fb1412282d32 # bad: [cec39174971f789b01d212afe8b5ffdd1ba466ca] source 76e75d2dd6dafe55fd1740693529640652ed6455 git bisect bad cec39174971f789b01d212afe8b5ffdd1ba466ca # good: [a8a2139bffcee59cfb8887106ac3f9bc6569cf9a] source 1848581f4f3a3f22e2d104a2890699c26d35e1e8 git bisect good a8a2139bffcee59cfb8887106ac3f9bc6569cf9a # bad: [51e0379831d38049a498ff5d6c70eb647c93dee8] source ac630469789b8b1fd93d3ae90acae83ed463d756 git bisect bad 51e0379831d38049a498ff5d6c70eb647c93dee8 # good: [ac87de9d4ee0020419ad1961156de4ac0321ec02] source 7bcd8ed0faaefb8fe3783d6e31dea5c727eddc2a git bisect good ac87de9d4ee0020419ad1961156de4ac0321ec02 # good: [f6420ff1264f1c468f3fbd5bf5429ff1b68b6b88] source 30cdd16cbfaaa34fd0da010bf4de18f9d649d22e git bisect good f6420ff1264f1c468f3fbd5bf5429ff1b68b6b88 # good: [884b901996cd55a4df0bfce490d3e842a291868a] source f99e8f84f5421076b6c0c10a592e43843eabd8ff git bisect good 884b901996cd55a4df0bfce490d3e842a291868a # bad: [1a5c56aa14e7b9a325cbb732a929b93eaebb7f1a] source 125f0c95b7f5613d71bcf107b73a0ba422d54643 git bisect bad 1a5c56aa14e7b9a325cbb732a929b93eaebb7f1a # good: [77442162720ce0a97195319f3782dce9bdf9d33c] source 623f5b26ffd77041d0b06d7ce9c3b32d05625440 git bisect good 77442162720ce0a97195319f3782dce9bdf9d33c # bad: [b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1] source 9b322ace3b8f316104f7138b082d2ffdb282c816 git bisect bad b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1 # good: [ad463231323943d069dae745ebc4b8eea2ced3ad] source ce15c93cec284440244e63bea75a016e9f2c9f04 git bisect good ad463231323943d069dae745ebc4b8eea2ced3ad # first bad commit: [b52018ea405c53d0c3cf4cd465ffd1dc80dd15a1] source 9b322ace3b8f316104f7138b082d2ffdb282c816
*** Bug 104562 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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!
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.