Implements the framework side of secure paste milestone 2, where the iOS
system context menu items can be customized.
Depends on PR https://github.com/flutter/flutter/pull/161103. Currently
I've merged that PR into this one for testing, but I think that PR
should merge separately first.
### Widget API (most users)
```dart
TextField(
contextMenuBuilder: (BuildContext context, EditableTextState editableTextState) {
return SystemContextMenu.editableText(
editableTextState: editableTextState,
// items is optional
items: <IOSSystemContextMenuItem>[
const IOSSystemContextMenuItemCut(),
constIOS SystemContextMenuItemCopy(),
const IOSSystemContextMenuItemPaste(),
const IOSSystemContextMenuItemSelectAll(),
const IOSSystemContextMenuItemSearchWeb(
title: 'Search!', // title is optional for this button, defaults to localized string
),
// Milestone 3:
IOSSystemContextMenuItemCustom(
// title and onPressed are required
title: 'custom button',
onPressed: () {
print('pressed the custom button.');
}
),
],
);
},
),
```
### Raw Controller API
```dart
_systemContextMenuController.show(
widget.anchor,
<IOSSystemContextMenuItemData>[
// Notice these are different classes than those used for the widget. That's
// mainly because I can't provide localized defaults here, so the titles are
// required in the classes that have titles.
const IOSSystemContextMenuItemDataCut(),
const IOSSystemContextMenuItemDataCopy(),
const IOSSystemContextMenuItemDataPaste(),
const IOSSystemContextMenuItemDataSelectAll(),
const IOSSystemContextMenuItemDataSearchWeb(
title: 'Search!', // title is required.
),
// Milestone 3:
IOSSystemContextMenuItemDataCustom(
// title and onPressed are required as before.
title: 'custom button',
onPressed: () {
print('pressed the custom button.');
}
),
],
);
```
<details>
<summary>Json format</summary>
```dart
return _channel.invokeMethod<Map<String, dynamic>>(
'ContextMenu.showSystemContextMenu',
<String, dynamic>{
'targetRect': <String, double>{
'x': targetRect.left,
'y': targetRect.top,
'width': targetRect.width,
'height': targetRect.height,
},
'items': <dynamic>[
<String, dynamic>{
'type': 'default',
'action': 'paste',
},
<String, dynamic>{
'type': 'default',
'action': 'copy',
},
<String, dynamic>{
'type': 'default',
'title': 'Crazy Title',
'action': 'share',
},
],
},
);
```
</summary>
</details>
### Localization changes
This change requires the SystemContextMenu widget in the widgets library
to be able to look up the default localized label for several context
menu buttons like "Copy", etc. Those strings previously resided in
MaterialLocalizations and CupertinoLocalizations, but not in
WidgetsLocalizations, so I have copied the necessary strings into
WidgetsLocalizations.
---------
Co-authored-by: Huan Lin <hellohuanlin@gmail.com>
<!-- start_original_pr_link -->
Reverts: flutter/flutter#140783
<!-- end_original_pr_link -->
<!-- start_initiating_author -->
Initiated by: matanlurey
<!-- end_initiating_author -->
<!-- start_revert_reason -->
Reason for reverting: This broke presubmit (which was skipped using
`added this pull request to the merge queue 2 hours ago`).
See https://github.com/flutter/flutter/issues/162715. Adding to the
merge queue manually is _not_ safe currently.
<!-- end_revert_reason -->
<!-- start_original_pr_author -->
Original PR Author: ueman
<!-- end_original_pr_author -->
<!-- start_reviewers -->
Reviewed By: {bkonyi}
<!-- end_reviewers -->
<!-- start_revert_body -->
This change reverts the following previous change:
This makes various Flutter version information available at runtime.
It's basically the same as executing `flutter --version`. This is
especially useful for tools like Crashlytics or Sentry (see for example
https://github.com/getsentry/sentry-dart/issues/416).
Usage example:
```dart
FlutterVersion.version; // 3.16.5
FlutterVersion.channel; // stable
FlutterVersion.gitUrl; // https://github.com/flutter/flutter.git
FlutterVersion.frameworkRevision; // 78666c8dc5
FlutterVersion.engineRevision; // 3f3e560236
FlutterVersion.dartVersion; // 3.2.3
```
This approach has prior art as seen in #134179.
Fixes https://github.com/flutter/flutter/issues/61814
<!-- *If you had to change anything in the [flutter/tests] repo, include
a link to the migration guide as per the [breaking change policy].* -->
## 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] 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
[test-exempt]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement
[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
<!-- end_revert_body -->
Co-authored-by: auto-submit[bot] <flutter-engprod-team@google.com>
We only need to conditionally send motion events to the platform_view_2
channel. This can be done with an override in the controller, the
existing surface classes don't need to be touched.
Use the PlatformViewController2 to register a platform view, allow the
dart side platform view logic to opt into this new platform view. Wires
up an integration test with android_engine_test.
This auto-formats all *.dart files in the repository outside of the
`engine` subdirectory and enforces that these files stay formatted with
a presubmit check.
**Reviewers:** Please carefully review all the commits except for the
one titled "formatted". The "formatted" commit was auto-generated by
running `dev/tools/format.sh -a -f`. The other commits were hand-crafted
to prepare the repo for the formatting change. I recommend reviewing the
commits one-by-one via the "Commits" tab and avoiding Github's "Files
changed" tab as it will likely slow down your browser because of the
size of this PR.
---------
Co-authored-by: Kate Lovett <katelovett@google.com>
Co-authored-by: LongCatIsLooong <31859944+LongCatIsLooong@users.noreply.github.com>
When running `dart format` over these lines the `// ignore` ended up on
a line where it wasn't properly ignoring the lint. This adjusts the
placement of `// ignore`s so they will continue to ignore the right
thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire
repo will go in smoother without manual intervention.
Enables the Scribe feature, or Android stylus handwriting text input.
This PR only implements basic handwriting input. Other features will be
done in subsequent PRs:
* https://github.com/flutter/flutter/issues/155948
* https://github.com/flutter/flutter/issues/156018
I created and fixed issue about stylus hovering while working on this:
https://github.com/flutter/flutter/issues/148810
Original PR for iOS Scribble, the iOS version of this feature:
https://github.com/flutter/flutter/pull/75472
FYI @fbcouch
~~Depends on https://github.com/flutter/engine/pull/52943~~ (merged).
Fixes https://github.com/flutter/flutter/issues/115607
<details>
<summary>Example code I'm using to test this feature (but any TextField
works)</summary>
```dart
import 'package:flutter/material.dart';
import 'package:flutter/scheduler.dart';
import 'package:flutter/services.dart';
void main() {
runApp(const MyApp());
}
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return const MaterialApp(
home: MyHomePage(),
);
}
}
class MyHomePage extends StatefulWidget {
const MyHomePage({super.key});
@override
State<MyHomePage> createState() => _MyHomePageState();
}
class _MyHomePageState extends State<MyHomePage> {
final FocusNode _focusNode1 = FocusNode();
final FocusNode _focusNode2 = FocusNode();
final FocusNode _focusNode3 = FocusNode();
final TextEditingController _controller3 = TextEditingController(
text: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.',
);
@override
Widget build(BuildContext context) {
return Scaffold(
appBar: AppBar(
title: const Text('Scribe demo'),
),
body: Center(
child: Padding(
padding: const EdgeInsets.symmetric(horizontal: 74.0),
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: <Widget>[
TextField(
focusNode: _focusNode1,
autofocus: false,
),
TextField(
focusNode: _focusNode2,
),
TextField(
focusNode: _focusNode3,
minLines: 4,
maxLines: 4,
controller: _controller3,
),
TextButton(
onPressed: () {
_focusNode1.unfocus();
_focusNode2.unfocus();
_focusNode3.unfocus();
},
child: const Text('Unfocus'),
),
TextButton(
onPressed: () {
_focusNode1.requestFocus();
SchedulerBinding.instance.addPostFrameCallback((Duration _) {
SystemChannels.textInput.invokeMethod('TextInput.hide');
});
},
child: const Text('Focus 1'),
),
],
),
),
),
);
}
}
```
</details>
---------
Co-authored-by: Nate Wilson <nate.w5687@gmail.com>
This pull request aims to improve code readability, based on feedback gathered in a recent design doc.
<br>
There are two factors that hugely impact how easy it is to understand a piece of code: **verbosity** and **complexity**.
Reducing **verbosity** is important, because boilerplate makes a project more difficult to navigate. It also has a tendency to make one's eyes gloss over, and subtle typos/bugs become more likely to slip through.
Reducing **complexity** makes the code more accessible to more people. This is especially important for open-source projects like Flutter, where the code is read by those who make contributions, as well as others who read through source code as they debug their own projects.
<hr>
<br>
The following examples show how pattern-matching might affect these two factors:
<details> <summary><h3>Example 1 (GOOD)</h3> [click to expand]</summary>
```dart
if (ancestor case InheritedElement(:final InheritedTheme widget)) {
themes.add(widget);
}
```
Without using patterns, this might expand to
```dart
if (ancestor is InheritedElement) {
final InheritedWidget widget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(widget);
}
}
```
Had `ancestor` been a non-local variable, it would need to be "converted" as well:
```dart
final Element ancestor = this.ancestor;
if (ancestor is InheritedElement) {
final InheritedWidget inheritedWidget = ancestor.widget;
if (widget is InheritedTheme) {
themes.add(theme);
}
}
```
</details>
<details> <summary><h3>Example 2 (BAD) </h3> [click to expand]</summary>
```dart
if (widget case PreferredSizeWidget(preferredSize: Size(:final double height))) {
return height;
}
```
Assuming `widget` is a non-local variable, this would expand to:
```dart
final Widget widget = this.widget;
if (widget is PreferredSizeWidget) {
return widget.preferredSize.height;
}
```
<br>
</details>
In both of the examples above, an `if-case` statement simultaneously verifies that an object meets the specified criteria and performs a variable assignment accordingly.
But there are some differences: Example 2 uses a more deeply-nested pattern than Example 1 but makes fewer useful checks.
**Example 1:**
- checks that `ancestor` is an `InheritedElement`
- checks that the inherited element's `widget` is an `InheritedTheme`
**Example 2:**
- checks that `widget` is a `PreferredSizeWidget`
(every `PreferredSizeWidget` has a `size` field, and every `Size` has a `height` field)
<br>
<hr>
I feel hesitant to try presenting a set of cut-and-dry rules as to which scenarios should/shouldn't use pattern-matching, since there are an abundance of different types of patterns, and an abundance of different places where they might be used.
But hopefully the conversations we've had recently will help us converge toward a common intuition of how pattern-matching can best be utilized for improved readability.
<br><br>
- resolves https://github.com/flutter/flutter/issues/152313
- Design Doc: [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns)
## Description
This factors out a separate `RawView` that doesn't add a `MediaQuery` or a `FocusScope`. This PR also adds a new method `WidgetsBindingObserver.didChangeViewFocus` which allows the observer to know when the `FlutterView` that has focus has changed.
It also makes the `View` widget a stateful widget that contains a `FocusScope` and ` FocusTraversalGroup` so that it can respond to changes in the focus of the view.
I've also added a new function to `FocusScopeNode` that will allow the scope node itself to be focused, without looking for descendants that could take the focus. This lets the focus be "parked" at the `FocusManager.instance.rootScope` so that nothing else appears to have focus.
## Tests
- Added tests for the new functionality.
Reverts: flutter/flutter#148238
Initiated by: zanderso
Reason for reverting: Failures in post submit https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8748025189669617649/+/u/run_test.dart_for_web_canvaskit_tests_shard_and_subshard_3/stdout
Original PR Author: justinmc
Reviewed By: {hellohuanlin}
This change reverts the following previous change:
Reland of https://github.com/flutter/flutter/pull/143002, which was reverted in https://github.com/flutter/flutter/pull/148237 due to unresolved docs references. Not sure why those weren't caught in presubmit.
```
dartdoc:stdout: Generating docs for package flutter...
dartdoc:stderr: error: unresolved doc reference [TextInput.showSystemContextMenu]
dartdoc:stderr: from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/widgets/media_query.dart:579:14)
dartdoc:stderr: in documentation inherited from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/widgets/media_query.dart:579:14)
dartdoc:stderr: error: unresolved doc reference [showSystemContextMenu]
dartdoc:stderr: from services.SystemContextMenuController.hide: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/services/text_input.dart:2554:16)
dartdoc:stderr: error: unresolved doc reference [hideSystemContextMenu]
dartdoc:stderr: from services.SystemContextMenuController.show: (file:///b/s/w/ir/x/w/flutter/packages/flutter/lib/src/services/text_input.dart:2509:16)
```
It's now possible to use the native-rendered text selection context menu on iOS. This sacrifices customizability in exchange for avoiding showing a notification when the user presses "Paste". It's off by default, but to enable, see the example system_context_menu.0.dart.
Reverts: flutter/flutter#143002
Initiated by: cbracken
Reason for reverting: unresolved docs links. See failure here: https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20docs_test/16540/overview
```
dartdoc:stdout: Generating docs for package flutter...
dartdoc:stderr: error: unresolved doc reference [TextInput.showSystemContextMenu]
dartdoc:stderr: from widgets.MediaQueryData.supportsShowingSystemContextMenu: (file:///b/s/w/ir/x/w/flutter/packages/flutt
Original PR Author: justinmc
Reviewed By: {Renzo-Olivares, hellohuanlin}
This change reverts the following previous change:
In order to work around the fact that iOS 15 shows a notification on pressing Flutter's paste button (https://github.com/flutter/flutter/issues/103163), this PR allows showing the iOS system context menu in text fields.
<img width="385" alt="Screenshot 2024-02-06 at 11 52 25 AM" src="https://github.com/flutter/flutter/assets/389558/d82e18ee-b8a3-4082-9225-cf47fa7f3674">
It is currently opt-in, which a user would typically do like this (also in example system_context_menu.0.dart):
```dart
contextMenuBuilder: (BuildContext context, EditableTextState editableTextState) {
// If supported, show the system context menu.
if (SystemContextMenu.isSupported(context)) {
return SystemContextMenu.editableText(
editableTextState: editableTextState,
);
}
// Otherwise, show the flutter-rendered context menu for the current
// platform.
return AdaptiveTextSelectionToolbar.editableText(
editableTextState: editableTextState,
);
},
```
Requires engine PR https://github.com/flutter/engine/pull/50095.
## API changes
### SystemContextMenu
A widget that shows the system context menu when built, and removes it when disposed. The main high-level way that most users would use this PR. Only works on later versions of iOS.
### SystemContextMenuController
Used under the hood to hide and show a system context menu. There can only be one visible at a time.
### MediaQuery.supportsShowingSystemContextMenu
Sent by the iOS embedder to tell the framework whether or not the platform supports showing the system context menu. That way the framework, or Flutter developers, can decide to show a different menu.
### `flutter/platform ContextMenu.showSystemContextMenu`
Sent by the framework to show the menu at a given `targetRect`, which is the current selection rect.
### `flutter/platform ContextMenu.hideSystemContextMenu`
Sent by the framework to hide the menu. Typically not needed, because the platform will hide the menu when the user taps outside of it and after the user presses a button, but it handles edge cases where the user programmatically rebuilds the context menu, for example.
### `flutter/platform System.onDismissSystemContextMenu`
Sent by the iOS embedder to indicate that the system context menu has been hidden by the system, such as when the user taps outside of the menu. This is useful when there are multiple instances of SystemContextMenu, such as with multiple text fields.
It's now possible to use the native-rendered text selection context menu on iOS. This sacrifices customizability in exchange for avoiding showing a notification when the user presses "Paste". It's off by default, but to enable, see the example system_context_menu.0.dart.
## Description
This PRs changes the default value transit mode for key event simulation.
The default transit mode for key event simulation is currently `KeyDataTransitMode.rawKeyData` while on the framework side `KeyDataTransitMode.keyDataThenRawKeyData` is the preferred transit mode.
`KeyDataTransitMode.keyDataThenRawKeyData` is more accurate and can help detect issues.
For instance the following test will fail with `KeyDataTransitMode.rawKeyData` because raw keyboard logic for modifier keys is less accurate:
```dart
testWidgets('Press control left once', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.keyDataThenRawKeyData;
final List<KeyEvent> events = <KeyEvent>[];
final FocusNode focusNode = FocusNode();
addTearDown(focusNode.dispose);
await tester.pumpWidget(
Focus(
focusNode: focusNode,
autofocus: true,
onKeyEvent: (_, KeyEvent event) {
events.add(event);
return KeyEventResult.handled;
},
child: Container(),
),
);
await simulateKeyDownEvent(LogicalKeyboardKey.controlLeft);
// This will fail when transit mode is KeyDataTransitMode.rawKeyData
// because a down event for controlRight is synthesized.
expect(events.length, 1);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
And the following this test is ok with `KeyDataTransitMode.rawKeyData` but rightly fails with `KeyDataTransitMode.keyDataThenRawKeyData`:
```dart
testWidgets('Simulates consecutive key down events', (WidgetTester tester) async {
debugKeyEventSimulatorTransitModeOverride = KeyDataTransitMode.rawKeyData;
// Simulating several key down events without key up in between is tolerated
// when transit mode is KeyDataTransitMode.rawKeyData, it will trigger an
// assert on KeyDataTransitMode.keyDataThenRawKeyData.
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
await simulateKeyDownEvent(LogicalKeyboardKey.arrowDown);
debugKeyEventSimulatorTransitModeOverride = null;
});
```
## Related Issue
Related to https://github.com/flutter/flutter/issues/143845
## Tests
Adds two tests.
## Description
This removes an unneeded expectation in the test for the AppLifecycleListener. It's unneeded because the test immediately resets the state anyhow. I'm removing it because the web implementation sets the value when initializing, so it's never initially null there.
## Related PR
- https://github.com/flutter/engine/pull/44720#issuecomment-1898482363
## Description
Adds some convenience methods to `KeyEvent` that allow testing to see if a logical or physical key is pressed from the event object. These are similar to the ones already on `RawKeyEvent`, and will make migration the to `KeyEvent` easier (so it could more easily be a `flutter fix` migration).
Added:
- `bool isLogicalKeyPressed(LogicalKeyboardKey key)`
- `bool isPhysicalKeyPressed(PhysicalKeyboardKey key)`
- `bool get isControlPressed`
- `bool get isShiftPressed`
- `bool get isAltPressed`
- `bool get isMetaPressed`
## Related Issues
- https://github.com/flutter/flutter/issues/136419
## Tests
- Added tests for the new methods.
This PR modifies the web build slightly to create an `AssetManifest.json`, that is a JSON(base64)-encoded version of the `AssetManifest.bin` file.
_(This should enable all browsers to download the file without any interference, and all servers to serve it with the correct headers.)_
It also modifies Flutter's `AssetManifest` class so it loads and uses said file `if (kIsWeb)`.
### Issues
* Fixes https://github.com/flutter/flutter/issues/124883
### Tests
* Unit tests added.
* Some tests that run on the Web needed to be informed of the new filename, but their behavior didn't have to change (binary contents are the same across all platforms).
* I've deployed a test app, so users affected by the BIN issue may take a look at the PR in action:
* https://dit-tests.web.app
This wraps up the platform view improvements discussed in https://github.com/flutter/flutter/issues/127030.
- Splits `HtmlElementView` into 2 files that are conditionally imported.
- The non-web version can be instantiated but it throws if it ends up being built in a widget tree.
- Out-of-the-box view factories that create visible & invisible DOM elements given a `tagName` parameter.
- New `HtmlElementView.fromTagName()` constructor that uses the default factories to create DOM elements.
- Tests covering the new API.
Depends on https://github.com/flutter/engine/pull/43828
Fixes https://github.com/flutter/flutter/issues/127030
The change in [0] has propagated now everywhere, so we can use
`utf8.encode()` instead of the longer `const Utf8Encoder.convert()`.
Also it cleans up code like
```
TypedData bytes;
bytes.buffer.asByteData();
```
as that is not guaranteed to be correct, the correct version would be
```
TypedData bytes;
bytes.buffer.asByteData(bytes.offsetInBytes, bytes.lengthInBytes);
```
a shorter hand for that is:
```
TypedData bytes;
ByteData.sublistView(bytes);
```
[0] https://github.com/dart-lang/sdk/issues/52801
