Starting in Firefox 102, if a page title end with the site's domain name, Firefox uses the TLD as the file extension rather than .htm.

Reported on SUMO at https://support.mozilla.org/questions/1382070 -- unfortunately continues in Firefox 102.0.1 after shortcut fix (might be a related issue).

[Tracking Requested - why for this release]: Broken file extension when save page as.

I can reproduce this in Nightly104.0a11 103.0b5, 102.0.1 and 102.0esr Windows10 and Xubuntu22.04.

Regression window:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f2d91ac5f4d68c5ab3b9141dde1068881145f14&tochange=7ddfc8dd77aa1acb0000b8d35621e6429ef8a205

:enndeakin, since you are the author of the regressor, bug 1770683, could you take a look?
For more information, please visit auto_nag documentation.

This happens because we don't append anymore if we can't force an extension. https://hg.mozilla.org/mozilla-central/rev/7ddfc8dd77aa#l1.77

Too late for 102 non-esr at this point.

Is this better after bug 1773907 or no?

(In reply to :Gijs (he/him) from comment #5)

Is this better after bug 1773907 or no?

I checked on Version 103.0b8, Build ID 20220712185923, and the Save Page As issue (.htm not being added) does not seem to be fixed.

I can still reproduce, we end with a .com file and the folder with media contents. We're still not appending the htm extension.

Set release status flags based on info from the regressing bug 1770683

Gijs, should we try to get an owner to this bug and get it uplifted to an ESR minor release?

Perhaps we should just add text/html to the special-case list at https://searchfox.org/mozilla-central/rev/560b7b1b174ed36912b969eee0c1920f3c59bc56/uriloader/exthandler/nsExternalHelperAppService.cpp#3696

(In reply to Neil Deakin from comment #10)

Perhaps we should just add text/html to the special-case list at https://searchfox.org/mozilla-central/rev/560b7b1b174ed36912b969eee0c1920f3c59bc56/uriloader/exthandler/nsExternalHelperAppService.cpp#3696

I'm confused why this would help; the list there was originally at least about whether we end up with foo.txt.png vs foo.png, whereas this bug is about .html being lost completely. Can you elaborate?

(In reply to Pascal Chevrel:pascalc from comment #9)

Gijs, should we try to get an owner to this bug and get it uplifted to an ESR minor release?

I can add it to the quality foundation tracker but I can't promise anything right now in terms of how quickly we'll find an assignee.

I meant so that html is special cased as images are in nsExternalHelperAppService::ShouldModifyExtension so that html files with filenames that have an invalid extension will instead have the proper extension .html either replaced or appended.

(In reply to Neil Deakin from comment #12)

I meant so that html is special cased as images are in nsExternalHelperAppService::ShouldModifyExtension so that html files with filenames that have an invalid extension will instead have the proper extension .html either replaced or appended.

This seems reasonable to me. However, we will need to do the same for saving these files as plain text (another option when saving webpages), and forcing all text/plain things that people download to have .txt extensions will probably annoy lots of people (because .log and various programming source code files tend to get served with that mimetype, but want to keep their file extensions). So I think we might need/want to instead/additionally have/use a flag that forces extension correction, and pass it from the "save as" consumer. Or correct the filename after it's returned from the 'save as' dialog, or something. Does that make sense?

https://hg.mozilla.org/mozilla-central/rev/b3b857348f60

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit auto_nag documentation.

The patch landed in nightly and beta is affected.
:enndeakin, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Reproduced issue on 107.0b8 Firefox.
Issue is verified-fixed in 108.0a1 Nightly build: 2022-11-01-21-36-59-mozilla-central.

Comment on attachment 9298795 [details]
Bug 1778597, append valid extensions only when saving a page, r=gijs

Beta/Release Uplift Approval Request

• User impact if declined: Some web pages with certain titles are not saved with the html extension making them not directly openable afterwards.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should only affect when manually saving a file.
• String changes made/needed: none
• Is Android affected?: No

Comment on attachment 9298795 [details]
Bug 1778597, append valid extensions only when saving a page, r=gijs

Approved for 107.0b9

https://hg.mozilla.org/releases/mozilla-beta/rev/479cfc2c074e

Verified fixed in Firefox 107.0b9.

https://hg.mozilla.org/releases/mozilla-esr102/rev/cdab5f7deed1

Verified fixed also in 102.5.0esr on Windows 10, Mac 12 ARM and Ubuntu 20.