This was broken in https://github.com/flutter/flutter/pull/122452. The culprit is that `PipelineOwner.ensureSemantics` doesn't turn on semantics for the entire app, it pretends to only turn it on for the local `PipelineOwner`. Unfortunately, that local `PipelineOwner` is never informed that it should produce semantics when semantics are not turned on globally. So, `PipelineOwner.ensureSemantics` is essentially without effect if semantics are not already turned on globally.
I can't think of a use case where it would be useful to only turn on semantics for a particular pipeline owner and fixing `PipelineOwner.ensureSemantics` would get pretty messy with performance implications even if semantics are turned off. So, this PR deprecates that functionality and moves the `SemanticsDebugger` to the global semantics API.
Fixes https://github.com/flutter/flutter/issues/147665.
Here's another PR with a couple of typos fixed. As you can see there was a typo in _fileReferenceI**n**dentifiers_, in class _ParsedProjectInfo._ Maybe we should do some check on that since I'm not sure if that property is used somewhere outside Flutter?
Use a dedicated `TextPainter` for intrinsic size calculation in `RenderEditable` and `RenderParagraph`.
This is an implementation detail so the change should be covered by existing tests. Performance wise this shouldn't be significantly slower since SkParagraph [caches the result of slower operations across different paragraphs](9c62e7b382/modules/skparagraph/src/ParagraphCache.cpp (L254-L272)). Existing benchmarks should be able to catch potential regressions (??).
The reason for making this change is to make sure that intrinsic size computations don't destroy text layout artifacts, so I can expose the text layout as a stream of immutable `TextLayout` objects, to signify other render objects that text-layout-dependent-cache (such as caches for `getBoxesForRange` which can be relatively slow to compute) should be invalidated and `markNeedsPaint` needs to be called if the painting logic depended on text layout.
Without this change, the intrinsics/dry layout calculations will add additional events to the text layout stream, which violates the "dry"/non-destructive contract.
When a Sliver with items is outside of the Viewport, but within the Viewport's `cacheExtent`, the framework should create SemanticNodes for the items even though they are out of view. However, for this to work, the Sliver's geometry must have a `cacheExtent` (how much space the sliver took up of the Viewport's `cacheExtent`) greater than 0, otherwise it is [excluded](f01ce9f4cb/packages/flutter/lib/src/rendering/viewport.dart (L311-L315)).
`SliverFillRemaining` widgets that fall outside the viewport did not have this set and therefore were being excluded when SemanticNodes were created, even if they were within the Viewport's `cacheExtent`. This PR sets the `cacheExtent` for `SliverFillRemaining` widgets.
In addition, `RenderSliverFillRemainingWithScrollable` would get dropped from the semantic tree because it's child had a size of 0 when outside the remaining paint extent. To fix, we give the child a `maxExtent` of the sliver's `cacheExtent` if it's outside the remaining paint extent but within the viewport's cacheExtent.
Fixes https://github.com/flutter/flutter/issues/142065.
Definitions:
* `RenderViewport.cacheExtent`:
```dart
/// The viewport has an area before and after the visible area to cache items
/// that are about to become visible when the user scrolls.
///
/// Items that fall in this cache area are laid out even though they are not
/// (yet) visible on screen. The [cacheExtent] describes how many pixels
/// the cache area extends before the leading edge and after the trailing edge
/// of the viewport.
///
/// The total extent, which the viewport will try to cover with children, is
/// [cacheExtent] before the leading edge + extent of the main axis +
/// [cacheExtent] after the trailing edge.
///
/// The cache area is also used to implement implicit accessibility scrolling
/// on iOS: When the accessibility focus moves from an item in the visible
/// viewport to an invisible item in the cache area, the framework will bring
/// that item into view with an (implicit) scroll action.
```
* `SliverGeometry.cacheExtent`:
```dart
/// How many pixels the sliver has consumed in the
/// [SliverConstraints.remainingCacheExtent].
```
* `SliverContraints.remainingCacheExtent`:
```dart
/// Describes how much content the sliver should provide starting from the
/// [cacheOrigin].
///
/// Not all content in the [remainingCacheExtent] will be visible as some
/// of it might fall into the cache area of the viewport.
///
/// Each sliver should start laying out content at the [cacheOrigin] and
/// try to provide as much content as the [remainingCacheExtent] allows.
```
I was doing some debugging on a RenderSliver subclass, and found
that SliverConstraints.toString was missing the precedingScrollExtent
field.
Add that, and add both that field and userScrollDirection to the
`==` and hashCode implementations, which had been skipping them,
so that all three methods now handle all the class's fields.
Originally, my aim was just to refactor (as per usual), but while messing around with the `TableBorder.symmetric` constructor, I realized that `borderRadius` was missing!
This pull request makes a few class constructors more efficient, and it fixes#144277 by adding the missing parameter.
<br>
This pull request fixes#143803 by taking advantage of Dart's null-aware operators.
And unlike `switch` expressions ([9 PRs](https://github.com/flutter/flutter/pull/143634) and counting), the Flutter codebase is already fantastic when it comes to null-aware coding. After refactoring the entire repo, all the changes involving `?.` and `??` can fit into a single pull request.
My RenderSliverMultiBoxAdaptor/RenderSliverFixedExtentList/RenderSliverVariedExtentList yak shave continues.
I've been subclassing RenderSliverVariedExtentList for SliverTree and have found some opportunities for clean up.
There is a larger clean up I'd like to do, but this week SliverTree comes first.
I noticed these methods were getting repeated ð, and I was about to repeat them again ð for the tree, so I figured bumping them up to the base class was better than continuing to copy-paste the same methods.
Multiple methods in `RenderSliverFixedExtentBoxAdaptor` pass a `double itemExtent` for computing things like what children will be laid out, what the max scroll offset will be, and how the children will be laid out.
Since `RenderSliverFixedExtentBoxAdaptor` was further subclassed to support a `itemExtentBuider` in `RenderSliverVariedExtentList`, these itemExtent parameters became useless when using that RenderObject. Reading through `RenderSliverFixedExtentBoxAdaptor.performLayout`, the remaining artifacts of passing around itemExtent make it hard to follow when it is irrelevant.
`RenderSliverFixedExtentBoxAdaptor.itemExtent` is available from these methods, so it does not need to pass it. It is redundant API.
Plus, if a bogus itemExtent is passed for some reason, errors will ensue and the layout will be incorrect. ð£ ð¥
Deprecating so we can remove these for a cleaner API. Unfortunately this is not supported by dart fix, but the fact that these methods are protected means usage outside of the framework is likely minimal.
Fixes https://github.com/flutter/flutter/issues/79495
This is basically a reland of https://github.com/flutter/flutter/pull/79607.
Currently when the cursor is invalid, arrow key navigation / typing / backspacing doesn't work since the cursor position is unknown.
Showing the cursor when the selection is invalid gives the user the wrong information about the current insert point in the text.
This is going to break internal golden tests.
Reverts flutter/flutter#142339
In the original change one of the tests included the same view twice which resulted in a different failure than the expected one. The second commit contains the fix for this. I don't understand how this wasn't caught presubmit on CI.
Reverts flutter/flutter#141484
Initiated by: eliasyishak
This change reverts the following previous change:
Original Description:
The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
The existing `runApp` bootstraps the widget tree and renders the provided widget into the default view (which is currently the implicit View from `PlatformDispatcher.implicitView` and - in the future - may be a default-created window). Apps, that want more control over the View they are rendered in, need a new way to bootstrap the widget tree: `runWidget`. It does not make any assumptions about the View the provided widget is rendered into. Instead, it is up to the caller to include a View widget in the provided widget tree that specifies where content should be rendered. In the future, this may enable developers to create a custom window for their app instead of relying on the default-created one.
Much nicer calling API and simplifies evolving this API in the future.
I wish we could write a dart fix for this, but that's blocked on https://github.com/dart-lang/sdk/issues/54668.
- Unskip `text_style_test` for CanvasKit.
- Remove no longer necessary `kIsWeb` checks in a few tests.
This PR depends on https://github.com/flutter/engine/pull/49786, which rolled into the framework. If the engine PR needs to be reverted, this PR will need to be reverted too.
This disables the expectation for `TileMode` stringification because
https://github.com/flutter/engine/pull/49786 is about to fix it (as in,
the test would fail when the engine fix lands).
This reverts commit
d24c01bd0c.
The original change was reverted because it caused some apps to get
stuck on the splash screen on some phones.
An investigation determined that this was due to a rounding error.
Example: The device reports a physical size of 1008.0 x 2198.0 with a
dpr of 1.912500023841858. Flutter would translate that to a logical size
of 527.0588169589221 x 1149.2810314243163 and use that as the input for
its layout algorithm. Since the constraints here are tight, the layout
algorithm would determine that the resulting logical size of the root
render object must be 527.0588169589221 x 1149.2810314243163.
Translating this back to physical pixels by applying the dpr resulted in
a physical size of 1007.9999999999999 x 2198.0 for the frame. Android
now rejected that frame because it didn't match the expected size of
1008.0 x 2198.0 and since no frame had been rendered would never take
down the splash screen.
Prior to dynamically sized views, this wasn't an issue because we would
hard-code the frame size to whatever the requested size was.
Changes in this PR over the original PR:
* The issue has been fixed now by constraining the calculated physical
size to the input physical constraints which makes sure that we always
end up with a size that is acceptable to the operating system.
* The `ViewConfiguration` was refactored to use the slightly more
convenient `BoxConstraints` over the `ViewConstraints` to represent
constraints. Both essentially represent the same thing, but
`BoxConstraints` are more powerful and we avoid a couple of translations
between the two by translating the` ViewConstraints` from the
`FlutterView` to `BoxConstraints` directly when the `ViewConfiguration`
is created.
All changes over the original PR are contained in the second commit of
this PR.
Fixes b/316813075
Part of https://github.com/flutter/flutter/issues/134501.
Fix and unskip the following CanvasKit tests:
- `test/painting/decoration_test.dart`
- `test/rendering/layers_test.dart`
- `test/widgets/app_overrides_test.dart`
Fixes https://github.com/flutter/flutter/issues/131435, https://github.com/flutter/flutter/issues/104594, https://github.com/flutter/flutter/issues/43400
Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text.
The new TextPaintes method tells you the layout bounds `(width = letterspacing / 2 + x_advance + letterspacing / 2, height = font ascent + font descent)` of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of its character's layout bounds.
Potential issues:
In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference.
This is a breaking change.
I want to build a widget that adds some extra functionality when the inner text overflow. So the problem occurred, I can't find an elegant way to determine if the text is overflowing.
So i expose `didExceedMaxLines` from `RenderParagraph`, I think it can make sense. Have there some advice?
Reverts flutter/flutter#139717
Initiated by: LongCatIsLooong
This change reverts the following previous change:
Original Description:
Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400
Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure).
Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text.
The new TextPaintes method tells you the layout bounds (`width = letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds.
Potential issues:
1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference.
This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
Fixes https://github.com/flutter/flutter/issues/131435, #104594, #43400
Needs https://github.com/flutter/engine/pull/48774 (to fix the web test failure).
Currently the method we use for text span hit testing `TextPainter.getPositionForOffset` always returns the closest `TextPosition`, even when the given offset is far away from the text.
The new TextPaintes method tells you the layout bounds (`width = letterspacing / 2 + x_advance + letterspacing / 2`, `height = font ascent + font descent`) of a character, the PR changes the hit testing implementation such that a TextSpan is only considered hit if the point-down event landed in one of it's character's layout bounds.
Potential issues:
1. In theory since the text is baseline aligned, we should use the max ascent and max descent of each character to calculate the height of the text span's hit-test region, in case some characters in the span have to fall back to a different font, but that will be slower and it typically doesn't make a huge difference.
This is a breaking change. It also introduces a new finder and a new method `WidgetTester.tapOnText`: `await tester.tapOnText('string to match')` for ease of migration.
Towards https://github.com/flutter/flutter/issues/134501.
This change is based on https://github.com/flutter/engine/pull/48090. It changes the `RenderView` to be dynamically sized based on its content if the `FlutterView` it is configured with allows it (i.e. the `FlutterView` has loose `FlutterView.physicalConstraints`). For that, it uses those `physicalConstraints` as input to the layout algorithm by passing them on to its child (after translating them to logical constraints via the device pixel ratio). The resulting `Size` that the `RenderView` would like to be is then communicated back to the engine by passing it to the `FlutterView.render` call.
Tests will fail until https://github.com/flutter/engine/pull/48090 has rolled into the framework.
This updates the implementation to use the stopwatch from the Clock object and pipes it through to the TestWidgetsFlutterBinding so it will be kept in sync with FakeAsync.
Relands https://github.com/flutter/flutter/pull/138843 attempted to reland https://github.com/flutter/flutter/pull/137381 which attempted to reland #132291
Fixes https://github.com/flutter/flutter/issues/97761
1. The original change was reverted due to flakiness it introduced in tests that use fling gestures.
* Using a mocked clock through the test binding fixes this now
2. It was reverted a second time because a change at tip of tree broke it, exposing memory leaks, but it was not rebased before landing.
* These leaks are now fixed
3. It was reverted a third time, because we were so excellently quick to revert those other times, that we did not notice the broken benchmark that only runs in postsubmit.
* The benchmark is now fixed
**What has been done?**
----------------------
Added new enumeration in `TableCellVerticalAlignment`, which sets the cell size to the same as the topmost cell. There are no noticeable problems in using it in all cells together, as there are in `TableCellVerticalAlignment.fill` which is made not to be used in all cells together because it has another purpose.
**Explanation of the logic**
----------------------
An assignment was made (which already existed in `TableCellVerticalAlignment.top; middle and bottom`) that assigns `rowHeight` the maximum double between the initialized height and the height of its child.
Basically, defining a minimum cell height based on its child, and letting each table row have its own height stipulated from the largest element, creating an `IntrinsicHeight` for TableCell automatically.
As the `TableCellVerticalAlignment` logic already provides for the use of the height of the largest cell in the row, it was possible to reuse this logic, and just not make the break statement that exists to fill in the calculation for `intrinsicHeight`.
Real example in an Android application after added enumeration
----------------------
Opened issue
----------------------
FIX: #130261
Reverts flutter/flutter#137381
Initiated by: Piinks
This change reverts the following previous change:
Original Description:
This updates the implementation to use the stopwatch from the Clock object and piping it through to the TestWidgetsFlutterBinding so it will be kept in sync with FakeAsync.
Relands #132291
Fixes https://github.com/flutter/flutter/issues/97761
The change was reverted due to flakiness it introduced in tests that use fling gestures.
* https://github.com/flutter/flutter/issues/135728
