## What's new?
- Implemented `_TestTooltipWindowController` in the `TestWindowingOwner`
- Fixed how child windows of the main window are rendered in the
application
- Introduced `WindowManager.getChildrenOf` to simplify filtering and
rendering of the children of a parent window
- Added a test for the tooltip window
- Added a test for modal dialogs of the main window
## 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], including [Features
we expect every widget to implement].
- [X] I signed the [CLA].
- [X] I listed at least one issue that this PR fixes in the description
above.
- [X] I updated/added relevant documentation (doc comments with `///`).
- [X] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [X] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [X] All existing and new tests are passing.
## Description
This PR replaces `wcslen` with `wcsnlen` in the Windows runner template
and all example/dev/integration test files to address CWE-126 (Buffer
Over-read) flagged by static analysis tools (Semgrep/GitLab SAST).
## Changes
The `Utf8FromUtf16` function now uses `wcsnlen` with the
`UNICODE_STRING_MAX_CHARS` constant (32767) as the maximum length,
providing defensive programming against potential buffer over-reads.
**Key improvements:**
1. Calculate `input_length` **first** using `wcsnlen(utf16_string,
UNICODE_STRING_MAX_CHARS)`
2. Use that bounded length for **both** `WideCharToMultiByte` calls
(eliminates the `-1` unbounded read)
3. Remove the `-1` adjustment since explicit length excludes null
terminator
4. Use `static_cast` instead of C-style casts per Google C++ Style Guide
## Test Coverage
Added comprehensive edge case tests for `Utf8FromUtf16` in
`windows_startup_test`:
- **nullptr input**: Verifies function returns empty string
- **Empty string input**: Verifies function returns empty string
- **Invalid UTF-16 (unpaired surrogate)**: Verifies function handles
malformed input gracefully
These tests address reviewer feedback from @loic-sharma requesting
coverage for corner cases.
## Files Updated
**Template (source of truth):**
- `packages/flutter_tools/templates/app/windows.tmpl/runner/utils.cpp`
**Integration tests (4 files):**
- `dev/integration_tests/flutter_gallery/windows/runner/utils.cpp`
- `dev/integration_tests/ui/windows/runner/utils.cpp`
- `dev/integration_tests/windowing_test/windows/runner/utils.cpp`
- `dev/integration_tests/windows_startup_test/windows/runner/utils.cpp`
**Examples and dev apps (10 files):**
- `examples/hello_world/windows/runner/utils.cpp`
- `examples/layers/windows/runner/utils.cpp`
- `examples/platform_view/windows/runner/utils.cpp`
- `examples/flutter_view/windows/runner/utils.cpp`
- `examples/platform_channel/windows/runner/utils.cpp`
- `examples/api/windows/runner/utils.cpp`
- `examples/multiple_windows/windows/runner/utils.cpp`
- `dev/manual_tests/windows/runner/utils.cpp`
- `dev/benchmarks/complex_layout/windows/runner/utils.cpp`
- `dev/a11y_assessments/windows/runner/utils.cpp`
**Test files (4 files):**
-
`dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp`
- `dev/integration_tests/windows_startup_test/lib/main.dart`
- `dev/integration_tests/windows_startup_test/lib/windows.dart`
-
`dev/integration_tests/windows_startup_test/test_driver/main_test.dart`
## Rationale
While the Windows API guarantees null-termination for strings returned
by `CommandLineToArgvW`, using `wcsnlen` with an explicit bound is a
defensive programming best practice that:
- Satisfies static analysis tools
- Provides an extra safety layer
- Follows the principle of defense in depth
The limit of 32767 (`UNICODE_STRING_MAX_CHARS`) is the maximum length of
a `UNICODE_STRING` structure and is far beyond any realistic
command-line argument length.
## Related Issues
Fixes https://github.com/flutter/flutter/issues/180418
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and labeled this PR with
`severe: API break` if it contains a breaking change.
- [x] All existing and new tests are passing.
[Contributor Guide]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[breaking change policy]:
https://github.com/flutter/flutter/blob/master/docs/contributing/Tree-hygiene.md#breaking-changes
## What's new?
- Implemented tooltip windows for the Win32 platform
- Implemented size-to-content on Win32
- Wired up the window metrics event with constraints
- Updated the example application to demonstrate tooltips
- Wrote a bunch of unit tests
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
---------
Co-authored-by: Matej Knopp <matej.knopp@gmail.com>
## What's new?
- Add `PopupWindowController`, `PopupWindowControllerDelegate`, and
`PopupWindow`
- Implement reference logic for popup windows in the test bindings
- Add tests for the popup windows API
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
This pull request makes it so that multi window applications can be
tested via `testWidgets`. This PR implements the following:
- A `_TestWindowingOwner` that is used by the
`TestWidgetsFlutterBinding`
- A `_TestRegularWindowController` implementation
- A `_TestDialogWindowController` implementation
- A `_TestFlutterView` and `_TestDisplay` for use by the controllers
- Proper `isActivated` status across controllers
- Proper minimization, maximization, and fullscreen status
- Proper sizing (based on constraints)
- Using the new testing abilities in the multiple windows example app
I have purposefully not implemented tooltip windows yet, as they are
still awaiting an implementation in Win32 to be useful.
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
- Added tooltips to the windowing API, but they have no implementation
for the time being
- Added the `WindowPostiioner` logic to the windowing API
- Wrote a lot of tests 🧪
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
- Users can now create a dialog whose parent is a dialog in the example
app
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
- Implemented `DialogWindowControllerWin32` for win32 dialogs 🚀
- Refactored and updated the Win32 embedder to support dialogs
- Updated the `multiple_windows` example to demonstrate both modal and
modeless dialogs
- Added integration tests for the dialog windows
- Added tests for dialogs in the embedder
## How to test?
1. Run the `multiple_windows` example application with a local engine
built from this pull request
2. Click the `Modeless Dialog` creation button on the main window
3. Open a regular window and click the `Modal Dialog` creation button
4. Note the behavior of modal and modeless dialogs
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
- 🍏 Added the concept of dialogs to the windowing API. New
symbols:
- `DialogWindowControllerDelegate`
- `DialogWindowController`
- `WindowingOwner.createDialogWindowController`
- `DialogWindow`
- `WindowControllerCommon`
- 🥘 Introduced the `WindowControllerCommon` mixin to
share common windowing functionality between controller types
- I have NOT yet implemented dialogs. This pull request ONLY adds the
idea to the API. Win32 implementation to follow :)
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
## What's new?
- Implement and test `_window_win32.dart`, the Win32 implementation of
`_window.dart` 🎉
- Wrote a bunch of tests in `window_win32_test.dart` which uses a mock
API barrier to mock the native Win32 layer
- Update `BaseWindowController` to extend `ChangeNotifier` and use it to
inform the `WindowScope` of when things change
- Made `RegularWindowController.empty()` a non-internal constructor, as
it is needed by implementations
- Added a _large_ example application for windowing where users can test
out different windowing concepts and see how they work!
To test, simply run the tests or try out the example app!
## 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], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.
