1356328 - Icons font 404s

Status: RESOLVED FIXED

(Webtools Graveyard :: DXR, enhancement)

Description

[Erik Rose [:erik][:erikrose]]

Since we started cachebusting the static assets (see HashedStatics in app.py), we've been 404ing on fetching icons.woff, icons.ttf, etc., because they're loaded from dxr.css, which doesn't use url_for()--and perhaps it cannot.

Comment 1

[:Atoll]

Is this still happening? I don't see icons.woff/icons.ttf fetches occurring from my Firefox instance to DXR at all now.

Comment 2

[Erik Rose [:erik][:erikrose]]

They're still happening--but, interestingly, only in certain places. (Do a command-R or even a command-shift-R, and you should see them in the Network pane of the dev tools. Make sure you don't have any filters on.) dxr.css loads the fonts just fine, but filter(.0b15c5d8).css gets 404s. It looks like the hashed names are getting subbed into dxr.css but not filter.css. Interesting!

Curious, I took a look at the difference between the files, and it turns out filter.css appends some querystrings to the CSS, probably an early attempt at cachebusting from our front-end person. Removing that, the 404s go away.

Comment 3

[:Atoll]

I was going to ask if you knew who the maintainer is, but it turns out you're the maintainer. Nifty! Let me know if I can be of any service helping ship a fix.

Comment 4

[[github robot]]

Commit pushed to master at https://github.com/mozilla/dxr

https://github.com/mozilla/dxr/commit/7684609cf255ef00f060b3307ac2356c16828c18
Keep fonts from 404ing when fetched from filter.css. Fixes bug 1356328.

The cachebusting was failing to find the hashed version of the filename because the static_manifest doesn't include those querystrings. The querystrings don't do anything anyway, so I removed them.

Comment 5

[Erik Rose [:erik][:erikrose]]

DXR is on the far, far back burner right now, as Mozilla decides what direction to go for analysis in the future, so I'm probably most accurately called the "most recent maintainer" at this point.