Firefox Release Notes "Developer Information" Link is Broken

Hi

Thank you for letting us know, but that now appears to be fixed.

Thanks for the response. Sorry for clicking "solved" too soon.

I still see the issue. Exact steps to reproduce:

1. Navigate to https://www.firefox.com/en-US/firefox/153.0/releasenotes/
2. Scroll to the "Developer" section
3. Click the Developer Information link (https://developer.mozilla.org/docs/Mozilla/Firefox/Releases/153 )
4. MDN displays a "Page not found" message with a list of search links to try, the first displayed being "153"
5. Click the "153" link (https://developer.mozilla.org/en-US/search?q=153 )
6. Click the link for "Firefox 153 release notes for developers (Stable)" in the list of results and the developer release notes are displayed

Notice the difference between the URL for the link in the Firefox release notes page and what works in MDN - the former's URL is missing the "en-US" which seems to be required for it to open in MDN and is not automatically added by the server.

Screenshot of message MDN displays when attempting to use the link in the standard Firefox release notes page is attached.

Let me know if I can provide any additional information.

No worries, that bit was not overlooked — it's deliberately published without hard–coded locale to let MDN serve you your accept–language preference. It seems working as expected for everyone; I intentionally run browsers with empty or malformed accept–language headers and still get this locale fixup to default en–US as expected there.

Do you only see this for v153 release notes or any of the previous versions exhibit the same?

I checked from a couple of CLI/headless locations and it all seems to work as expected so this would be interesting to understand what's different on your end:

--- ignore - updating this resulted in the new answer added below (?) ---

Sorry for the delayed response.

I checked the release notes pages for various versions and their one-offs going back to 148.0 before concluding that the issue is not limited to just the release notes page for 153.0 (at least for decently recent releases).

It is caused by the "/en-US/" not being included in the pathname for the link's URL, so I think that needs to be addressed in one way or another. MDN just does not handle the URL set in the release notes page and will complain and suggest as I described earlier on.

Manually adding "/en-US/" to the URL set for the clicked link in the address bar while the MDN 404 page is visible does result in the developer notes opening. This simple test goes with what I described regarding the use of the suggested search links MDN presents.

All normal steps such as clearing cache, cookies, etc. have been completed multiple times (manually and via the option to do so when quitting Firefox which I have had set for a while). I do not think I would be working with stale data.

I hope this helps.

Thanks jbr.. i can open an issue there and attach a HAR with a release notes page => MDN type session.

I have not heard of such an issue either. My locale/language is picked up by various other sites and utility pages such as CYT from EFF and Browserleaks.

On Mozilla domains (mozilla.com, firefox.com, extensionworkshop.com and even thunderbird.net (MZLA I know)), none of my extensions are enabled by choice or Firefox add-on restrictions, and ETP exceptions have been made for relevant domains and subdomains. Extensions include:

• uBO
• LocalCDN
• ClearURLs
• Canvas Blocker
• Consent-O-Matic

And the Dev release notes link seems to work fine in troubleshoot mode.

With that, as I prepare to open an issue, do you have an ideas why disabled extensions and/or ETP seemingly break such a link, but a vanilla instance of Firefox in troubleshoot mode does not? I'm just curious and don't think a GitHub issue is a good place to ask for an explainer, so if you have info or tips (other than removing my extensions since other sites I want to visit behave as I need them to). Or, is this a purely MDN dev type issue I need to wait on to learn more from?

Thanks again for pointing me a more meaningful direction. Voluntary follow-up explainer or no, I'm marking this as solved using your response. 🖖

Thanks, jbr. That is a good idea and I'll open that up.

In the meantime, you solved this and I appreciate that.

I have questions as well as all my extensions do not run on Mozilla and MZLA domains by choice and due to Firefox add-on restrictions (including extensionworkshop.com). And, ETP extensions have been setup for every mozilla.org and firefox.com subdomain I am aware of. So, in theory, what I've installed shouldn't be interfering with this as none of them are active on the pages.

The Dev release notes work as expected in Troubleshoot Mode, but surely I shouldn't be expected or forced to stop using extensions such as uBO, LocalCDN and a few other privacy-focused extensions. I'm often on VPN (Proton - paid), but that doesn't affect that proper behavior in Troubleshoot Mode.

So, I'll be interested in what can be done here short of removing extensions every time I need to click that Developer link in Firefox release notes!

FWIW, when testing in the EFF's CYT and Browserleaks (among many other sites), my language is picked up as "en-US" just fine, so this indeed a strange issue with a Mozilla browser having problems with some Mozilla pages.

At any rate, thanks again. 🖖

I have questions as well as all my extensions do not run on Mozilla and MZLA domains by choice and due to Firefox add-on restrictions (including extensionworkshop.com). And, ETP extensions have been setup for every mozilla.org and firefox.com subdomain I am aware of. So, in theory, what I've installed shouldn't be interfering with this as none of them are active on the pages.

https://support.mozilla.org/en-US/kb/quarantined-domains

Only accounts, login, addon and some support surfaces that internally have elevated permissions (like to run browser functions, or pull browser data) are excluded from addon access — MDN not being one of them.

I don't have an answer how you can tamper with their requests/responses in a way to end up with a broken result, but the reduced test that shows it passing:

~ $ http -v HEAD https://developer.mozilla.org/docs/Mozilla/Firefox/Releases/153
HEAD /docs/Mozilla/Firefox/Releases/153 HTTP/1.1
Accept: */*
Host: developer.mozilla.org

HTTP/1.1 302 Found
Vary: Accept
X-Cache: MISS, MISS, MISS
X-Cache-Hits: 0, 0, 0
X-Served-By: cache-BFI, cache-CHI
location: /en-US/docs/Mozilla/Firefox/Releases/153

so that's a perfectly served redirection ^^ that it's designed to do. Maybe your HAR will show some intentional interfering with the traffic to the extent it forces the host to respond even with a resource it doesn't have. 🤷

You can see what request+response is used for your render in the Network pane of devtools, which is something that might be useful to the MDN maintainers as well, if that's an edge case interesting enough to track down to close the gap.