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 745774 - 'Hold to right click' does not work on all apps when using a touchscreen
'Hold to right click' does not work on all apps when using a touchscreen
Status: RESOLVED NOTGNOME
Product: gnome-shell
Classification: Core
Component: general
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 756771 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-07 07:53 UTC by Acsinte Florin
Modified: 2015-10-18 08:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Acsinte Florin 2015-03-07 07:53:35 UTC
When using a touchscreen on applications not using the new header bar (for example Firefox), you cannot right click by holding your finger in one spot.

Tested on Fedora 22
Comment 1 Florian Müllner 2015-03-07 09:05:01 UTC
What applications like Firefox do or don't do on some event is up to the application, gnome-shell is not involved in any way there.
Comment 2 Acsinte Florin 2015-03-07 09:56:34 UTC
Right click with the mouse works fine, it's 'right clicking' with your finger that does not work. I don't think that applications like firefox should know/care if I am using a mouse or a touchscreen in this situation.
Comment 3 Florian Müllner 2015-03-07 10:00:10 UTC
(In reply to Acsinte Florin from comment #2)
> Right click with the mouse works fine, it's 'right clicking' with your
> finger that does not work.

There is not such thing as 'right clicking with your finger' - there is a touch gesture (long press) that is commonly used by applications to trigger the same action as a pointer right-click, but event processing in applications is really up to applications. Sorry, but that is just how it works.
Comment 4 Acsinte Florin 2015-03-07 10:17:28 UTC
While I understand and appreciate that gnome offers the ability to set the action for each gesture, long press should really be treated as 'right click' by default (with the ability to change this). 

Old applications are not going to be rewritten for new stuff, so sane defaults would help a lot. At the moment, Gnome is the best DE for touch screens. While everything 'gnome' works fine, 3rd party apps make it unusable. 

I am sorry, but I am just a x86 tablet owner frustrated that I cannot use Linux+Gnome on it, even though it's so close.
Comment 5 Florian Müllner 2015-03-10 15:30:08 UTC
I understand your frustration, but this is really not the window managers job. Yes, long-press should trigger the context menu as right-click does for pointer devices. But there is no way for us to tell that some item has a context menu that would be shown on right-click - that's something only the application (and to some extent the toolkit it uses) can know.
Comment 6 Jasper St. Pierre (not reading bugmail) 2015-03-10 15:36:18 UTC
If you're curious, if you're asking us to simply send a right-click to the app after we hold for a second or two, we can't accurately send a fake right-click to the client.
Comment 7 Acsinte Florin 2015-03-10 20:03:44 UTC
So this means that each application will have to treat all gestures? So swipe up/down to scroll, pinch to zoom, etc will not work, unless the application specifically states this? That's a bummer :(.

Anyway, thank you very much for taking the time to explain all of this to me.
Comment 8 Florian Müllner 2015-03-10 20:12:18 UTC
(In reply to Acsinte Florin from comment #7)
> So this means that each application will have to treat all gestures? So
> swipe up/down to scroll, pinch to zoom, etc will not work, unless the
> application specifically states this? That's a bummer :(.

Well, no - that's why applications usually use a toolkit instead of doing all the lifting themselves. There's just no magic make-everything-work-automatically switch somewhere ...
Comment 9 Florian Müllner 2015-10-18 08:42:33 UTC
*** Bug 756771 has been marked as a duplicate of this bug. ***