You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The output from rustdoc, at the top of the page for a struct or a const, etc., includes a line like,
Struct crate::MyStruct [-][src]
Clicking the [-] on a browser w/ restrictive cookie settings (which typically includes localStorage) results in an error similar to the following:
storage.js:11 Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
at updateLocalStorage (file:///home/[...]/target/doc/storage.js:11:343)
at HTMLAnchorElement.toggleAllDocs (file:///home/[...]/target/doc/main.js:13:997)
Additionally, the section fails to expand or contract, as the exception isn't handled.
rustdoc is attempting to store the collapse/expand state, s.t. later visits to the page presumably maintain that state for the user's convenience.
I browse the web with an admittedly somewhat atypical setup: I whitelist cookies. localStorage, in most browsers, counts, since it is a similar mechanism of persistence. I think Rust's use of localStorage here is fine, but I would request that, if localStorage is forbidden by the user agent, that the documentation gracefully "degrade" to just expanding or contracting the requested item, but not persist it. As it is, the JS crashes while storing the state, and appears to never make it to actually expanding/contracting the item.
The text was updated successfully, but these errors were encountered:
If the user's cookie/persistent storage setting forbid access to localStorage,
catch the exception and abort the access.
Currently, attempting to use the expand/contract links at the top of the page
for structs/consts/etc. fails due to an unhandled error while accessing
localStorage, if such access is forbidden, as the exception from the failed
access propagates all the way out, interrupting the expand/contract. Instead, I
would like to degrade gracefully; the access won't happen (the collapse/expand
state won't get persisted) but the actual expanding/contracting of the item
will go on to succeed.
Fixesrust-lang#55079
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Oct 18, 2018
…GuillaumeGomez
Detect if access to localStorage is forbidden by the user's browser
If the user's cookie/persistent storage setting forbid access to `localStorage`, catch the exception and abort the access.
Currently, attempting to use the expand/contract links at the top of the page for structs/consts/etc. fails due to an unhandled error while accessing `localStorage`, if such access is forbidden, as the exception from the failed access propagates all the way out, interrupting the expand/contract. Instead, I would like to degrade gracefully; the access won't happen (the collapse/expand state won't get persisted) but the actual expanding/contracting of the item will go on to succeed.
Fixesrust-lang#55079
The output from
rustdoc
, at the top of the page for astruct
or aconst
, etc., includes a line like,Clicking the
[-]
on a browser w/ restrictive cookie settings (which typically includeslocalStorage
) results in an error similar to the following:Additionally, the section fails to expand or contract, as the exception isn't handled.
rustdoc
is attempting to store the collapse/expand state, s.t. later visits to the page presumably maintain that state for the user's convenience.I browse the web with an admittedly somewhat atypical setup: I whitelist cookies.
localStorage
, in most browsers, counts, since it is a similar mechanism of persistence. I think Rust's use oflocalStorage
here is fine, but I would request that, iflocalStorage
is forbidden by the user agent, that the documentation gracefully "degrade" to just expanding or contracting the requested item, but not persist it. As it is, the JS crashes while storing the state, and appears to never make it to actually expanding/contracting the item.The text was updated successfully, but these errors were encountered: