| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/81928
“Ask forgiveness not permission” : this makes the code both simpler and more robust
|
|
|
|
rustdoc has various user-configurable preferences. These are recorded
in web Local Storage (where available). But we want to provide a way
to configure the default default, including for when web storage is
not available.
getSettingValue is the function responsible for looking up these
settings. Here we make it fall back some in-DOM data, which
ultimately comes from RenderOptions.default_settings.
Using HTML data atrtributes is fairly convenient here, dsspite the
need to transform between snake and kebab case to avoid the DOM
converting kebab case to camel case (!)
We cache the element and dataset lookup in a global variable, to
ensure that getSettingValue remains fast.
The DOM representation has to be in an element which precedes the
inclusion of storage.js. That means it has to be in the <head> and we
should not use an empty <div> as the container (although most browsers
will accept that). An empty <script> element provides a convenient
and harmless container object. <meta> would be another possibility
but runs a greater risk of having unwanted behaviours on weird
browsers.
We trust the RenderOptions not to contain unhelpful setting names,
which don't fit nicely into an HTML attribute. It's awkward to quote
dataset keys.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
Currently, storage.js and main.js have many open-coded calls to
getCurrentValue for "rustdoc-" values, but these are settings and
should be handled by getSettingValue.
So make getSettingValue part of storage.js (where everyone can call
it) and use it everywhere.
No functional change yet. We are going to make getSettingValue do
something more sophisticated in a moment.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
|
|
|
|
If the user doesn't have a preferred dark theme but is already using a
dark theme, set the preferred dark theme to be that theme
|
|
|
|
|
|
|
|
|
|
|
|
[rustdoc] Fix system theme detection
Fixes #63830
The problem is that it returns the property "entirely" (so with the quotes in our case). Removing them fixes the issue.
cc @fenhl
r? @kinnison
|
|
Save crate filtering on rustdoc
Fixes #62929.
I added a hashmap and a hash encoding for the current crate list in case you have multiple crates handling on a same website (who talked about docs.rs?!). Like that, for each context, you have the filter crate selected.
r? @QuietMisdreavus
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change removes the small bit of jslint config, replacing it
with eslint. I've currently configured eslint to mostly only report
the more serious of lints, although there are still some style nits
turned on.
Upcoming changes will start fixing lints.
|
|
|
|
|
|
|
|
1. Extract the tests for whether or not we have workable localStorage out into
a helper method, so it can be more easily reused
2. Use it in getCurrentValue() too, for the same reasons, as suggested in code
review
|
|
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.
Fixes #55079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
