1436418 - Firefox emitting false window:activate/deactivate events

Status: RESOLVED WORKSFORME

(Core :: Widget: Gtk, defect)

Description

[Alex ARNAUD]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20180123215146

Steps to reproduce:

Hello all,

Environments where I could reproduce the issue :
- Debian Sid with Firefox Nightly (e10s enabled)
- Debian 8 Jessie with Firefox ESR (e10s disabled)

Steps to reproduce:
1) Open Firefox
2) Open Accerciser and monitor "window" events
3) Press alt+tab to switch to Firefox
4) Open http://www.debian.org (or another web site)
4) Press tab multiple times into the web site content
5) Press alt+tab to leave the Firefox window


Actual results:

Result from accerciser:
window:activate(0, 0, Debian -- The Universal Operating System - Firefox Nightly)
	source: [frame | Debian -- The Universal Operating System - Firefox Nightly]
	application: [application | Firefox]
window:deactivate(0, 0, Debian -- The Universal Operating System - Firefox Nightly)
	source: [frame | Debian -- The Universal Operating System - Firefox Nightly]
	application: [application | Firefox]
window:activate(0, 0, Debian -- The Universal Operating System - Firefox Nightly)
	source: [frame | Debian -- The Universal Operating System - Firefox Nightly]
	application: [application | Firefox]
window:deactivate(0, 0, Debian -- The Universal Operating System - Firefox Nightly)
	source: [frame | Debian -- The Universal Operating System - Firefox Nightly]
	application: [application | Firefox]


Expected results:

Expected result: Firefox should only emits one window:activate and one window:desactivate event

The user impact is that Orca believes it is inside Firefox when it is another application. For example if your are on a terminal or on a text editor like Gedit or Pluma pressing down arrow will be catch by Orca and you will continu to move inside the web content. 

Best regards.

Comment 1

[Joanmarie Diggs]

I cannot reproduce this bug using Orca master and Firefox nightly. Is it limited to Firefox 52?

Comment 2

[Alex ARNAUD]

(In reply to Joanmarie Diggs from comment #1)
> I cannot reproduce this bug using Orca master and Firefox nightly. Is it
> limited to Firefox 52?

No, not limited to 52. I really reproduce the issue on Firefox Nightly. Sometimes the bug doesn't occur but most of the time the steps I've followed make the bug reproducible. Could you try two or three times?

Best regards.

Comment 3

[Joanmarie Diggs]

I'll try, but I'm wondering if it's an issue in the Window manager or app gaining focus or something else.

Mind attaching a full debug.out captured when the problem has happened?

Comment 4

[Alex ARNAUD]

Attachment: orca-debug.log

This the Orca debug log when I reproduce the issue.

Comment 5

[Alex ARNAUD]

(In reply to Joanmarie Diggs from comment #3)
> I'll try, but I'm wondering if it's an issue in the Window manager or app
> gaining focus or something else.

I don't think it is an issue with the window manager because I've tested with Marco (Mate) and Compiz 0.9 and the issue only appear with Firefox.

> Mind attaching a full debug.out captured when the problem has happened?

The debug log is big because I've wanted to be sure the bug was logged.

Best regards.

Comment 6

[Joanmarie Diggs]

Alex: What I'm seeing is a ton of events from Accerciser. Can you reproduce the bug without using Accerciser?

What would be extremely helpful to me is a debug.out captured when you only have the following applications running:
1. Firefox (already displaying the debian page)
2. Pluma (which has two short lines of text in it)
3. A terminal (only if you need it to capture the debug.out)

Then do the following steps:

1. Tab at most twice in Firefox (twice so that I don't get a bunch of focus event spam in the output which is not relevant to the bug).
2. Alt + Tab until you land into Pluma
3. Press the arrow keys (a couple of times) to move in in the Pluma text

That's it.

If you capture a debug.out with just that information in it, it should be a lot easier for me to read -- and hopefully to help shine more light on the problem you're reporting here. Sorry and thanks!

Comment 7

[Alex ARNAUD]

Attachment: debug.log

Shot debug log when I reproduce the issue. Enable the caret navigation with F7 seems to have an impact on the window activate/deactivate events.

Best regards.

Comment 8

[Samuel Thibault]

Hello,

I could notice the issue with the accerciser window itself too: for instance on switching between mate-terminal and accerciser, when I leave the accerciser window to get to mate-terminal, I get

- deactivate accerciser,
- activate accerciser,
- activate mate-terminal,
- deactivate accersiser

so nothing related to firefox itself.

That was however with mate+compiz. When trying with just fvwm, I don't have any issue. I guess it might thus be related with how compiz' task switcher behaves.

Samuel

Comment 9

[Alex ARNAUD]

OK, I reproduce the same issue with Mate terminal only with Compiz switcher. I close this bug. sorry for the inconvenience.

Best regards.

Comment 10

[Samuel Thibault]

Hello,

We have been diving into this and submitted pull requests to gtk on

https://gitlab.gnome.org/GNOME/gtk/merge_requests/91 (gtk2)
https://gitlab.gnome.org/GNOME/gtk/merge_requests/76 (gtk3)

But it doesn't fix the firefox, because it's actually firefox itself which emits window:activate/deactivate rather than gtk (as can be seen in the case nsIAccessibleEvent::EVENT_WINDOW_ACTIVATE: block of accessible/atk/AccessibleWrap.cpp).

Avoiding the events in the keyboard shortcut case (it's not only alt-tab, but any kind of shortcut managed by the window manager through X11 grabbing) will need some help from gtk, to determine whether a focus-out is actually NotifyGrab or NotifyNormal, I'll a post a patch once gtk has the needed help.

Comment 11

[Samuel Thibault]

Attachment: windowactivate

This is what it would look like. gdk_x11_window_has_focus_window is not in gtk yet, possibly it'll have another name, and we'll probably want to detect it dynamically etc. thus this is not a patch for submission, just to show how it can look like.

Comment 12

[:Gijs (he/him)]

Yura, is this the best component for this bug? Feels like this should be tracked in Core.

Comment 13

[Yura Zenevich [:yzen] (please use "needinfo")]

(In reply to :Gijs (he/him) from comment #12)
> Yura, is this the best component for this bug? Feels like this should be
> tracked in Core.

Looks this way to me, just in case ni? Alex to make a call.

Comment 14

[alexander :surkov (:asurkov)]

(In reply to Samuel Thibault from comment #11)
> Created attachment 8963983 [details] [diff] [review]
> windowactivate
> 
> This is what it would look like. gdk_x11_window_has_focus_window is not in
> gtk yet, possibly it'll have another name, and we'll probably want to detect
> it dynamically etc. thus this is not a patch for submission, just to show
> how it can look like.

Samuel, what's left to turn this work into a patch ready for review?

Comment 15

[Samuel Thibault]

We are waiting for gtk to add the gdk_x11_window_has_focus_window interface or similar as requested on

https://gitlab.gnome.org/GNOME/gtk/merge_requests/91 (gtk2)
https://gitlab.gnome.org/GNOME/gtk/merge_requests/76 (gtk3)

Comment 16

[Samuel Thibault]

Upstream gtk eventually agreed to just avoid changing the focus on keyboard grabs, so that no change would be needed in firefox in the end.

Comment 17

[Alex ARNAUD]

(In reply to Samuel Thibault from comment #16)
> Upstream gtk eventually agreed to just avoid changing the focus on keyboard
> grabs, so that no change would be needed in firefox in the end.

What is the state of this bug Samuel? A user reported a side-effect about this issue on the Orca list today : https://mail.gnome.org/archives/orca-list/2018-June/msg00185.html

Best regards,
Alex.

Comment 18

[Samuel Thibault]

Mmm, I don't think she has the gtk patch, so it'd be another issue, which I can't seem to reproduce. I'll have a look at her debug log.

Concerning the gtk patches, it's commited in the 3.24 and 4 branches, so gtk 3.24.0 will have it for instance.

Comment 19

[Samuel Thibault]

The 3.23.0 release does have the change.

Comment 20

[Samuel Thibault]

I believe we can close this bug, with gtk 3.24 firefox doesn't emit the spurious window:deactivate/activate events any more.

Comment 21

[Marco Zehe (:MarcoZ)]

Closed as per comment #20.

Comment 22

[Alex ARNAUD]

(In reply to Samuel Thibault from comment #20)

I believe we can close this bug, with gtk 3.24 firefox doesn't emit the
spurious window:deactivate/activate events any more.

Just to be sure, With the recent revert of accessibility changes related to keyboard shortcuts, could we always consider this as fixed?

Best regards,
Alex.

Comment 23

[Samuel Thibault]

Well, it's not fixed any more indeed, but I don't think we want to fix it in firefox anyway, since it's a more general gtk issue. I'd thus say to mark this as invalid.