Expanded items under Quick Access collapse when the window regains focus
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript
- Área
- frontend
Línea de trabajo
Start by tracing the visibilitychange handler in account-panel/dist/panels/AccountPanel/index.js to ensureCorrectSubscriptionNodes in out/app/index.js, then read resetAndRefreshChildren() in explorer-panel. Reproduce the focus change with expanded Quick Access items and check how child view models are rebuilt. Done means expanded descendants remain open after returning to the window, without breaking refreshes after subscription changes.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Storage Explorer Version
1.47.1
Regression From
No response
Architecture
x64
Storage Explorer Build Number
20261106.18
Platform
Windows
OS Version
Windows 11
Bug Description
When I switch away from Storage Explorer and come back, everything I expanded under Quick Access collapses. The Quick Access node stays expanded, but the containers and folders inside it close every time the window regains focus. Attached Blob, Queue, Table and File services seem to lose their expanded state in the same way.
Analysis (from the shipped JS bundles)
account-panel/dist/panels/AccountPanel/index.jsregisters:document.addEventListener("visibilitychange", () => { const hidden = document.webkitHidden; hidden ? Host.executeFunction("StorageExplorer.TopLevelNodes.ensureCorrectSubscriptionNodes") : vm.refresh(); });- In
out/app/index.js,StorageExplorer.TopLevelNodes.ensureCorrectSubscriptionNodesunconditionally runs
QuickAccessManager.instance.refreshQuickAccessNode()andResourceTree.refreshChildren(...)on all attached service nodes. refreshQuickAccessNode()→ResourceTree.refreshChildren(["Azure.QuickAccess"])+expand(["Azure.QuickAccess"]).- In
explorer-panel,resetAndRefreshChildren()disposes the child group view model and builds a new one, carrying over only the parent's ownisExpanded()state. Descendant expansion state is lost.
So a visibility change that isn't a user action triggers a full rebuild of Quick Access, which loses the user's expansion state.
Suggested fixes
- Only run
ensureCorrectSubscriptionNodeswhen subscription/account selection actually changed (or only when the user leaves the Account panel, not on window-level visibility changes); and/or - Make
resetAndRefreshChildren()preserve and restore the expansion state of descendants (e.g. by node UID) after reloading.
Workaround
Locally removing the refreshQuickAccessNode() call from ensureCorrectSubscriptionNodes in out/app/index.js stops the collapse (tested on 1.47.1). This confirms the call is the cause. With that change, Quick Access no longer auto-refreshes after subscription changes.
Resource Types
Quick Access - Storage Accounts
Authentication Method
Sign in
Connection Type
Sign in (subscription)
Steps to Reproduce
- Pin a storage account or container to Quick Access.
- Expand the item and some of its children (e.g. Blob Containers → a container).
- Switch to another application (or minimize Storage Explorer), then return.
Actual Experience
Quick Access stays expanded, but every item underneath it collapses. Attached Blob/Queue/Table/File service nodes appear to lose their child state in the same way.
Expected Experience
The Quick Access tree keeps its expansion state.
Additional Context
No response
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 458
- Forks
- 92
- Merge medio
- 17 h 57 min
- PR fusionados (30 d)
- 4
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/AzureStorageExplorer
-
Copilot usage documentationAbierto
Dificultad 2/5 1-2 días Aptitud para principiantes 76/100
microsoft/AzureStorageExplorer#9186 ·
-
:globe_with_meridians: hard-coded string :globe_with_meridians: localization :test_tube: testing
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/AzureStorageExplorer#9152 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
microsoft/AzureStorageExplorer#9234 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 22/100
microsoft/AzureStorageExplorer#9233 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 42/100
microsoft/AzureStorageExplorer#9232 ·
Todos los issues de microsoft/AzureStorageExplorer
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 75/100
SACGF/variantgrid#2791 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
bug from-app needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
nightly-labs/openbot#7447 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Codeinwp/themeisle-companion#1014 ·
Los mantenedores suelen responder en 1 día
-
repo:cms
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
craftcms/cms#20596 · 1 comentario ·
Los mantenedores suelen responder en 1 día