Resolves https://github.com/flutter/flutter/issues/99149
## 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.
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>
This was previously connected to right alt, which was confusing the
keyboard handling code into generating up events for this key when it
didn't match the expected values. This key is also configurable, and
only defaults to right alt in Ubuntu/GNOME.
Fixes https://github.com/flutter/flutter/issues/154053
Developers will need to _conditionally_ use HCPP (or the framework will
need to handle it automatically). This requires the ability to query at
runtime whether HCPP mode is enabled + supported.
Add a message channel to do so, and add the usage of this to the
android_engine_test. Does not yet add any automatic selection.
---------
Co-authored-by: Matan Lurey <matanlurey@users.noreply.github.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>
## Description
Adding reference to the Human Interface documentation about Haptics in the `HapticFeedback` docs.
The Human Haptic Guidelines documentation are excellent since they provide visualizations that show how these different haptics actually are with some interactive demos, for example with Impact haptics (see image below). Such helps developers decide what haptic to go for and understand when they should be used.
<img width="675" alt="Screenshot 2024-11-13 at 15 13 10" src="https://github.com/user-attachments/assets/909240d3-1981-4e25-9bed-b3b52154e662">
This is simply removing unnecessary parenthesis from various places. This change is because of a change to the unnecessary_parentesis lint that will trigger there. Here is the CL https://dart-review.googlesource.com/c/sdk/+/390161.
- https://github.com/dart-lang/linter/issues/4996
If anything else is needed please let me know.
I'd like to ask for this PR to wait a bit until the bots are run again on that CL so that I can be sure nothing else will trigger, I will come back here and update this whenever everything is complete. Thanks!
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)
Hopefully soon, [flutter.dev/go/dart-patterns](https://flutter.dev/go/dart-patterns) will have lots of good feedback; in the meantime, I'll focus refactoring efforts on uncontroversial things :)
Previously, I was under the impression that I could solve issue #143803 with [just 1 PR](https://github.com/flutter/flutter/pull/143804).
It turns out that I had overlooked quite a bit!
<br>
```dart
// before
if (chunkEvents != null) {
chunkEvents.listen((ImageChunkEvent event) {
reportImageChunkEvent(event);
},
);
}
// after
chunkEvents?.listen(reportImageChunkEvent);
```
This sentence didn't make a lot of sense as written. It looks like
it was probably based on the doc of invokeMapMethod, and then
incompletely adapted. So, fix it.
## 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.
This pull request aims for improved readability, based on issue #146600.
```dart
// before
Set<Color> _distinctVisibleColors() {
final Set<Color> distinctVisibleColors = <Color>{};
if (top.style != BorderStyle.none) {
distinctVisibleColors.add(top.color);
}
if (right.style != BorderStyle.none) {
distinctVisibleColors.add(right.color);
}
if (bottom.style != BorderStyle.none) {
distinctVisibleColors.add(bottom.color);
}
if (left.style != BorderStyle.none) {
distinctVisibleColors.add(left.color);
}
return distinctVisibleColors;
}
// after
Set<Color> _distinctVisibleColors() {
return <Color>{
if (top.style != BorderStyle.none) top.color,
if (right.style != BorderStyle.none) right.color,
if (bottom.style != BorderStyle.none) bottom.color,
if (left.style != BorderStyle.none) left.color,
};
}
```
Most of the repo should be covered in this PR (aside from `flutter_tools/`, since there was a lot going on in there).
In order for text fields to work correctly in multi-view on the web, we need to have the `viewId` information sent to the engine (`TextInput.setClient`). And while the text field is active, if it somehow moves to a new `View`, we need to inform the engine about such change (`TextInput.updateConfig`).
Engine PR: https://github.com/flutter/engine/pull/51099
Fixes https://github.com/flutter/flutter/issues/137344
