fix: notify focus change right away rather not on next tick #14453

nitsakh · 2018-09-04T17:40:27Z

Description of Change

This issue fixes #13913. There was a problem with two windows fighting for focus because the focus notification was being sent on next tick.
This PR changes that, so that the focus notification is sent right away.
Also fixes #13549.

Checklist

PR description included and stakeholders cc'd
npm test passes
tests are changed or added
relevant documentation is changed or added
PR title follows semantic commit guidelines

Release Notes

Notes: Fixed windows multiple windows focus bug.

ckerr

This is almost verbatim the reverse of #5131 and so I think it would reintroduce that bug?

nitsakh · 2018-09-04T18:08:33Z

:-( Will check that. Thanks for pointing me to that. 🙇

jkleinsc · 2018-09-04T18:34:23Z

I just verified that this also fixes #13549.

jkleinsc · 2018-09-04T18:48:05Z

I just tested this branch against the repro listed here #3893 (fixed by #5131). Unfortunately this fix reintroduces the original issue.

zcbenz

The focus event is meant to be emitted after the window is focused. So behaviors on all platforms are matched, and issues like #3893 can be avoided.

The OnWidgetActivationChanged method is called when the window is in the middle of changing focus, so emitting focus here breaks the behavior, and can crash Electron if user decides to close the window now.

My solution was to delay the event one tick later, which fixed part of the problem but it was not the right solution.

We probably have to find out when the views library has just finished the focus changing, and emitting the event there.

MarshallOfSound · 2018-09-05T01:45:18Z

We probably have to find out when the views library has just finished the focus changing, and emitting the event there.

I'm going to work on that today, then we can land this fix in combination with that change

MarshallOfSound · 2018-09-05T04:58:15Z

OK so did a bunch of work on this today, there are other events we can use to get focus but they introduce other race conditions with the window creation and the first observer being added. The easiest solution to get this fixed in 3.0 is to reintroduce the next tick delay but later in the call stack so it only affects the JS emit calls

zcbenz · 2018-09-05T08:29:28Z

atom/browser/api/atom_api_top_level_window.cc

@@ -71,6 +71,21 @@ v8::Local<v8::Value> ToBuffer(v8::Isolate* isolate, void* val, int size) {

 }  // namespace

+namespace {


There is already an anonymous namespace right above, not need to create a new one.

Feels bad... Didn't even realize 😆

ckerr · 2018-09-05T16:34:10Z

atom/browser/api/atom_api_top_level_window.cc

+  content::BrowserThread::PostTask(
+      content::BrowserThread::UI, FROM_HERE,
+      base::Bind(&EmitNextTickTask,
+                 emitter, name));


Looks like this is nonrepeating; should this be bind::BindOnce()?

Could avoid bit of unnecessary heap action by using base::StringPiece rather than const std::string& here and in EmitNextTickTask

It's not clear to me how the std::string objects created on the stack in OnWindowBlur and OnWindowFocus stay alive through the deferred action to EmitNextTickStack? The previous bullet point will fix this, but asking separately for my own edification on base::Bind's internals

jkleinsc · 2018-09-05T19:42:17Z

FYI... it looks like the Windows CI failures are a DCHECK failure:

# Fatal error in .\../../v8/src/v8threads.cc, line 30
# Debug check failed: (isolate) != nullptr.

jkleinsc

Windows CI is failing with a DCHECK failure:

#
# Fatal error in .\../../v8/src/v8threads.cc, line 30
# Debug check failed: (isolate) != nullptr.
#

jkleinsc · 2018-09-05T19:52:46Z

https://gist.github.com/7eb20129c41f6fc95999404d507fe438 reproduces the DCHECK failure above

jkleinsc · 2018-09-05T20:01:00Z

Looks like Mac CI is failing with same DCHECK error:
https://circleci.com/gh/electron/electron/53418?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

codebytere · 2018-09-05T22:33:52Z

atom/browser/api/atom_api_top_level_window.cc

+void EmitNextTick(TopLevelWindow* emitter, const std::string& name) {
+  content::BrowserThread::PostTask(
+      content::BrowserThread::UI, FROM_HERE,
+      base::Bind(&EmitNextTickTask,


@nitsakh: #12639 (base::Bind is being deprecated in favor of base::BindOnce and base::BindRepeating)

ckerr

Assuming CI is happy, I'm 👍 on this approach.

I'd still love to hear if the std::string& being bound was somehow staying in scope in 92de895 due to magic in base::BindOnce...?

codebytere · 2018-09-05T23:27:19Z

For windows:

Tests failed with exit code -1073741819

🤔

jkleinsc · 2018-09-05T23:28:35Z

@codebytere that is the dcheck failure I mentioned above.

codebytere · 2018-09-05T23:29:18Z

interesting, this failure didn't happen with my changes running the test suite locally (but on MacOS)

This is so that the deferred Emit() calls will be canceled if the TopLevelWindow is destroyed.

ckerr · 2018-09-06T23:56:00Z

The new method TopLevelWindow::EmitEvent() exists only because I couldn't make this work instead:

base::BindOnce(&TopLevelWindow::Emit, weak_factory_.GetWeakPtr(), eventName));

If some C++ guru could explain how to make that work, that would make my day. 🤞

MarshallOfSound · 2018-09-06T23:56:52Z

atom/browser/api/atom_api_top_level_window.cc

+  Emit(eventName);
+}
+
+void TopLevelWindow::EmitEventSoon(base::StringPiece eventName) {


Question: Can we avoid the EmitEvent method and make this more generic by putting EmitSoon onto the EventEmitter base class?

Right now the function is slightly brittle because it requires exactly one argument. It would be preferable if that could be resolved before this is opened up for a wider scope in the code.

The issue I mentioned above is the cause for this: EmitEvent() exists solely to make the compiler happy because I didn't see how to use the existing EventEmitter::Emit().

To be more specific, this was the compiler error:

base::BindOnce(&TopLevelWindow::Emit, weak_factory_.GetWeakPtr(), "blur")); ^~~~~~~~~~~~~~ ../../base/bind.h:179:1: note: candidate template ignored: couldn't infer template argument 'Functor'

base::BindOnce(&TopLevelWindow::Emit<base::StringPiece>, weak_factory_.GetWeakPtr(), "blur"));

My understanding of that error is you need to do ☝️

You can just invoke the default template variation of Emit for this scenario

void TopLevelWindow::EmitEventSoon(base::StringPiece eventName) { content::BrowserThread::PostTask( content::BrowserThread::UI, FROM_HERE, base::BindOnce(base::IgnoreResult(&TopLevelWindow::Emit<>), weak_factory_.GetWeakPtr(), eventName)); }

Or

template <typename... Args> void TopLevelWindow::EmitEventSoon(base::StringPiece eventName) { content::BrowserThread::PostTask( content::BrowserThread::UI, FROM_HERE, base::BindOnce(base::IgnoreResult(&TopLevelWindow::Emit<Args...>), weak_factory_.GetWeakPtr(), eventName)); }

For a generic version in EventEmitter class you would essentially do the above by capturing the variadic args and passing them on. But I would suggest avoid adding a generic version for this delayed event emit, we are just working around a problem due to a some design issues with the framework, it shouldn't set out as a code suggestion for similar problems that may arise in the future rather we should rethink the class design.

Aha! I didn't know about base::IgnoreResult() and was unsure how to get rid of the bool return value from Emit, since weak ptrs can only be bound to functions returning void. Thanks for the pointer 👍

…-win-focus

…into fix-win-focus" This reverts commit 9057680, reversing changes made to 9c13e47.

We apologise again for the fault in the subtitles. Those responsible for sacking the people who have just been sacked have been sacked.

release-clerk · 2018-09-07T18:22:01Z

Release Notes Persisted

Fixed windows multiple windows focus bug.

trop · 2018-09-07T18:22:21Z

An error occurred while attempting to backport this PR to "3-0-x",
you will need to perform this backport manually

* fix: Notify focus change right away, not on next tick * fix: emit the JS blur/focus events on next tick to avoid race condition * address feedback from review * fix: bind deferred Emit() calls to a WeakPtr This is so that the deferred Emit() calls will be canceled if the TopLevelWindow is destroyed. * chore: remove wip/test code cruft * fix: make linter happy * Enable disabled tests * refactor: cleaner impl of EmitEventSoon() * Revert "Merge branch 'fix-win-focus' of github.com:electron/electron into fix-win-focus" This reverts commit 9057680, reversing changes made to 9c13e47. * Restore 704722c, which was removed in error. We apologise again for the fault in the subtitles. Those responsible for sacking the people who have just been sacked have been sacked.

nitsakh requested review from a team, zcbenz and jkleinsc September 4, 2018 17:40

ckerr reviewed Sep 4, 2018

View reviewed changes

zcbenz requested changes Sep 5, 2018

View reviewed changes

MarshallOfSound force-pushed the fix-win-focus branch 2 times, most recently from 8ce94fb to b91bf74 Compare September 5, 2018 05:19

nitsakh requested review from a team September 5, 2018 05:19

MarshallOfSound changed the base branch from 3-0-x to master September 5, 2018 05:19

zcbenz approved these changes Sep 5, 2018

View reviewed changes

fix: Notify focus change right away, not on next tick

e371bc5

jkleinsc force-pushed the fix-win-focus branch from b91bf74 to 4416b2b Compare September 5, 2018 14:14

fix: emit the JS blur/focus events on next tick to avoid race condition

92de895

MarshallOfSound force-pushed the fix-win-focus branch from 4416b2b to 92de895 Compare September 5, 2018 16:16

MarshallOfSound added the target/3-0-x label Sep 5, 2018

codebytere approved these changes Sep 5, 2018

View reviewed changes

ckerr reviewed Sep 5, 2018

View reviewed changes

jkleinsc requested changes Sep 5, 2018

View reviewed changes

codebytere reviewed Sep 5, 2018

View reviewed changes

ckerr approved these changes Sep 5, 2018

View reviewed changes

ckerr mentioned this pull request Sep 6, 2018

[wip] Weakly bound deferred emissions #14485

Closed

ckerr added 4 commits September 6, 2018 18:47

fix: bind deferred Emit() calls to a WeakPtr

b970d5e

This is so that the deferred Emit() calls will be canceled if the TopLevelWindow is destroyed.

chore: remove wip/test code cruft

1d1f7cc

fix: make linter happy

75316ed

fix: resolve conflict

6033364

MarshallOfSound reviewed Sep 6, 2018

View reviewed changes

Enable disabled tests

704722c

jkleinsc approved these changes Sep 7, 2018

View reviewed changes

refactor: cleaner impl of EmitEventSoon()

9c13e47

MarshallOfSound changed the title ~~fix: Notify focus change right away, not on next tick~~ fix: notify focus change right away, not on next tick Sep 7, 2018

ckerr added 3 commits September 7, 2018 10:30

Merge branch 'fix-win-focus' of github.com:electron/electron into fix…

9057680

…-win-focus

Revert "Merge branch 'fix-win-focus' of github.com:electron/electron …

050d5f8

…into fix-win-focus" This reverts commit 9057680, reversing changes made to 9c13e47.

Restore 704722c, which was removed in error.

e9769ff

We apologise again for the fault in the subtitles. Those responsible for sacking the people who have just been sacked have been sacked.

ckerr changed the title ~~fix: notify focus change right away, not on next tick~~ fix: notify focus change right away rather not on next tick Sep 7, 2018

ckerr merged commit a2ab0d8 into master Sep 7, 2018

ckerr deleted the fix-win-focus branch September 7, 2018 18:22

jkleinsc mentioned this pull request Sep 7, 2018

fix: notify focus change right away rather not on next tick (3-0-x) #14494

Merged

4 tasks

bpasero mentioned this pull request Sep 9, 2018

3.0.x regression: Object has been destroyed upon quit with multiple windows open #14513

Closed

markleutloff mentioned this pull request Sep 13, 2018

Temporary OS freeze and flickering when opening BrowserWindows simultaneously. #13549

Closed

This was referenced Sep 19, 2018

Update electron in / from 2.0.9 to 3.0.0 JetBrains/ring-ui#417

Merged

Update electron in /packages/generator/app/templates from 2.0.10 to 3.0.0 JetBrains/ring-ui#418

Merged

ckerr mentioned this pull request Dec 18, 2018

Draft 4.0.0 Release Notes #16117

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix: notify focus change right away rather not on next tick #14453

fix: notify focus change right away rather not on next tick #14453

nitsakh commented Sep 4, 2018 •

edited by jkleinsc

Loading

ckerr left a comment

nitsakh commented Sep 4, 2018

jkleinsc commented Sep 4, 2018

jkleinsc commented Sep 4, 2018

zcbenz left a comment

MarshallOfSound commented Sep 5, 2018

MarshallOfSound commented Sep 5, 2018

zcbenz Sep 5, 2018

MarshallOfSound Sep 5, 2018

ckerr Sep 5, 2018 •

edited

Loading

jkleinsc commented Sep 5, 2018

jkleinsc left a comment

jkleinsc commented Sep 5, 2018

jkleinsc commented Sep 5, 2018

codebytere Sep 5, 2018 •

edited

Loading

ckerr left a comment

codebytere commented Sep 5, 2018 •

edited

Loading

jkleinsc commented Sep 5, 2018

codebytere commented Sep 5, 2018 •

edited

Loading

ckerr commented Sep 6, 2018

MarshallOfSound Sep 6, 2018

ckerr Sep 7, 2018

MarshallOfSound Sep 7, 2018

deepak1556 Sep 7, 2018

ckerr Sep 7, 2018

release-clerk bot commented Sep 7, 2018

trop bot commented Sep 7, 2018

		@@ -71,6 +71,21 @@ v8::Local<v8::Value> ToBuffer(v8::Isolate* isolate, void* val, int size) {

		} // namespace

		namespace {

fix: notify focus change right away rather not on next tick #14453

fix: notify focus change right away rather not on next tick #14453

Conversation

nitsakh commented Sep 4, 2018 • edited by jkleinsc Loading

Description of Change

Checklist

Release Notes

ckerr left a comment

Choose a reason for hiding this comment

nitsakh commented Sep 4, 2018

jkleinsc commented Sep 4, 2018

jkleinsc commented Sep 4, 2018

zcbenz left a comment

Choose a reason for hiding this comment

MarshallOfSound commented Sep 5, 2018

MarshallOfSound commented Sep 5, 2018

zcbenz Sep 5, 2018

Choose a reason for hiding this comment

MarshallOfSound Sep 5, 2018

Choose a reason for hiding this comment

ckerr Sep 5, 2018 • edited Loading

Choose a reason for hiding this comment

jkleinsc commented Sep 5, 2018

jkleinsc left a comment

Choose a reason for hiding this comment

jkleinsc commented Sep 5, 2018

jkleinsc commented Sep 5, 2018

codebytere Sep 5, 2018 • edited Loading

Choose a reason for hiding this comment

ckerr left a comment

Choose a reason for hiding this comment

codebytere commented Sep 5, 2018 • edited Loading

jkleinsc commented Sep 5, 2018

codebytere commented Sep 5, 2018 • edited Loading

ckerr commented Sep 6, 2018

MarshallOfSound Sep 6, 2018

Choose a reason for hiding this comment

ckerr Sep 7, 2018

Choose a reason for hiding this comment

MarshallOfSound Sep 7, 2018

Choose a reason for hiding this comment

deepak1556 Sep 7, 2018

Choose a reason for hiding this comment

ckerr Sep 7, 2018

Choose a reason for hiding this comment

release-clerk bot commented Sep 7, 2018

trop bot commented Sep 7, 2018

nitsakh commented Sep 4, 2018 •

edited by jkleinsc

Loading

ckerr Sep 5, 2018 •

edited

Loading

codebytere Sep 5, 2018 •

edited

Loading

codebytere commented Sep 5, 2018 •

edited

Loading

codebytere commented Sep 5, 2018 •

edited

Loading