After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 785187 - Broken text formatting shortcuts in composer
Broken text formatting shortcuts in composer
Status: RESOLVED FIXED
Product: geary
Classification: Other
Component: composer
master
Other Linux
: Normal normal
: 0.13.0
Assigned To: Geary Maintainers
Geary Maintainers
Depends on: 778738
Blocks:
 
 
Reported: 2017-07-20 18:39 UTC by Kacper Bielecki
Modified: 2019-02-13 14:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kacper Bielecki 2017-07-20 18:39:17 UTC
I am using Geary version compiled from master (master~ge4563d8a) on Ubuntu 17.04 with Gnome.

Text formatting shortcuts (CTRL-i, CTRL-b, CTRL-u) are completely broken in embedded composer. However, they work fine with composer in a separate window.
Comment 1 Kacper Bielecki 2017-07-22 12:25:33 UTC
It looks like the root of the problem is a conflict of some text formatting shortcuts in the composer with the controller shortcuts:

 - <CTRL>I - marking a message as read (this has also <SHIFT>I shortcut)
 - <CTRL>U - marking a message a unread (this has also <SHIFT>U shortcut)
 - <CTRL>B - moving focus to conversation list

I could disable the whole controller action group in case user switches focus to embedded composer web view. I don't think there are any meaningful shortcuts defined in controller that user would want to use while composing email in embedded composer.

Most of them doesn't work as expected anyway. For example <CTRL>F will trigger search but non searched phrase would be matched in composer...

Otherwise, I could also change conflicting shortcuts in controller to their shift equivalents.

What do you think?
Comment 2 Michael Gratton 2018-02-07 05:33:57 UTC
There's some code that attempts to work around this already in ComposerContainer.{add,remove}_accelerators(), so maybe that's not quite doing the right job?

Using master they are currently working fine for composers in the main window, but also activate the associated main-window actions, which is pretty poor. This might have changed when we migrated main window actions from GtkAction to GAction.

The correct fix would probably be to implement the composer actions as action signals rather than using GActions for them like we do at the moment. Action signals would mean the actions are scoped to the current widget focus chain, which is exactly what we want, whereas GActions are more appropriate for app-wide or window-wide actions.

See Bug 778738 for more details, and we might need to fix that anyway so we can remove the MainWindow.key_press_event hack mentioned there, which would great since it means we could fix a bunch of other things as well.
Comment 3 Michael Gratton 2019-02-13 14:34:01 UTC
Fixed by https://gitlab.gnome.org/GNOME/geary/merge_requests/106