Guard tooltip delay localStorage read
What does this MR do and why?
Guards the tooltip-delay localStorage read in the global boot path (app/assets/javascripts/main.js) so it no longer throws SecurityError: Failed to read the 'localStorage' property from 'Window' in browsers that deny storage access (e.g. blocked cookies/storage on Chrome Mobile).
Because main.js runs on every page, this unguarded read surfaced across a wide spread of feature_category values in Sentry. The fix:
- Wraps the read with the existing
AccessorUtilities.canUseLocalStorage()guard, which safely probes storage access. - Parses the value via the existing
getStorageValue()helper instead of an inline unguardedJSON.parse. - Falls back to the default tooltip delay of
0when storage is unavailable, preserving existing behaviour.
The gl-tooltip-delay key is a dev/debug convenience with no other readers/writers, so guarding the read carries no functional risk. User-facing impact of the bug was nil (tooltips would simply use the default delay), but the error created steady Sentry noise.
References
Screenshots or screen recordings
No UI change — this only guards a localStorage read. Behaviour is unchanged except that storage-denied browsers no longer throw.
| Before | After |
|---|---|
| N/A | N/A |
How to set up and validate locally
- In Chrome DevTools, block third-party cookies / site data (or run in a context where
window.localStorageaccess is denied). - Load any GitLab page.
- Before:
SecurityErroris thrown frommain.jswhen readinglocalStorage.getItem('gl-tooltip-delay'). - After: no error; tooltips initialize with the default delay of
0.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.