Changes:
* Make it so you can click or hover over a post's favorite count to see
the list of public favorites.
* Remove the "Show »" button next to the favorite count.
* Make the favorites list visible to all users. Before favorites were
only visible to Gold users.
* Make the /favorites page show the list of all public favorites,
instead of redirecting to the current user's favorites.
* Add /posts/:id/favorites endpoint.
* Add /users/:id/favorites endpoint.
This is for several reasons:
* To make viewing favorites work the same way as viewing upvotes.
* To make posts load faster for Gold users. Before, we loaded all the
favorites when viewing a post, even when the user didn't look at them.
This made pageloads slower for posts that had hundreds or thousands of
favorites. Now we only load the favlist if the user hovers over the favcount.
* To make the favorite list visible to all users. Before, it wasn't
visible to non-Gold users, because of the performance issue listed above.
* To make it more obvious that favorites are public by default. Before,
since regular users could only see the favcount, they may have
mistakenly believed other users couldn't see their favorites.
Restructure the Dockerfile and the CSS/JS files so that we only rebuild
the CSS and JS when they change, not on every commit.
Before it took several minutes to rebuild the Docker image after every
commit, even when the JS/CSS files didn't change. This also made pulling
images slower.
This requires refactoring the CSS and JS to not use embedded Ruby (ERB)
templates, since this made the CSS and JS dependent on the Ruby
codebase, which is why we had to rebuild the assets after every Ruby
change.
Fix https://github.com/danbooru/danbooru/issues/4783#issuecomment-912426739:
Spoke too soon. It works in flash posts, but not in non-flash posts.
Here's the full trace that happens by trying the Shift-E shortcut
(tested on https://danbooru.donmai.us/posts/4749304 with the latest
ruffle for chrome at https://ruffle.rs/#downloads):
4749304:7 Uncaught TypeError: Cannot read properties of undefined (reading 'appendChild')
at Object.initialize_ruffle_player (application-237cebbe071cb34ce095.js:1)
at Object.initialize_all (application-237cebbe071cb34ce095.js:1)
at HTMLDocument.<anonymous> (application-237cebbe071cb34ce095.js:1)
at f (857-ff5115a2d6ceb23b4291.js:2)
at p (857-ff5115a2d6ceb23b4291.js:2)
at nrWrapper (4749304?q=status%3Aany:7)
Caused by trying to initialize the Ruffle player on non-Flash posts,
because we checked for the existence of the `window.RufflePlayer` object
to tell if we were on a Flash post, but when using the Ruffle browser
extension the RufflePlayer object will always exist.
Fix issue mentioned in 55980c6fb with Javascript spazzing out on Flash
posts and randomly triggering keyboard shortcuts.
The bug was calling `javascript_pack_tag` twice. This caused the
runtime Javascript chunk to be loaded twice, caused a lot of Javascript
errors that somehow resulted in keyboard shortcuts being triggered.
The fix is to combine both calls into `javascript_pack_tag "application", "flash"`.
hxxps://github.com.rails.webpacker.issues.2932
The search form uses a <button type="submit"> tag instead of a
<input type="submit"> tag. It uses a <button> because it contains an
icon and <input> tags can't contain nested tags.
This happens because toggling a related tag updates the tag box, which
triggers autocomplete, which can't find a tag because the cursor isn't
in the tag box, so it ends up making an autocomplete call for the empty
string.
Instead of changing the background color of the entire page when you
change modes in the post mode menu (which was ugly, and not obvious what
the colors meant), show a notice and make it so that hovering a post
gives it a blue outline. This indicates that clicking the post will do
something different.
In the related tags list, use checkboxes and bold to indicate selected
tags, instead of highlighting selected tags with a blue background.
This is so that you can see the colors of selected tags in the related
tags list, and in particular so you can see the artist tag.
Adjust input boxes to fit the screen better on mobile, and to use
consistent sizes throughout the site (no ad-hoc overrides to make
certain input boxes a bit bigger in random places).
On desktop, this makes most input boxes a bit taller and narrower. On
mobile, it makes input boxes the full width of the screen.
This most notably affects the tag edit box, the comment and forum
post box, the wiki page edit box, and the commentary box.
Regression caused by the upgrade to Webpacker 6.0 in 90cd3293e. This
caused various Javascript errors in old versions of Chrome, which
somehow resulted in the keyboard shortcut for visiting the next page
being triggered when you pressed any key.
Specifically, the mobx library (used by the TagCounter component) called
`Object.entries`, which isn't available in Chrome 49, and for some
unknown reason this triggered the buggy shortcut behavior.
`Object.entries` is supposed to be automatically polyfilled by Babel to
support old browsers, but something changed in Webpacker 6 that broke
this and I couldn't get it working again. The probable cause is that
Webpacker 6 no longer transpiles code inside ./node_modules by default,
which means that any libraries we use that use new Javascript features
won't get transpiled down to support old browsers, but even after fixing
that it still didn't work. The workaround is to just drop mobx and
preact entirely to avoid the issue.
On the post show page, define the next page / previous page keyboard
shortcuts in html using data-shortcut attributes instead of in
Javascript. This is consistent with how these shortcuts are defined on
the post index page.
* Factor out the post navbar into a component. The post navbar is the
part of the post containing the current search, the list of pools, and
the list of favgroups, along with next/prev navigation links.
* Change navbar markup: remove various unused CSS classes/IDs, change
pools to use same markup as favgroups, replace nested <div>'s with
flat <ul>/<li> list.
* Use CSS to truncate long searches/pool names/favgroup names if they're
too wide for the screen (especially on mobile).
* Add comment scores.
* Rework voting buttons so that you can click the upvote/downvote
buttons to toggle votes.
* Hide the edit, delete, undelete, and report buttons behind a popup menu.
* Show the upvote/downvote/reply buttons to logged out users. Redirect
them to the login page instead.
Previously thresholded comments were hidden completely. You had to click
the "Show X hidden comments" button to unhide all hidden comments in a
thread. Now it works like this:
* When a comment is below your threshold, the comment text is hidden and
replaced by a `[hidden]` link, which you can click to unhide the comment.
* When a comment is at half your threshold (for example, your threshold
is -8 but the comment is at -4), then the comment is greyed out.
This means that comments aren't completely hidden, they're just
collapsed, so you can see the commenter and the score without unhiding
the comment. It also means you don't have to scroll back up to unhide a
comment, and threads aren't disrupted by comments being secretly
hidden (which is confusing when people are replying to hidden comments,
which forces you to go back up and unhide to find).
The normalization always ends up being less than a pixels difference,
and the clamp applied later on removes that difference. Before the
clamp was added, it had the effect of moving the box along it's angle
of rotation. Now it moves it along the x,y axis of the image itself,
which is probably more intuitive anyways.
It's still needed for the drag and drop though, otherwise, it displaces
by a certain amount making it impossible to accurately place.
This option was originally added in issue #1747. But only ~350 users
ever disabled autocomplete, only ~120 of these were seen in the last
year, and only 9 new users who signed up in the last year disabled it.
Users wishing to disable autocomplete can use this CSS:
.ui-autocomplete { display: none !important: }
or this Javascript:
$("[data-autocomplete]").autocomplete("disable");
Remove the enable_post_navigation option. This option was originally
added to disable the next/prev post navbar beneath posts. It was later
repurposed to disable keyboard shortcuts.
Users who don't want keyboard shortcuts are advised to not press random
buttons on the keyboard like a caveman.
Only ~1200 users disabled this option and only ~600 were seen in the
last year.
This is the scenario:
* You type something in autocomplete, let's say 'touhou'.
* Autocomplete calls /autocomplete?search[query]=touhou&search[type]=tag_query
* The endpoint returns JSON, because the autocomplete call sets an
`Accept: application/json` header requesting JSON.
* Visit /autocomplete?search[query]=touhou&search[type]=tag_query in your browser.
* Notice that the cached JSON response is incorrectly returned, not an
HTML response like the browser requested.
The problem is that the response type is chosen based on the Accept
header, but the response didn't set the `Vary: Accept` header, so the
browser doesn't know the response type can vary and so it incorrectly
returns the cached response.
This issue is partially fixed by Rails 6.1 ([1]), which properly sets the
`Vary: Accept` header when the response depends on the Accept header.
However, the next issue is that Cloudflare doesn't respect the Vary
header at all ([2], [3]). Therefore we can't use the Accept header to
pick the format, instead we have explicitly specify the format with
/autocomplete.json.
This is clearer and better for caching anyway. Using the `Vary: Accept`
header reduces the cache hit rate, because the exact format of the
Accept header varies across browsers, which fragments the cache.
Whew.
[1] https://github.com/rails/rails/pull.36213
[2] https://community.cloudflare.com/t/cloudflare-cdn-cache-to-support-http-vary-header/160802
[3] https://support.cloudflare.com/hc/en-us/articles/115003206852
[4] https://www.smashingmagazine.com/2017/11/understanding-vary-header/
* Remove the `source` and `weight` html data attributes (no longer used).
* Make the `type` html data attribute properly indicate the completion
type. Valid types: `tag`, `tag-alias`, `tag-abbreviation`,
`tag-autocorrect`, `tag-other-name`.
* Set Max-Age= flag instead of Expires= flag.
* Set Secure flag when using HTTPS.
* Extend default cookie lifetime from 1 year to 20 years.
* Remove "session" expiration option (unused).
* Remove max cookie size check.
The cookie size check was previously added in #2518 to deal with running
out of space due to tag scripts and blacklists. This should no longer
happen since we no longer use cookies for these things. Remove the
warning because it should never happen, we can't fix it if it does, and
the user probably won't know how to fix it either.
Display autocorrected tags similar to aliases, with an arrow pointing at
the corrected tag, but with a dotted underline beneath the misspelled
tag to indicate that it's misspelled.
This refactors the autocomplete Javascript to use a single dedicated
/autocomplete.json endpoint instead of a bunch of separate endpoints.
This simplifies the autocomplete Javascript by making it so that instead
of calling a different endpoint for each type of query (for users, wiki
pages, pools, artists, etc), then having to parse the results of each
call to get the data we need, we can call a single endpoint that returns
exactly what we need.
This also means we don't have to parse searches clientside in order to
autocomplete metatags. Instead we can just pass the search term to the
server and let it parse the search, which is easy to do serverside.
Finally, this makes autocomplete easier to test, and it makes it easier
to add more sophisticated autocomplete behavior, since most of the logic
lives serverside.
