Pale Moon automatically requesting CSS and JS files after JSON responses. Bug? Topic is solved

[BenFenner]

When Pale Moon gets a JSON response back from a web URL, it renders the JSON as text (expected) but then automatically requests two additional files from the domain:

Code: Select all

/css/main.css
/lib/require.js

I've created a test file on my domain so you can see this in action. (It was difficult to find an example otherwise, but you're welcome to find somewhere else to test if you can.)

Steps to reproduce:
1) Open a new browser tab in Pale Moon.
2) Press F12 to open the dev tools in the newly opened tab.
3) Click the "Network" button in the dev tools to navigate to the Network dev panel.
4) Visit this test URL: https://www.sr20-forum.com/test_json_endpoint.php
5) Notice the browser window shows the JSON response.
6) Notice the network tab shows a 200 response, and the raw response header shows content-type: application/json.
7) Notice the two additional files mentioned above are automatically requested by the browser and fail with 404 responses (because those files don't exist on the domain).



For full context, the complete contents of test_json_endpoint.php are:

Code: Select all

<?php

  $data = array();
  $data['name'] = 'Testing Pale Moon and how it may automatically ask for /css/main.css and /lib/require.js when being fed a JSON reply.';

  header('Content-Type: application/json');
  echo json_encode($data);

I've tested with Waterfox and the only additional automatic request sent is for /favicon.ico.
Funnily enough, Waterfox's request for the favicon and it being blocked by my CSP are both Firefox bugs: https://stackoverflow.com/questions/698 ... on-firefox .
I assume Chromium and other similar browsers don't ask for these files, but let me go check...
Edit: Ungoogled Chromium does not ask for the CSS or JS file, just incorrectly (IMO) asks for /favicon.ico.

Is there a reason Pale Moon is automatically tacking on extra requests? This doesn't seem to make any sense to me, and was very surprising when I noticed it. My web site showed logged requests from my IP that I absolutely did not initiate, and I thought I'd been compromised for a bit there until I figured it out.

I guess it could be one of my few extensions doing this... I'm happy to provide more details, but I suspect it will be an easy thing to reproduce for everyone here.

[UCyborg]

Wow, this is bizarre, can confirm with clean profile.

Edit: If you turn off security.csp.enable in about:config, then these requests aren't made. Firefox 52.9.0 doesn't make these requests. Some version of Basilisk from 2024 does. Presumably it's a platform thing.

[Moonchild]

Yeah that's a bug. The two requests are for the builtin devtools json viewer and for some reason it pipes them to the remote. I'm guessing it's got something to do with a php request resulting in a json response...
e.g. when asking for a json directly, like from https://testserver.palemoon.org/json/te ... point.json it does it correctly.

Even weirder... if I don't accept gzip encoding in the request header, there's no problem either.

[BenFenner]

when asking for a json directly, like from https://testserver.palemoon.org/json/te ... point.json it does it correctly.

My guess is because the response headers are:

Code: Select all

HTTP/2.0 304 Not Modified
X-Firefox-Spdy: h2
date: Sat, 13 Jun 2026 17:32:01 GMT
etag: "6a2d9190-84"
last-modified: Sat, 13 Jun 2026 17:21:20 GMT
server: nginx

Which do not include content-type: application/json. I would guess that response header value is important?


Edit: Sorry! That was after a soft refresh after opening dev tools. The actual response headers are:

Code: Select all

HTTP/2.0 200 OK
X-Firefox-Spdy: h2
accept-ranges: bytes
content-length: 132
content-type: application/json
date: Sat, 13 Jun 2026 17:37:46 GMT
etag: "6a2d9190-84"
last-modified: Sat, 13 Jun 2026 17:21:20 GMT
server: nginx

So it seems the content-type: application/json pairing is present and the extra files are not requested. Very interesting...

And for comparison, here are the response headers from my site that do encounter the problem:

Code: Select all

HTTP/2.0 200 OK
X-Firefox-Spdy: h2
content-encoding: gzip
content-security-policy: default-src 'self'; base-uri 'self'; object-src 'none'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: http: https:; frame-src 'self' https://www.youtube-nocookie.com;
content-type: application/json
date: Sat, 13 Jun 2026 17:40:35 GMT
referrer-policy: strict-origin-when-cross-origin
server: Apache
strict-transport-security: max-age=31536000
vary: Accept-Encoding
via: e13s
x-content-type-options: nosniff
x-frame-options: DENY

[Moonchild]

Hard refresh will do a new full request. (Alternatively go to the address bar and press enter for a fresh navigation)

[BenFenner]

Well, if there is anything else I can do to help, let me know.

Have fun with this one!

(I will leave my example up for a while or until it is no longer needed. Hopefully I can take it down in a few weeks or so.)

[Moonchild]

Filed Issue #3122 (UXP)

Please do leave the json endpoint test up for a little while.

[Moonchild]

This should now be fixed on the master branch -- I'll include it in the next release of Pale Moon. Since this is a potential issue with unwanted loading of foreign content I'll uplift it to be in the next minor update.

[BenFenner]

\m/

[BenFenner]

To close the loop on this, all looks good now with the release of Pale Moon v34.3.1 so I've removed the test file from my server.

If only they could all be this easy.