Bug 117017 - Text formatting .uno:Subscript, .uno:Superscript work from menu and Sidebar deck, but not completed with assigned keyboard shortcut
Summary: Text formatting .uno:Subscript, .uno:Superscript work from menu and Sidebar d...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.4.6.2 release
Hardware: All All
: medium normal
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:6.1.0 target:6.0.5
Keywords:
: 117908 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-04-15 08:40 UTC by PN
Modified: 2018-05-31 09:21 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen cast demonstrating issue (841.40 KB, video/mp4)
2018-04-15 08:40 UTC, PN
Details

Note You need to log in before you can comment on or make changes to this bug.
Description PN 2018-04-15 08:40:29 UTC
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.
Comment 1 Jean-Baptiste Faure 2018-04-15 16:08:34 UTC
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
Comment 2 V Stuart Foote 2018-04-15 16:26:53 UTC
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.
Comment 3 V Stuart Foote 2018-04-15 16:56:54 UTC
(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.
Comment 4 Maxim Monastirsky 2018-04-15 21:16:17 UTC
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/
Comment 5 Commit Notification 2018-04-17 09:54:36 UTC
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.
Comment 6 Eike Rathke 2018-04-17 10:14:26 UTC
@Maxim:
May it be that bug 116329 has the same cause?
Comment 7 Maxim Monastirsky 2018-04-17 12:33:02 UTC
(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).
Comment 8 Xisco Faulí 2018-04-19 09:23:40 UTC
Cherry-picked to 6.0: https://gerrit.libreoffice.org/#/c/53144/
Comment 9 Maxim Monastirsky 2018-04-22 22:36:07 UTC
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?
Comment 10 Eike Rathke 2018-04-23 14:58:11 UTC
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.
Comment 11 Maxim Monastirsky 2018-04-23 20:51:00 UTC
(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;
Comment 12 Commit Notification 2018-04-27 11:36:03 UTC
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.
Comment 13 Maxim Monastirsky 2018-04-27 12:00:14 UTC
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.
Comment 14 Commit Notification 2018-05-04 15:29:46 UTC
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.
Comment 15 Maxim Monastirsky 2018-05-31 09:21:43 UTC
*** Bug 117908 has been marked as a duplicate of this bug. ***