fix: fall back to internal storage when external storage is unavailable - #2781
Open
ulite-Amr wants to merge 1 commit into
Open
fix: fall back to internal storage when external storage is unavailable#2781ulite-Amr wants to merge 1 commit into
ulite-Amr wants to merge 1 commit into
Conversation
Contributor
Greptile SummaryThe PR preserves the application entry points and adds resilient startup behavior when external storage is unavailable.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains; the previously reported deletion issue is invalid at the current head because all three application entry-point files remain present and contain targeted modifications. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Device ready] --> B[Probe external storage]
B -->|Available| C[Use external data and cache]
B -->|Unavailable| D[Use internal data and cache]
C --> E[Ensure plugins directory]
E -->|Creation succeeds| F[Continue application bootstrap]
E -->|Creation fails| D
D --> G[Ensure internal plugins directory]
G --> F
Reviews (2): Last reviewed commit: "fix: fall back to internal storage when ..." | Re-trigger Greptile |
ulite-Amr
marked this pull request as draft
August 20, 2026 22:08
ulite-Amr
force-pushed
the
fix/startup-storage-fallback
branch
from
August 20, 2026 22:09
313fcca to
e6fd161
Compare
ulite-Amr
marked this pull request as ready for review
August 20, 2026 22:10
The app used to pick the external data directory unconditionally and then create the plugins directory without guarding against failures. On devices where the external filesystem cannot be created (e.g. Android/data dir is not creatable), the unhandled rejection aborted startup, leaving users stuck on the splash screen with a misleading "Update Android System WebView or Chrome" message. - Probe external storage with fs.stat() and fall back to internal storage - Wrap plugins directory creation in try/catch and fall back to internal - Request storage permissions only on SDK < 33, guarded by hasPermission - Guard editorManager.hasUnsavedFiles() access in exitAppMessage - Show an honest "storage is unavailable" startup message for storage errors
ulite-Amr
force-pushed
the
fix/startup-storage-fallback
branch
from
August 21, 2026 00:03
e6fd161 to
43f8595
Compare
RohitKushvaha01
approved these changes
Aug 21, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes the app failing to start on devices where the external storage directory cannot be created. On such devices users were stuck on the splash screen with a misleading "Acode failed to start. Update Android System WebView or Chrome." message — the WebView was fine, the problem was storage.
Reported by
Root cause
src/main.jsunconditionally picked the external data directory:window.DATA_STORAGE = externalDataDirectory || dataDirectory;fileplugin only registersfiles-externalif the external root directory can be created (newRoot.mkdirs()fails on affected devices), so the chosen URL points at a non-existent filesystem.if (!(await fsOperation(PLUGIN_DIR).exists())) await fsOperation(DATA_STORAGE).createDirectory("plugins");onDeviceReady()beforeloadApp(), leavingeditorManagernull and the splash screen forever — with the error handler blaming WebView/Chrome.Logcat evidence on an affected device:
Changes
src/main.jsresolveStorageDir()— probes the preferred directory withfs.stat()and falls back to internal storage when unavailableDATA_STORAGE/CACHE_STORAGE/PLUGIN_DIR/KEYBINDING_FILEto internal storage and retrieshasPermissionreturns false (ensurePermission()helper), preventing background-activity-launch blockssrc/lib/acode.js—editorManager?.hasUnsavedFiles?.() ?? 0inexitAppMessage(the error above was a downstream symptom of the aborted startup)www/index.html— startup error/rejection handlers now detect storage errors (FileError/NotFoundError/SecurityError/DOMException codes 1-12) and show an honest "Acode failed to start: storage is unavailable" message instead of blaming WebView/ChromeTested
The same patch was verified on an affected device: app now falls back to internal storage and starts normally, and storage errors produce an accurate message. CI (biome, typos, vitest) runs on this PR.
Fixes the class of startup failures reported as "Update Android System WebView or Chrome" that actually originate from unavailable external storage.