With this approach, when the last window of an app is closed, the engine
sends a message to the framework to check if it is allowed to exit. If
it may, the windows lifecycle manager synthesizes a second `WM_CLOSE`
message that it will ignore, and so the next registered top level window
proc delegate, if any, will be able to process the message. If none do
so, the message will be handled by the default window proc, so the app
will be able to close.
I was not able to get a full system tray example application running to
test this, but I could get an application that stays open when its
window is closed and can be seen as a system tray icon as long as it is
running, albeit the icon was non-functional. As this repro app still
exhibited this behavior when using this engine build, I am reasonably
confident in concluding that applications that want to be able to run
headless when their windows close will function properly.
Addresses https://github.com/flutter/flutter/issues/123654.
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [x] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
---------
Co-authored-by: Loïc Sharma <737941+loic-sharma@users.noreply.github.com>
Reverts flutter/engine#40862
Google Testing is failing on
```
The compiler crashed: root:🎯_engine::SkObjectFinalizationRegistry::@methods::|staticInteropFactoryStub is already bound to Reference to dart:_engine::SkObjectFinalizationRegistry::@methods::|staticInteropFactoryStub, trying to bind to Reference to SkObjectFinalizationRegistry.|staticInteropFactoryStub with node SkObjectFinalizationRegistry.|staticInteropFactoryStub (Procedure:1207727)
```
TargetPlatformNeedsSL was true for all target platforms.
I believe we reworked this after we started embedding metadata in IPLR
files perhaps? In any case, this seemed unused and was making the code
harder to read. Just a cleanup that I didn't want to include in the
compiler rework for SPIRV.
This PR makes view ID signed from unsigned int64.
Initially, I made view IDs unsigned because they were opaque anyway. As
I'm working deeper into multiview, I found some issues that made me
think signed is better:
* Unsigned integers are worse
* Sometimes you want negative values to represent special values.
* Unsigned integers are dangerous (if compared with signed ones by
mistake.)
* Unsigned integers are not needed
* We're very unlikely to reach that big anyway.
* Almost all other languages support only signed integers.
* Also JavaScript only supports up to 51 bits of integer.
Therefore I think it's better to change them to signed int64, especially
before these APIs are widely used by developers.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I added new tests to check the change I am making or feature I am
adding, or Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
