1502226 - Plugin test browser_private_clicktoplay.js has focus not following newly opened windows when run locally

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P3)

Description

[:Gijs (he/him)]

STR:

1. apply https://hg.mozilla.org/try/rev/38611142d6fc1658f91a018cdc3600d6a62a4980
2. on macOS (not sure about other platforms), run:

./mach mochitest browser/base/content/test/plugins/browser_private_clicktoplay.js

3. watch the test hang because the private window it creates never gains focus.


I... don't know why it doesn't work. Manually calling .focus() or .click() from the test or assigning to focusedWindow or activeWindow doesn't seem to help. Clicking anywhere in the window makes it gain focus properly and causes the test to continue.

Neil, any ideas what's wrong here?

Comment 1

[Neil Deakin]

The test doesn't seem to work for me at all with or without the patch.

At step2c, the plugin is focused (I assume), and the system never sends a window ordering notification.

Comment 2

[:Gijs (he/him)]

(In reply to Neil Deakin from comment #1)
> the system never sends a window ordering notification.

Any idea why that'd be or how we'd convince it to send one? :-)

Comment 3

[Neil Deakin]

The test passes (with and without the patch) if I return early from plugin initialization. For example, I added an early return in nsPluginHost::InstantiatePluginInstance.

If doing that 'fixes' your problem, I would suggest that this be some plugin related issue, or at least, that would be a better place to continue investigating.

Comment 4

[:Gijs (he/him)]

:handyman, any idea what's going wrong here? Why does the plugin being initialized break focus / window ordering behavior in this test?

Comment 5

[David Parks [:handyman]]

I'll take a look but my mac is crazy out of date (and I'm not seeing the failure on Windows) so it'll take some time.

Comment 6

[:Gijs (he/him)]

(In reply to David Parks (dparks) [:handyman] from comment #5)
> I'm not seeing the failure on Windows

Not even with the steps from comment #0 ? I'm surprised because it shows up on infra:

https://treeherder.mozilla.org/#/jobs?repo=try&searchStr=win&selectedJob=207104041&revision=10ac608f414670045bbe7380e26a770c902b718b

though I guess it's possible that's due to the test modifications in that particular trypush - https://hg.mozilla.org/try/rev/51fcba180aa4a9f2ea69939d17030f29a1cef255#l1.1 - which are about the same thing: focus/activate events should follow around the topmost window, ie when the private browsing window closes, it should have been the topmost window so then the next-topmost window should be getting focus + activate events.

Comment 7

[David Parks [:handyman]]

Not only did I not see it on Windows but, so far, I can't reproduce it on mac (10.14) either.  With or without the patch.  All tests are passing for me with no interruption.

I just noticed that the patch in comment 0 is actually part of a series.  Should I be grabbing the entire series or just the test changes?

https://hg.mozilla.org/try/pushloghtml?changeset=38611142d6fc

Comment 8

[David Parks [:handyman]]

Doh.  Applied the entire patch series and I can see it on mac now.

Comment 9

[David Parks [:handyman]]

I'm currently swamped with WebGL remoting work but I'll put in some time to see what is causing this in the next few days.

Comment 10

[:Gijs (he/him)]

At least for the moment, I've stopped seeing this on try, though like Neil I can still reproduce locally (also on vanilla m-c, without any patches) with my local mac artifact build, which is... curious.

Comment 11

[David Parks [:handyman]]

It tlooks like you are just over-stressing the test framework.  The promiseFocus call just doesn't work properly when run async with the rest:

https://hg.mozilla.org/try/rev/c7601ef17547814288adf159c2c074bf7e8e4e2d
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3e33a9918b77ce44bf10636ec7614f4a95afe7bd

Comment 12

[:Gijs (he/him)]

(In reply to David Parks (dparks) [:handyman] from comment #11)
> It tlooks like you are just over-stressing the test framework.  The
> promiseFocus call just doesn't work properly when run async with the rest:
> 
> https://hg.mozilla.org/try/rev/c7601ef17547814288adf159c2c074bf7e8e4e2d
> https://treeherder.mozilla.org/#/
> jobs?repo=try&revision=3e33a9918b77ce44bf10636ec7614f4a95afe7bd

Hm, yeah, unfortunately that doesn't seem to help for the hanging I'm seeing locally... Basically, the test hangs at https://searchfox.org/mozilla-central/rev/eac6295c397133b7346822ad31867197e30d7e94/browser/base/content/test/plugins/browser_private_clicktoplay.js#25 when called from https://searchfox.org/mozilla-central/rev/eac6295c397133b7346822ad31867197e30d7e94/browser/base/content/test/plugins/browser_private_clicktoplay.js#107 .

I mean, because this is no longer blocking me landing stuff, I'm happy to close this as incomplete from that perspective, but on the other hand I'm intrigued that we can end up opening foreground windows that then don't take focus, even when we try to force them to have focus.

Comment 13

[Jim Mathies [:jimm]]

lets just disable the test.

Comment 14

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.