Fun little bug: viewing the "Engulfed in Flames Effect" item was
showing our "502 Bad Gateway" custom error page in the embed. This is
because the Rails app was providing a `Content-Security-Policy` header
value that was longer than nginx is configured by default to allow, so
it was refusing the response, and showing the same 502 error as if the
app hadn't responded at all. (We discovered this by opening
`/var/log/nginx/error.log`, which explained this very clearly, ty~!)
In this change, we no longer list every `images.neopets.com` asset,
instead marking the entire domain as a valid image source for the
SWF asset embed iframe. I don't _love_ this solution, I liked the
property of specifying literally exactly the assets we allow! But I
don't think there's any practical danger here, and it helps a *lot* for
making this more reliable.
(If we could have solved this reliably by increasing nginx's allowed
response header size, I probably would've done that? But I researched a
bit, and ultimately concluded that I don't trust other intermediary
software like firewalls not to have the same issue. Let's not be
pushing the limits of HTTP headers of all things!)
This shouldn't ever be an issue in practice? I just noticed it because
something funny is going on with the `#userbar` element specifically
not using the Delicious font, and so I figured, hey, this simulates a
very real possible scenario, I'd rather use our consistent sans font
in this case!
Huh okay, moving to my other machine, the change to Noto Sans subtly
broke the homepage layout a bit, wrapping the form buttons to the next
line in the three module sections.
Here, I refactor to more modern grid/flexbox sensibilities. Btw, there
was a Flexbox thing that didn't work quite how I expected? I commented
on my confusion, but checked in Chrome and Firefox and it seems to work
in both, so, ok!
Okay cool, so this was an error that was happening *only* when building
assets for production: Sass's CSS minifier isn't familiar with all
modern CSS syntax (I think is the issue?), and so errors on things that
are actually totally okay.
I had previously worked around this in `swf_assets/show.css` with an
equivalent syntax that Sass recognized. But in this latest case with
the new `fonts.css.erb`, it was upset about the `src` list for the
fonts, and I don't know a workaround for that.
So, let's just disable Sass's CSS minification for now. I imagine the
difference isn't huge when CSS compresses just fine with gzip anyway?
(Most of what you can "minify" in CSS is whitespace, and that largely
seems silly to me when gzip is running.)
I was just scrolling our CSS and surprised to find we use Google Fonts
embeds! I don't like depending on external hosts like that.
Google Fonts doesn't offer the Droid fonts for download anymore,
though—looks like the Noto fonts are their spiritual successor. The
Droid Serif and Noto Serif fonts look visually identical to me, but the
Sans ones are a bit different… I kinda like the charm of the Droid Sans
better, but ah well! I'd rather be moving forward with a more modern
font with more reliable glyph support etc for now.
I think this has just been broken for a long time? And I don't think
it's very useful in a world 15 years later, where our problem *used* to
be giant gaps in our library, which isn't really our data problem
anymore.
No more of this loading everything into `application.css`! I'm
arbitrarily starting here because that's where I've been playing
lately, but this is part of a larger effort to move toward a more
straightforward CSS architecture (and away from Sass even?)
Ran into a funny thing on an upcoming change, where a style on the
page-specific stylesheet was getting undone by the *CSS Reset* of all
things in the application stylesheet. Resets come first!
I haven't audited that I didn't break a ton of stuff with this change,
but. I hope not! :)
Closes#3, by adapting the suggested changes! Thank you!!
We both change how we create pet name preview jobs, by catching the `@`
case early; and we better handle symbols in pet names when showing the
thank you message, by parsing the query string more correctly.
Co-Authored-By: Steve C <diceroll123@gmail.com>
This was always modeling correctly, but not showing the message,
because Turbo doesn't handle anchors in redirect URLs the same way the
browser's full page loads do.
I forget why we had this as a `#` URL anyway to begin with. Use `?`
instead!
I haven't been running Prettier consistently on things in this project.
Now, it's quick-runnable, and I've got it on everything!
Also, I just think tabs are the right default for this kind of thing,
and I'm glad to get to switch over to it! (In `package.json`.)
I skipped this for a bit because I couldn't think of a simple way to
adapt this behavior to a web component + vanilla CSS setting, but then
I thought of CSS variables, and sat down and cranked this out!
I noticed the last row of the species faces required a scroll, I forget
when that happened! But I made some tweaks, most notably widened the
container from the normal 800px, so that on bigger screens everything
lays out and aligns nice, without requiring any scrolling of the face
container!
Oh oops, I forgot one of the kinds of restricted zones when refactoring
how we load search data in wardrobe-2020! This made most items with
restricted zones (like Be Gone items) not work correctly when you
search for them to add them to the item—though it *does* work correctly
when you reload the page or change the species, to get to load a
different way.
If something goes wrong, like the site goes down or has an intermittent
error, try a full pageload. That way, we're both retrying, and in a way
that gives the user more control and visibility into what's going on,
and what they can potentially do about it. (e.g. if there's a useful
error message, they will see it!)
I took this ordering from a specific place on Impress 2020, but I think
that was in a context where the pose mattered more? Here though, I'm
realizing that I'd rather show any known-unglitched pose than the happy
masc or whatever we semi-randomly chose.
instead of doing the random choice we do for most colors.
This is especially noticeable in cases where like, I'm looking at the
Elderlyboy Ogrin and like, it has *work* put into the masc eyes, and
them fem eyes are just the standard ones.
Used to have something like this long ago, now here's the latest
version!
This task can't run autonomously, it needs the human user to provide a
neologin cookie value. So, no cron for us! But we're cleaning up *years*
of lil guys in one swoop now :3
When playing with a Rainbow Pool syncing task, I noticed that error
handling wasn't working correctly for requests using `async-http`: if
the block raised an error, the `Sync` block would never return.
My suspicion is that this is because we were never reading or releasing
the request body.
In this change, I upgrade all the relevant gems for good measure, and
switch to using the response object yielded by the _block_, so we can
know it's being resource-managed correctly. Now, failures raise errors
as expected!
(I tested all these relevant service calls, too!)
Huh, this is a bit odd, I think we took this from Impress 2020's
`canonicalPetStateForBodyLoader` SQL query… but actually, it doesn't
really make sense? and `petStatesForPetTypeLoader` has a more sensible
ordering, and is the one the app uses in more ways. Maybe that's a
mistake we made back then, or a bug we fixed only in one place?
Anyway, this fixes why the item previews were like. using a LOT of
glitched pet states and I was like "dang did a lot of them break
recently?"
Nah we were just. not pulling the right ones lol
Oh right, forgot about this lol!
The specific effect on Impress 2020 where the button label expands is,
kinda hard to implement in normal CSS/JS, and so I'm not in the mood
and I'm settling for the `title` attribute lol
Oh right, I need the error indicator to be part of a container that
also contains the outfit viewer, to appear below it!
I was motivated because I realized I forgot the Customize More button
so now I'm building it lol
The main bottleneck for us is still just uploading the full source code,
there might be some clever option I'm not using for that yet of like,
compression or something? But this change did take the process down
from like 5 minutes to 3 minutes, so, works for me!
My immediate motivation is that I'm going to try turning on the
pipelining setting, to improve performance, and I'd like to have the
consistent place to put it! But also, I like standardizing our setup a
bit more, too
The loading indicator *should* fade in after two seconds, to avoid a
flash of a loading indicator when the page loads quickly - but in some
circumstances it wouldn't delay:
1. Visit an item page. (It delays correctly the first time!)
2. Click "Infinite Closet", then click a link to another item page.
3. The loading indicator appears immediately, because this time the
web component JS is already loaded, so the `outfit-layer` elements
enter `:state(loading)` *immediately*. The element starts at
`opacity: 1`, and the delay doesn't matter, because it was never at
anything else.
In this change, we have the `outfit-viewer` web component take on a
`:state(after-first-frame)`, after a `setTimeout(0)` resolves. That
enables the loading state CSS to *never* apply on the first frame, but
then sometimes kick in on the *second* frame, so that the element is
correctly perceived as "transitioning" from hidden to visible, and the
two-second delay will apply.
When I run `bin/deploy:precompile` on the previous version, I get an
error from libsass that `vw` and `vh` are incompatible units. I don't
get this error in development, only when compiling for production.
My inference is:
1. For the production build, Sass is trying to preprocess even non-SASS
files, maybe to help minify them?
2. In Sass, their `min()` existed before CSS's `min()`, so it's
treating it Like That, and returning a reasonable-in-some-cases-but-
not-here error that `min(100vw, 100vh)` can't be *precomputed*.
Anyway, wrapping it in `calc()` isn't a *problem*, and helps the Sass
compiler not try to precompute it, so. Okay!
https://github.com/sass/node-sass/issues/2815#issuecomment-575926329
We call it enough times on this page, and it *does* have a SQL query,
that I want to cache it! (Also I want to make it fewer species queries
if I can tbh…)
