Description
When opening an Event from a scenario in landscape orientation, the dialog does not consistently start at the top of its scrollable content. Shortly after opening, it scrolls down by a small amount automatically.
This appears to be a regression introduced in the July 2026 changes. A build from roughly ~40 days earlier did not show the same behavior.
The issue is much easier to notice in landscape because the vertical viewport is shorter. Portrait may appear unaffected because more monitored fields are already fully visible.
Steps to reproduce
- Start a scenario and open the scenario editor in landscape orientation.
- Open an existing Event.
- Observe the initial position of the Event configuration dialog.
- The content may initially appear at/near the top and then automatically scroll downward slightly.
The same mechanism may also affect other scrollable configuration dialogs such as Image Condition dialogs.
Expected behavior
Opening an Event/Condition configuration dialog should leave its scroll position at the top unless the user scrolls it, or unless an active tutorial explicitly needs to reveal a monitored UI element.
Actual behavior
The dialog can automatically scroll during the first moments after opening, even during normal editing with no tutorial being followed.
Suspected regression / root cause
The strongest suspect is commit:
ca40f9939ca00374fc3cfdebba59096d2d9e343b
"Automatically scroll to monitored view"
That change added delayed visibility checks to ViewMonitor and, when a monitored view is not fully visible, finds a NestedScrollView ancestor and calls smoothScrollTo(...) to bring the view into view.
The important part is that normal configuration dialogs attach monitored tutorial views unconditionally:
EventDialog.onStart() calls viewModel.monitorViews(...) for Conditions, AND/OR controls, Actions, Initial State, Save, etc.ImageConditionDialog.onStart() similarly registers Save, detection type, area selector, visibility, etc.MonitoredViewsManagerImpl.attach(...) attaches a ViewMonitor without checking whether a tutorial is actually active.
Because ViewMonitor now has a scrolling side effect, tutorial instrumentation can alter normal non-tutorial UI behavior.
This is especially visible in landscape: lower monitored fields are more likely to be partially outside the shorter NestedScrollView viewport, so the new visibility check scrolls the dialog down to expose them.
There was also a related July 9 change:
855b90da3b490392f1bc60d80f2993bf1ee9b2ce
"Fix condition and action access in tutorials"
which changed Event Actions monitoring to the new layoutActionsSelector wrapper. This may affect monitored geometry, but ca40f993 appears to be the main behavioral regression because it introduced the actual automatic scrolling.
Possible fix
Only perform scrollIntoViewIfNeeded() when a tutorial is actively requesting/using that monitored view, rather than whenever any monitored view is attached.
Alternatively, gate the dialog monitoring/auto-scroll behavior behind tutorial-active state.
This would preserve tutorial auto-navigation while preventing monitoring from changing ordinary Event/Condition editor scroll positions.
Description
When opening an Event from a scenario in landscape orientation, the dialog does not consistently start at the top of its scrollable content. Shortly after opening, it scrolls down by a small amount automatically.
This appears to be a regression introduced in the July 2026 changes. A build from roughly ~40 days earlier did not show the same behavior.
The issue is much easier to notice in landscape because the vertical viewport is shorter. Portrait may appear unaffected because more monitored fields are already fully visible.
Steps to reproduce
The same mechanism may also affect other scrollable configuration dialogs such as Image Condition dialogs.
Expected behavior
Opening an Event/Condition configuration dialog should leave its scroll position at the top unless the user scrolls it, or unless an active tutorial explicitly needs to reveal a monitored UI element.
Actual behavior
The dialog can automatically scroll during the first moments after opening, even during normal editing with no tutorial being followed.
Suspected regression / root cause
The strongest suspect is commit:
ca40f9939ca00374fc3cfdebba59096d2d9e343b"Automatically scroll to monitored view"
That change added delayed visibility checks to
ViewMonitorand, when a monitored view is not fully visible, finds aNestedScrollViewancestor and callssmoothScrollTo(...)to bring the view into view.The important part is that normal configuration dialogs attach monitored tutorial views unconditionally:
EventDialog.onStart()callsviewModel.monitorViews(...)for Conditions, AND/OR controls, Actions, Initial State, Save, etc.ImageConditionDialog.onStart()similarly registers Save, detection type, area selector, visibility, etc.MonitoredViewsManagerImpl.attach(...)attaches aViewMonitorwithout checking whether a tutorial is actually active.Because
ViewMonitornow has a scrolling side effect, tutorial instrumentation can alter normal non-tutorial UI behavior.This is especially visible in landscape: lower monitored fields are more likely to be partially outside the shorter
NestedScrollViewviewport, so the new visibility check scrolls the dialog down to expose them.There was also a related July 9 change:
855b90da3b490392f1bc60d80f2993bf1ee9b2ce"Fix condition and action access in tutorials"
which changed Event Actions monitoring to the new
layoutActionsSelectorwrapper. This may affect monitored geometry, butca40f993appears to be the main behavioral regression because it introduced the actual automatic scrolling.Possible fix
Only perform
scrollIntoViewIfNeeded()when a tutorial is actively requesting/using that monitored view, rather than whenever any monitored view is attached.Alternatively, gate the dialog monitoring/auto-scroll behavior behind tutorial-active state.
This would preserve tutorial auto-navigation while preventing monitoring from changing ordinary Event/Condition editor scroll positions.