Created attachment 141375 [details] Screen cast demonstrating issue I would like to be able to subscript part of a cell's text using keyboard shortcuts. Selecting the text part, and picking Format->Text->Subscript works. However, clicking the equivalent keyboard shortcut (that appears in beside the menu, in my case Shift-Ctrl-B) puts the selected text in subscript but the formatting is lost if I hit ENTER or navigate to an other cell (by clicking with the mouse, for example). In summary, picking the entry through the menu using the mouse and typing the corresponding shortcut do not have the same effect. A screencast demonstrating the issue is attached. The rendering glitches are unrelated and due to the intel graphics driver.
It works if you select the text part in the cell instead of in the formula bar. The problem (if it is a problem) is the same with other formatting like bold, italic or underline. I guess that the formula bar is not the right place to apply formatting. According to https://help.libreoffice.org/6.0/en-US/text/scalc/guide/super_subscript.html it is not a bug because it works as designed. Best regards. JBF
Confirmed on Windows 10 Home 64-bit en-US with Version: 6.1.0.0.alpha0+ (x64) Build ID: 55e84652ae84bd2374462ee19afd359a8cc90b95 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-13_05:08:28 Locale: en-US (en_US); Calc: CL Seems to be an issue with keypress--the Subscripted, or Superscripted, keyboard accelerators are linked to the .uno:Subscript, or .uno:Superscript, and will apply the format to the selected text while the B, or P, is held keydown. But on release the formating reverts. From Format -> Text menu or the Sidebar Properties deck, the menu item or button press applies the formatting and it is retained.
(In reply to Jean-Baptiste Faure from comment #1) > It works if you select the text part in the cell instead of in the formula > bar. Yes, it does work with a selection made from the cell. And, likely how most folks would be applying the formatting. But the formatting does apply to a selection made in the Formula Bar when the .uno command are applied from the menu or the sidebar panel--just not when done with the keyboard. Which momentarily toggles the format, but releases it. To me that seems some mishandling of the keyboard shortcut and .uno when focus and text selection is in the Formula Bar.
The revert of formatting is caused by the releasing of the modifier key (Ctrl). The same effect can be reproduced also if applying the formatting using the menu, and then pressing Ctrl. I hope that simply ignoring all modifier key changes here is OK (didn't notice any problems so far): https://gerrit.libreoffice.org/52924/
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a860c94f0da22065074cc36e8ddda73261641533 tdf#117017 Make modifier keys not trigger the InputChanged handler It will be available in 6.1.0. 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.
@Maxim: May it be that bug 116329 has the same cause?
(In reply to Eike Rathke from comment #6) > @Maxim: > May it be that bug 116329 has the same cause? It appears so. The hyperlink breaks after pressing the modifier key, and it doesn't happen if using the toolbar button or menu to copy the hyperlink. And the patch seems to fix it as well. There is also somewhat similar Bug 70597 which is about destroying the hyperlink with a right click. I suspect it can be fixed in a similar way, this time for CommandEventId::ContextMenu (but had no chance to try it yet).
Cherry-picked to 6.0: https://gerrit.libreoffice.org/#/c/53144/
Now I noticed that the format resetting via modifier keys was done on purpose for Bug 113894, but I don't understand that report: 1. By default a copy-paste procedure preserves formatting. Why there should be a difference if pasting while the focus is inside the formula bar? 2. Even if pasting into the formula bar really should strip formatting like Bug 113894 wants, it's odd that it's implemented via pressing of a modifier key. 3. As it was after the fix of Bug 113894, users were getting different results when pasting via toolbar/menu, or if assigned a different keyboard shortcut for the paste command. 4. AFAICS resetting of the format is a relatively new behavior, as old LO releases didn't have it. So I still think that modifier keys should not change formatting, and Bug 113894 should be instead closed as WONTFIX. @Eike: What's your take on this?
Ugh.. I think bug 113894 is right, pasting arbitrarily formatted text into the Input Line should not retain the formatting (different to pasting into the cell). However, it shouldn't depend on (release of) modifier keys. No quick idea right now though how that should be correctly handled in the code.
(In reply to Eike Rathke from comment #10) Maybe we can paste as unformatted text when the focus is in the formula bar (so users could still override this with the paste special dialog or the toolbar button), i.e. something like this: diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx index e3e6ec2f35de..75ddf11ece37 100644 --- a/sc/source/ui/app/inputwin.cxx +++ b/sc/source/ui/app/inputwin.cxx @@ -1468,7 +1468,8 @@ void ScTextWnd::StartDrag( sal_Int8 /* nAction */, const Point& rPosPixel ) void ScTextWnd::KeyInput(const KeyEvent& rKEvt) { bInputMode = true; - if (!SC_MOD()->InputKeyEvent( rKEvt )) + if (rKEvt.GetKeyCode().GetFunction() == KeyFuncType::PASTE || + !SC_MOD()->InputKeyEvent( rKEvt )) { bool bUsed = false; ScTabViewShell* pViewSh = ScTabViewShell::GetActiveViewShell(); diff --git a/sc/source/ui/view/editsh.cxx b/sc/source/ui/view/editsh.cxx index 804401b303f4..5c8d00bff7b3 100644 --- a/sc/source/ui/view/editsh.cxx +++ b/sc/source/ui/view/editsh.cxx @@ -217,7 +217,11 @@ void ScEditShell::Execute( SfxRequest& rReq ) break; case SID_PASTE: - pTableView->PasteSpecial(); + if (pTopView && pTopView->GetWindow()->HasFocus()) + pTableView->Paste(); + else + pTableView->PasteSpecial(); + if (pTopView) pTopView->Paste(); break;
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=632bc11ce8fab1c4046ab24810b90a7ce9ac5914 tdf#117017 Pasting into the formula bar shouldn't retain formatting It will be available in 6.1.0. 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.
I believe the current behavior is reasonable, and at least not worse than what was before. Would be great to get some feedback about current master (for this bug and Bug 113894) before considering a backport.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=599ab0f82ebcb29a5205d77daed72b842e839800&h=libreoffice-6-0 tdf#117017 Make modifier keys not trigger the InputChanged handler It will be available in 6.0.5. 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.
*** Bug 117908 has been marked as a duplicate of this bug. ***
*** Bug 114046 has been marked as a duplicate of this bug. ***