The test fails due to receiving unexpected focus events while pressing accesskey shortcuts.

Here is the test page that shows the behavior.

After triggering the accesskey shortcut, for example, control + option + a on Mac, we got two focus events on Fission OOP iframe (the latter one seems fired asynchronously). Like,

onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onclick: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415

Where there is only one focus event on non-Fission

onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onclick: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415

I tried https://phabricator.services.mozilla.com/D87859, but it doesn't help.

The additional focus event is from ContentChild::RecvBlurToChild,
Edited: The additional focus event is from BrowserChild::RecvActivate,

#0 0x00007f577cfb884b in nsFocusManager::FireFocusOrBlurEvent(mozilla::EventMessage, mozilla::PresShell*, nsISupports*, bool, bool, mozilla::dom::EventTarget*) (this=0x7f578db654c0, aEventMessage=mozilla::eFocus, aPresShell=0x7f5771a66000, aTarget=0x7f577386d820, aWindowRaised=false, aIsRefocus=false, aRelatedTarget=0x0) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:2667
#1 0x00007f577cfb8255 in nsFocusManager::SendFocusOrBlurEvent(mozilla::EventMessage, mozilla::PresShell*, mozilla::dom::Document*, nsISupports*, unsigned int, bool, bool, mozilla::dom::EventTarget*) (this=0x7f578db654c0, aEventMessage=mozilla::eFocus, aPresShell=0x7f5771a66000, aDocument=<optimized out>, aTarget=<optimized out>, aFocusMethod=<optimized out>, aWindowRaised=<optimized out>, aIsRefocus=false, aRelatedTarget=0x0) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:2658
#2 0x00007f577cfb5396 in nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) (this=0x7f578db654c0, aWindow=
0x7f578db95d60, aElement=0x7f576db06030, aFlags=<optimized out>, aIsNewDocument=<optimized out>, aFocusChanged=false, aWindowRaised=<optimized out>, aAdjustWidget=<optimized out>, aFocusInOtherContentProcess=<optimized out>, aContentLostFocus=0x0) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:2418
#3 0x00007f577cfb64dd in nsFocusManager::WindowRaised(mozIDOMWindowProxy*) (this=0x7f578db654c0, aWindow=<optimized out>) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:764
#4 0x00007f577fde0f46 in nsWebBrowser::FocusActivate() (this=<optimized out>) at /home/edgar/Workspace/mercurial/mozilla-central/toolkit/components/browser/nsWebBrowser.cpp:1208
#5 0x00007f577e7e2d9a in mozilla::dom::BrowserChild::RecvActivate() (this=<optimized out>) at /home/edgar/Workspace/mercurial/mozilla-central/dom/ipc/BrowserChild.cpp:1384

And similar to bug 1653160, we will see an additional pair of blur and focus event, (but the patch of bug 1653160 doesn't help).

onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onclick: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onblur: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415
onfocus: target: https://bugzilla.mozilla.org/show_bug.cgi?id=1661415

The blur event is from ContentChild::RecvBlurToChild,

#1 0x00007f577cfb8255 in nsFocusManager::SendFocusOrBlurEvent(mozilla::EventMessage, mozilla::PresShell*, mozilla::dom::Document*, nsISupports*, unsigned int, bool, bool, mozilla::dom::EventTarget*) (this=0x7f578db654c0, aEventMessage=mozilla::eBlur, aPresShell=0x7f5771a66000, aDocument=<optimized out>, aTarget=<optimized out>, aFocusMethod=<optimized out>, aWindowRaised=<optimized out>, aIsRefocus=false, aRelatedTarget=0x0) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:2658
#2 0x00007f577cfba272 in nsFocusManager::BlurImpl(mozilla::dom::BrowsingContext*, mozilla::dom::BrowsingContext*, bool, bool, nsIContent*) (this=0x7f578db654c0, aBrowsingContextToClear=<optimized out>, aAncestorBrowsingContextToFocus=0x7f577386dc00, aIsLeavingDocument=true, aAdjustWidget=<optimized out>, aContentToFocus=0x0) at /home/edgar/Workspace/mercurial/mozilla-central/dom/base/nsFocusManager.cpp:2226
#3 0x00007f577e7ccdcd in mozilla::dom::ContentChild::RecvBlurToChild(mozilla::dom::MaybeDiscarded<mozilla::dom::BrowsingContext> const&, mozilla::dom::MaybeDiscarded<mozilla::dom::BrowsingContext> const&, mozilla::dom::MaybeDiscarded<mozilla::dom::BrowsingContext> const&, bool, bool) (this=<optimized out>, aFocusedBrowsingContext=..., aBrowsingContextToClear=..., aAncestorBrowsingContextToFocus=..., aIsLeavingDocument=true, aAdjustWidget=true) at /home/edgar/Workspace/mercurial/mozilla-central/dom/ipc/ContentChild.cpp:3925

Hey Henri, is this something known issue? Thanks.

Some details for the additional blur event,

-- OOP iframe process --
While user active the accesskey shortcut, EventStateManager will call nsGenericHTMLElement::PerformAccesskey and then call nsFocusManager::SetFocus in nsGenericHTMLElement::PerformAccesskey which will dispatch focus synchronously. Then send RequestFocus IPC message to parent process

-- Parent process --
forward request to top-level page.

-- Toplevel page process --
Try to focus iframe element again with FLAG_NOSCROLL and call nsFocusManager::Blur with aBrowsingContextToClear=<nullptr> and aAncestorBrowsingContextToFocus=<toplevel>, then send Blur IPC message to parent process.

-- Parent process --
Send Blur IPC message to OOP iframe process.

-- OOP iframe process --
Call nsFocusManager::BlurFromOtherProcess, then dispatch a blur event.

And the subsequent focus event is from,

-- Toplevel page process --
After

Try to focus iframe element again with FLAG_NOSCROLL and call nsFocusManager::Blur with aBrowsingContextToClear=<nullptr> and aAncestorBrowsingContextToFocus=<toplevel>

call nsFocusManager::Focus and then activate the remote browser which will send activate IPC message.

-- Parent process --
Forward activate request to OOP iframe process.

-- OOP iframe process --
Call nsWebBrowser::FocusActivate, then dispatch a focus event.

Hi Chris, does M6c here mean, it should no longer block bug 1653457 (marked M6b) ?

(In reply to Jens Stutte [:jstutte] (REO for FF 81) from comment #8)

Hi Chris, does M6c here mean, it should no longer block bug 1653457 (marked M6b) ?

Or maybe move bug 1653457 to M6c?

(In reply to Edgar Chen [:edgar] from comment #9)

(In reply to Jens Stutte [:jstutte] (REO for FF 81) from comment #8)

Hi Chris, does M6c here mean, it should no longer block bug 1653457 (marked M6b) ?

Or maybe move bug 1653457 to M6c?

I will move bug 1653457 from M6b to M6c.

M6c means fixing the bug soon (in September, ideally) is important, but it doesn't block our Fission Nightly experiment (October 6).

(In reply to Edgar Chen [:edgar] (PTO 09/14) from comment #5)

Hey Henri, is this something known issue? Thanks.

Additional behaviors on key presses in Fission are not known to me. However, as seen in bug 1660805 comment 2, the when an OOP iframe wants focus, it needs to bounce an IPC message to the framer via the parent, and then another IPC message needs to come back, also via the parent. This makes the focus event fire later relative to the event that triggered the focusing than in the non-Fission case.

Thanks. I also found a similar behavior on tab navigation while working on bug 582459. Will get back to this after other M6b bugs.