User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:105.0) Gecko/20100101 Firefox/105.0

Steps to reproduce:

1. Visit https://archiveofourown.org/works/40037295/chapters/100267341
2. Press Ctrl+S

(Tested on both a Flatpak build with my usual profile and and a freshly downloaded getfirefox.com 64-bit Linux tarball with a clean profile, with the latter being tested both with the KDE file picker via export GTK_USE_PORTAL=1 and the GTK file picker via unset GTK_USE_PORTAL.)

Actual results:

Under all test conditions, the save dialog opens with a filename lacking any extension (or, in the worst case, a site where the page title ends with a .com domain leading to a saved HTML file that shows up as a MS-DOS binary in any file manager that lets the extension be the final arbiter of displayed file type.)

Expected results:

The save dialog should append the .html extension like I remember it used to reliably do and like it still does for pages like https://www.fanfiction.net/s/7613196/1/The-Pureblood-Pretense.

(Yes, I did choose that reproducer link because the same work of fiction was posted to one site that exhibits the problem and one that doesn't.)

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

I doubt adding the .html to the suggested filename to feed to a platform common dialog is part of the DOM component, but I wouldn't know where it would belong to.

Reproducible on Ubuntu 20.04, setting the flags accordingly.
Going to run mozregression to try and find the regressor asap.

Thanks for reporting!

Mozregression returned the following pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=bc528e3ae14e5356a276aee2d2e526accb755e5b&tochange=7b6293ef312a75ba082ce9dedcbce636448020dd

I suspect Bug 1770683 to be the culprit.