bug 1766761 introduced an ability to redirect the JSM imports to ESM imports when the JSM file is already ESM-ified but the consumer still uses JSM.

CheckForBrokenChromeURL hits crash on automation because of the JSM file is missing.

Given this is expected case, the check should be suppressed.

RecordZeroLengthEvent might also need to be suppressed.

:dragana, can I have your opinion here?

I'm trying to add a new LoadInfo field that suppresses the check, does it sound right?
https://hg.mozilla.org/try/rev/7c17802848d7f59e8893ea3b68c68ff74bea0841

is there better way to exclude JSMs from the check?
Here, JSM means any file that ends with *.jsm, *.jsm.js, or *.js, loaded by mozJSModuleLoader

Also, is there any way to check if a file pointed by resource:// URI or chrome:// URI exists, without actually opening the channel ?
If that's possible, mozJSModuleLoader::TryFallbackToImportESModule can be performed before hitting the "file not found" error.

I should've explained the details:

To make the ESMification migration easier, bug 1766761 introduced a feature that redirects

ChromeUtils.import("resource://gre/modules/Services.jsm");

to

ChromeUtils.importESModule("resource://gre/modules/Services.sys.mjs");

The purpose here is to make it possible to migrate the JSM file, without touching all consumers at the same time.
The consumers here includes the out-of-tree consumers such as extensions, so migrating all consumers at once is impossible.

The algorithm used in the bug 1766761 patch is the following:

1. When ChromeUtils.import is called with *.jsm or *.js or *.jsm.js URI, try loading the file, as usual
2. If the load is successful:
   1. Return the exports object, as usual
3. Else:
   1. Try loading ES module, with the URI replacing .jsm or *.js or *.jsm.js suffix to .sys.mjs suffix
   2. If the load is successful:
      1. Return the module namespace object
   3. Else:
      1. Throw error that says no module is found, as usual

So, the load failure is expected to happen at the step 1.

The other option was to have a static list of known-to-be-ESMified URLs and immediately redirect if the imported URL matches,
but I didn't choose this because it can be difficult to keep the list up to date.

We could use both approach, so that known case can be redirected immediately, and overlooked case can be redirected after failure, but that doesn't solve the issue in this bug.

(In reply to Tooru Fujisawa [:arai] from comment #4)

The other option was to have a static list of known-to-be-ESMified URLs and immediately redirect if the imported URL matches,
but I didn't choose this because it can be difficult to keep the list up to date.

We could use both approach, so that known case can be redirected immediately, and overlooked case can be redirected after failure, but that doesn't solve the issue in this bug.

I'm investigating the performance impact of the current and the above options in bug 1777673.

Depends on D150874

(In reply to Tooru Fujisawa [:arai] from comment #5)

(In reply to Tooru Fujisawa [:arai] from comment #4)

The other option was to have a static list of known-to-be-ESMified URLs and immediately redirect if the imported URL matches,
but I didn't choose this because it can be difficult to keep the list up to date.

We could use both approach, so that known case can be redirected immediately, and overlooked case can be redirected after failure, but that doesn't solve the issue in this bug.

I'm investigating the performance impact of the current and the above options in bug 1777673.

with bug 1777694 patch applied, there's no notable performance impact with the above "redirect after failure" way (see bug 1777673)

Currently there are 3 options:

• (a) Keep using the current algorithm in comment #4. So, load .jsm, and retry with .sys.mjs if not found
  • This requires the attached patch to suppress the error handling for .jsm
• (b) Use a static list for redirecting .jsm to .sys.mjs (investigating in bug 1778042), and maintain the list with the command in bug 1776870 patch
• (c) perhaps mix of (a) and (b), to cover most case in (b) and use (a) as fallback

So far (a) and (b) has no significant performance difference (bug 1777673)

Discussed on chat.

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