# Objective
Add a `context()` extension method to `Result<T>` and `Option<T>` like
`anyhow`
## Solution
Add a `Vec<String>` field to `InnerBevyError` to store context messages
added via `context()`
Fixes#19714.
## Testing
Added the `context` unit test to test messages produced by `context() `
and a `context_downcasting` unit test to test that downcasting still
works when using `.context`
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Currently, a panic (whether from engine or user code, as there is little
distinction) takes down the entire app with it. Instead the user should
be able to decide how the error is handled. This is currently not
possible except by writing your own executor and setting it for all
relevant schedules.
See for comparison Godot's policy on exceptions:
> ### [Why does Godot not use
exceptions?](https://docs.godotengine.org/en/stable/about/faq.html#why-does-godot-not-use-exceptions)
>
> We believe games should not crash, no matter what. If an unexpected
situation happens, Godot > will print an error (which can be traced even
to script), but then it will try to recover as > gracefully as possible
and keep going.
Unity will also log an error and then continue if user code throws an
exception. I believe Unreal does too for exceptions coming from
Blueprints. Similarly, many web servers will respond with an error to a
request that threw an exception, but will not crash the server itself.
This PR does not enable this behavior by default, but makes it
user-configurable.
Also fixes#19109
Also (I think) fixes#7434
## Solution
Instead of rethrowing panics, hand them to the `FallbackErrorHandler`.
If the panic was thrown by an error handler in the first place, we don't
need to pass it back to a handler again. I've added a way for the error
handler to signal that it's the source of the panic.
The constructed error is created without a backtrace, as the default
panic handler already prints it when instructed to via
`RUST_LIB_BACKTRACE`/`RUST_BACKTRACE`.
Panics will not be turned into errors on `no_std` projects.
Potential work for a future PR:
- if a error handler has been specified with e.g. `queue_handled`, use
this error handler instead of the fallback error handler
- if a command panics, still apply the remaining commands in the buffer?
## Testing
See added `panic_to_error` test
---------
Co-authored-by: Gonçalo Rica Pais da Silva <bluefinger@gmail.com>
# Objective
The text input widget selects the word under the pointer on a double
click. This isn't correct, the select word edit should be queued on the
press following a click. This allows for users to select a word with a
double press and then hold the button and drag to extend the selection.
## Solution
Track multi-presses as well as multi-clicks:
- Add a `count` field to `Press` events.
- Update the click count in `PointerButtonState::clicking` on
consecutive presses within the multi-click duration, not on releases.
- Filter the `clicking` map in both the `Press` and `Click` dispatchers.
- Removed the `MULTI_CLICK_DURATION` const.
- The multi-click duration can now be set using a new
`multi_click_duration` field on the `PickingSettings` resource.
## Testing
```
cargo run --example multiline_text_input
```
You should observe that dragging after selecting a word with a double
press extends the selection.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Allow UI elements to be positioned relative to the viewport rather than
their parent element.
Fixes#9564
## Solution
- New UI marker component `FixedNode`. Requires `Node` and
`OverrideClip`.
- `FixedNode` entities are treated as UI roots in layout, even if they
have a parent.
- `FixedNode`s don't inherit their parent's layout, clipping or
transform context.
- During the taffy layout updates children with `FixedNode` are skipped.
- Added a couple of basic helper functions to `UiSurface`, mainly there
to make the tests a little less painful.
- Added a fairly comprehensive range of new tests, including tests with
`GhostNode`s.
- In the Taffy layout (stored in `UiSurface`) there is nothing to
distinguish `FixedNode`s and root nodes, so they are treated identically
during updates.
--
The original suggestion was to implement it as a `PositionType::Fixed`
variant that could used with `Node`, but I think that would be much more
complicated without support from Taffy. Being able to just directly
query for and filter out `FixedNode` entities directly makes the
implementation much simpler and more efficient.
## Testing
Basic example which shows events bubbling up to the parent from the
fixed node:
```
cargo run --example fixed_node
```
There are also a number of new tests in the `layout` module.
```
cargo test -p bevy_ui --lib --features ghost_nodes
```
---------
Co-authored-by: François Mockers <francois.mockers@vleue.com>
See release notes for rationale and usage.
Fixes#17644, #20524
(It may not be a 100% fix, but it's good enough to close the ticket I
think.)
## Testing
- Manual testing with VoiceOver on MacOS (note that VoiceOver /
AccessKit does not work well without `desktop_app` being set, but this
causes other issues)
---------
Co-authored-by: Richard Braakman <rebraakman@gmail.com>
The release is nigh! One of the most important tasks is to get the
release notes ready.
I've done them all in a single batch to avoid endless spam and to be
able to consider them in context.
Two of them are deliberately omitted: the BSN notes ( @cart has claimed
these) and render-graph-as-systems ( for @tychedelia).
Key things I focused on when editing and writing these release notes:
- what is worth teaching about, and how much detail does it need
- how do we contextualize and motivate each feature
- is the usage clearly demonstrated without taking up too much space
- the tone should be fun, clear, and optimistic throughout
---------
Co-authored-by: Trashtalk217 <trashtalk217@gmail.com>
Co-authored-by: Adam__ <67244228+Based-A@users.noreply.github.com>
# Objective
- Fixes#23183
- The issue describes strobing that happens on OOM’s (that used to just
crash the application). I’ve also seen strobing happen on validation
errors while some examples were in a broken state very recently. I
believe it’s cause OOM’s and Validations are ignored, which just leads
for rendering to resume and hit those same issues again. The looping is
somehow causing the flashing. To protect against this strobing, I think
the default render error policy needs to be changed.
## Solution
- Instead of ignoring any errors and continuing to render, this PR
changes the default error policy to quit the application upon any error.
OOM and Validation error induced strobing will not happen cause the app
should just quit. I’m not aware of strobing that could happen on
DeviceLost / Internal errors, but I’m leaning towards safety here. You
can correct me (within reason) if there are some obvious errors we
should handle with a different error policy, but I think this is a
better starting point than `Ignore` for all.
- Note: At times, even with this code, I’ve seen the app flash to a
magenta/pink color before exiting (not a strobing pink that would happen
if the app ignored validation errors, just a single abrupt switch before
app exit), so I’m wondering if it’s better to throw a `panic!` rather
than try to quit gracefully.
## Testing
- Fortunately, the `pccm` example and `light_probe_blending` examples
are still broken on `main`.
- `cargo r --example light_probe_blending --features free_camera,https`
correctly closes the app upon Validation error
- `cargo run --example pccm --features="free_camera https”` does the
same.
<details>
<summary>Example console logs</summary>
```
cargo r --example light_probe_blending --features free_camera,https
Compiling bevy v0.19.0-dev (/Users/kchen/CodingProjects/bevy)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 11.24s
Running `target/debug/examples/light_probe_blending`
2026-05-05T01:04:33.028208Z INFO bevy_diagnostic::system_information_diagnostics_plugin::internal: SystemInfo { os: "macOS 26.4.1", kernel: "25.4.0", cpu: "Apple M4", core_count: "10", memory: "16.0 GiB" }
2026-05-05T01:04:33.031189Z WARN bevy_asset::io::web: WebAssetPlugin is potentially insecure! Make sure to verify asset URLs are safe to load before loading them. If you promise you know what you're doing, you can silence this warning by setting silence_startup_warning: true in the WebAssetPlugin construction.
2026-05-05T01:04:33.448175Z INFO bevy_render::renderer: AdapterInfo { name: "Apple M4", vendor: 0, device: 0, device_type: IntegratedGpu, device_pci_bus_id: "", driver: "", driver_info: "", backend: Metal, subgroup_min_size: 4, subgroup_max_size: 64, transient_saves_memory: true }
2026-05-05T01:04:34.315115Z INFO bevy_pbr::cluster: GPU clustering is supported on this device.
2026-05-05T01:04:34.315226Z INFO bevy_render::batching::gpu_preprocessing: GPU preprocessing is fully supported on this device.
2026-05-05T01:04:34.611394Z INFO bevy_winit::system: Creating new window Bevy Light Probe Blending Example (65v0)
2026-05-05T01:04:37.312262Z ERROR bevy_render::error_handler: Caught rendering error: Validation Error
Caused by:
In Device::create_bind_group, label = 'mesh_view_bind_group_binding_array'
Number of bindings in bind group descriptor (3) does not match the number of bindings defined in the bind group layout (0)
2026-05-05T01:04:37.900677Z ERROR bevy_render::error_handler: Quitting the application due to Validation RenderError
2026-05-05T01:04:37.964583Z WARN bevy_ecs::world::command_queue: CommandQueue has un-applied commands being dropped. Did you forget to call SystemState::apply?
2026-05-05T01:04:37.964628Z WARN bevy_ecs::world::command_queue: CommandQueue has un-applied commands being dropped. Did you forget to call SystemState::apply?
...
```
</details>
There is some `WARN bevy_ecs::world::command_queue: CommandQueue has
un-applied commands being dropped. Did you forget to call
SystemState::apply?` spam (like at least 20+ lines of it) after quitting
the application; if anyone knows if that could be prevented somehow, I’m
keen to learn.
---------
Co-authored-by: atlv <email@atlasdostal.com>
# Objective
Alternative to #24004.
https://github.com/bevyengine/bevy/pull/23288 adds ltc luts for rect
light support which implicitly requires `bevy_image/ktx2` and
`bevy_image/zstd` otherwise loading ltc luts will panic.
We either accept to always enable area light supoort (#24004), or add a
feature to opt out it (this PR).
## Solution
Gate ltc luts behind a feature and merge them to a texture array.
## Testing
`rect_light` example works.
---------
Co-authored-by: Kevin Chen <chen.kevin.f@gmail.com>
# Objective
An existing migration guide + release note got clobbered by the
`bevy_scene` -> `bevy_ecs_serialization` rename.
Fixes#24007.
## Solution
Carefully integrate the rename into the text to make the migration less
confusing.
First pass on the release notes. I generated a couple of images for the
post-processing effects and the parallax correction, and I fixed a
couple of small mistakes. I also removed two release notes because I
don't think they were necessary.
This reverts commit 98c69104c4.
# Objective
@cart's
[objections](https://discord.com/channels/691052431525675048/749335865876021248/1499119335828881529):
1. I'm not sure top-level World methods for path-driven access is
justifiable in its current form. For anything but the smallest
application, looping over every Name in the app to find the one you're
looking for is pretty much never what you want
2. Calling Name::to_string() and collecting the result in a Vec isn't
going to cut it performance wise. Even within the scoped context of
entity access we shouldn't be doing any allocations or "recomputations".
Just the act of comparison across all entities is arguably too expensive
## Solution
Revert it for now and go back to revising the work before landing it.
## Plan going forward
[Core
plan](https://discord.com/channels/691052431525675048/749335865876021248/1499120012034838692):
1. An EntityRef API that is always relative to the current entity
2. Grab the Children component.
3. Iterate over it, read the Name on each component, see if it matches
the current piece of the path.
4. Add docs discouraging usage in most cases; users should prefer
`EntityTemplate` and pre-resolved connections.
As discussed
[here](https://discord.com/channels/691052431525675048/749335865876021248/1499120218927271987),
opt-in names indexing (both all names for inspector use cases and based
on With filters for e.g. animation) should be considered too, but
doesn't need to be in the MVP. @laundmo suggests the use of a trie,
while Sander says that a hashmap is adequate in flecs.
# Objective
Fixes: #16201
Originally based on and closes: #20848
## Solution
Add two to methods to world
```rust
fn get_entity_from_path<R: Relationship, C: Component + PartialEq + Clone>(
&self,
root: Option<Entity>,
path: &[C],
) -> Option<Entity>;
fn get_path_from_entity<R: Relationship, C: Component + PartialEq + Clone>(
&self,
root: Option<Entity>,
entity: Entity,
) -> Option<Vec<C>>;
```
Original methods were taken from #20848, but changed to focus on bottom
up search instead of a top down search, which should hopefully be more
efficient and made them generic over the relationship.
Also added an `EntityPath` variant to `EntityTemplate`.
## Testing
Tests included and working.
## Showcase
```rust
#[derive(Component)]
#[relationship(relationship_target = WieldedBy)]
pub struct Weapon(pub Entity);
#[derive(Component)]
#[relationship_target(relationship = Weapon)]
pub struct WieldedBy(Entity):
fn player() -> impl Scene {
bsn! {
Player
Weapon("Items/Weapons/Sword")
}
}
```
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Part of #19236
## Solution
A numeric text input widget. This includes:
* Colored stripes ("sigils") for designating X, Y and Z input fields.
* Character filtering
* ValueChange events
Not supported:
* Validation error events
* Range and precision options
Additional changes in this PR:
* Added small labels (related to text inputs only insofar as numeric
inputs have small labels above them in the editor design).
* Refactored labels to be simple spans instead of nested entities - this
required a non-inherited text font theme component, so we renamed the
existing component to have the word "inherited" in the name.
* Consolidated the way focus outlines work for text inputs and other
widgets
* I had to make changes to Slider and other widgets to support the
`is_final` flag in `ValueChange`. This is necessary to allow listeners
the choice between spammy and not-spammy updates when listening to
widget outputs.
## Testing
Manual testing
## Showcase
<img width="353" height="101" alt="numeric_input"
src="https://github.com/user-attachments/assets/36efd243-fa01-484e-bab5-689aa6be4d9e"
/>
# Objective
Fixes https://github.com/bevyengine/bevy/issues/23814
It isn't clear whether we should be detailing what is now possible with
bevy settings (can use enums and tuple structs) in the release notes so
i've left it as is but happy to collate code examples and the toml they
result in and add this.
# Objective
- Give thanks :)
## Solution
- Gives the thanks!
- I assumed it was the person listed as the owner here:
https://crates.io/crates/bevy-settings
Make BUFFER_BINDING_ARRAY conditional on whether the material uses
buffer binding arrays. Fix sampler limit to check array element count
instead of binding slot count. Only create binding arrays for resource
types the material actually uses, reducing overhead on all platforms.
## Objective
Fixes#18149
Metal supports `TEXTURE_BINDING_ARRAY` but not `BUFFER_BINDING_ARRAY`.
Bindless was disabled entirely on Metal because `bindless_supported()`
required both unconditionally.
## Solution
1. **Conditional feature check**: Only require `BUFFER_BINDING_ARRAY`
when the material actually uses buffer binding arrays.
2. Materials using `#[data(...)]`, textures, and samplers (like
`StandardMaterial`) only need `TEXTURE_BINDING_ARRAY`. **Fix sampler
limit check**: Use `max_binding_array_sampler_elements_per_shader_stage`
(array element count) instead of `max_samplers_per_shader_stage`
(binding slot count).
3. **Only create needed binding arrays**:
`create_bindless_bind_group_layout_entries` now skips resource types the
material doesn't use. This stays within Metal's 31 argument buffer slot
limit and reduces wasted fallback resources on all platforms.
## Testing
Bistro Exterior (698 materials), 5-minute runs:
| GPU | Avg FPS (before → after) | Min FPS (before → after) | RAM/VRAM |
|-----|--------------------------|--------------------------|----------|
| Apple M2 Max (Metal) | 115 → 136 **(+18%)** | 60 → 106 **(+77%)** |
-57 MB RAM |
| NVIDIA 5060 Ti | 118 → 217 **(+84%)** | 60 → 165 **(+174%)** | Same |
| Intel i360P | 25 → 29 **(+15%)** | Same | Same |
| AMD Vega 8 / Ryzen 4800U | 25 → 25 | Same | **-88 MB VRAM** |
| Intel Iris XE | ~22 → ~22 | Same | No regression |
Also tested: `3d_scene`, `pbr`, `lighting`, `transmission`,
`deferred_rendering`: all pass with zero errors.
Materials using `#[uniform(..., binding_array(...))]` correctly fall
back to non-bindless on Metal.
# Objective
Upstream `jackdaw`'s `TransformGizmo`!
## Solution
Add `TransformGizmoPlugin` to bevy_gizmos as an optional plugin that
draws on a focused entity and lets the user click/drag to manipulate its
transform. Rotate, Translate, and Scale are all individual gizmos -
perfect opportunity for someone to extend and create a combined gizmo in
a follow-up :)
## Testing
- Manually tested with cargo run --example transform_gizmo --features
free_camera:
- All three modes (translate, rotate, scale) work
- Focus switch between objects, and gizmo moves across
- World/local space toggle and editing
- Tested on Linux (X11)
## Showcase
Mark any entity with `TransformGizmoFocus` to get interactive handles:
```rust
app.add_plugins(TransformGizmoPlugin);
commands.spawn((
Mesh3d(mesh),
MeshMaterial3d(material),
TransformGizmoFocus,
));
// Switch modes via resource
mode.set(TransformGizmoMode::Rotate);
```
The `transform_gizmo` example shows input cycling and keyboard mode
switching (1/2/3 for translate/rotate/scale, X to toggle world/local
space)
## Video
### Jackdaw
https://github.com/user-attachments/assets/8193b3ed-ae9c-416d-9514-8fb4f42a1f90
### Transform Example
https://github.com/user-attachments/assets/fea22981-4e61-492e-918e-9791ddf5a00d
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Add support for more keys and keyboard shortcuts to `editable_text`.
## Solution
Added support for the most common keyboard shortcuts to
`editable_text`'s `on_focused_keyboard_input` observer system.
* Alternative shortcuts are used on macOS.
* Uses constants for modifier keys for sake of clarity.
* Shortcuts are matched on exact, exclusionary modifier combinations.
* Enter & Tab left out as they need additional logic for special cases
etc.
* Placeholder clipboard implementation using a `Clipboard` resource.
Can't access the OS clipboard, but allows copy, cut and paste to be
tested.
## Testing
```
cargo run --example editable_text
```
Could easily be mistakes in the match statement. Unfortunately some of
the shortcuts can't be tested with the `editable_text` example because
it doesn't allow multiple lines atm. It's not the end of the world if
there are bugs though, can be easily corrected later.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
- Bevy is now at a point where multiple people are experimenting with
editors and pretty much all of them need an infinite grid
- There are various techniques that can be used to render an infinite
grid without artifacts. This one fades out the lines that are too far
from the camera. The general idea is that the grid is rendered in a
fullscreen pass.
- [bevy_infinite_grid](https://github.com/fslabs/bevy_infinite_grid) is
maintained by foresight spatial labs. It has been used by foresight and
other third party projects in production for many years at this point.
This PR upstreams that crate with full permission from foresight.
## Solution
- Upstream bevy_infinite_grid
- A few minor changes were done to bring it in line with the rest of
bevy
- In the process of upstreaming I noticed a few minor issues that I
fixed like using a fullscreen triangle instead of a quad and using
bevy's View instead of custom one.
- The infinite_grid is currently part of bevy_dev_tools since we don't
have an editor crate but I suspect we'll want to move it to an editor
crate down the line. Although I'm sure projects will want to use this
even if they aren't using the official editor.
## Testing
- I tested the example to confirm it works
---
## Showcase
<img width="1280" height="720" alt="infinite_grid_cSJj0G02fP"
src="https://github.com/user-attachments/assets/cacddc5e-9a54-454b-aefa-b7829c34227a"
/>
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Add pointer support for editable text, click to place the cursor and
drag to extend selections.
## Solution
Two new observer systems in the editable_text module, `on_pointer_press`
and `on_pointer_drag`.
Very simple implementation, just calculates the pointer's local position
and queues it with the appropriate `TextEdit` variant.
# Objective
Make release notes and migration guides show up first when viewing PRs
in github.
## Solution
Prefix the release-content directory with `_` so it sorts first.
## Testing
See for yourself.
Cookie