ES6 module instantiation error: module record has unexpected status

RESOLVED FIXED in Firefox 65

Status

()

RESOLVED FIXED
7 months ago
3 months ago

People

(Reporter: james_mozilla, Assigned: anba)

Tracking

61 Branch
mozilla65
Points:
---

Firefox Tracking Flags

(firefox62 wontfix, firefox63 wontfix, firefox64 wontfix, firefox65 fixed)

Details

Attachments

(3 attachments)

(Reporter)

Description

7 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3534.4 Safari/537.36

Steps to reproduce:

Navigate to http://spispopd.lol/doomsw.html



Actual results:

A blank page renders, with the following error in the developer console:

module record has unexpected status
CallModuleResolveHook self-hosted:3926:9
getExportedNames self-hosted:3954:31
GetModuleNamespace self-hosted:4042:13
ModuleDeclarationEnvironmentSetup self-hosted:4186:29
InnerModuleInstantiation self-hosted:4156:5
InnerModuleInstantiation self-hosted:4145:17
InnerModuleInstantiation self-hosted:4145:17
InnerModuleInstantiation self-hosted:4145:17
declarationInstantiation self-hosted:4109:9 




Expected results:

A WebGL canvas should initialize, initially rendering a blue skybox with clouds. After downloading the data files, the first level of Doom shareware should render.
(Reporter)

Comment 1

7 months ago

Comment 2

7 months ago
Hi, I reproduced this issue in Nightly 64.0a1 (2018-09-05).
Status: UNCONFIRMED → NEW
status-firefox62: --- → affected
status-firefox63: --- → affected
status-firefox64: --- → affected
Component: Untriaged → Canvas: WebGL
Ever confirmed: true
Product: Firefox → Core
(Reporter)

Comment 3

7 months ago
I suspect this bug is actually an ES6 module dependency resolution issue or something related to Web Components, rather than a WebGL issue.
Component: Canvas: WebGL → JavaScript Engine
(Reporter)

Comment 4

4 months ago
I've done some work to isolate this problem, it turns out it's due to the way I'm using imports in combination with 'export * from "./foo.js";' to build a library.  Here's a simple form of the problem, live version is online at https://baicoianu.com/~bai/es6moduletest/foo.html :

foo.html:
  <html>
    <body>
      <script type="module">
        import * as Foo from './foo.js';

        let thing1 = new Foo.Class1(),
            thing2 = new Foo.Class2();
      </script>
    </body>
  </html>

foo.js:
  export * from './class1.js';
  export * from './class2.js';

class1.js:
  import * as Foo from './foo.js';

  export class Class1 {
    constructor() {
      document.body.innerHTML += 'class1 created';
      // Real world example would make use of the other classes that make up the Foo namespace
    }
  }

class2.js:
  import * as Foo from './foo.js';

  export class Class2 {
    constructor() {
      document.body.innerHTML += 'class2 created';
      // Real world example would make use of the other classes that make up the Foo namespace
    }
  }


Expected result is that foo.js would export a namespace "Foo" consisting of all the classes which make up the library, and that those classes would in turn be able to use the Foo namespace and all of the classes defined within.  Instead, it seems that Firefox is seeing this as a circular dependency and failing to resolve them.  Chrome and Edge both handle this case with no errors.
(Assignee)

Comment 5

4 months ago
ModuleGetExportedNames needs to be allowed to resolve uninstantiated module records. I've added more details when exactly this case can happen in the test file.
Assignee: nobody → andrebargull
Status: NEW → ASSIGNED
Attachment #9029580 - Flags: review?(jcoppeard)
(Assignee)

Comment 6

4 months ago
(In reply to James Baicoianu from comment #4)
> I've done some work to isolate this problem, it turns out it's due to the
> way I'm using imports in combination with 'export * from "./foo.js";' to
> build a library.

Thanks a ton for the reduced test case, it was a real help to find and fix this bug! :-)
Comment on attachment 9029580 [details] [diff] [review]
bug1488117.patch

Review of attachment 9029580 [details] [diff] [review]:
-----------------------------------------------------------------

OK that makes sense.  Thanks for fixing this.
Attachment #9029580 - Flags: review?(jcoppeard) → review+

Comment 9

4 months ago
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/62cb0a02ae13
Export* modules can be uninstantiated when ModuleGetExportedNames is called. r=jonco
Keywords: checkin-needed

Comment 10

4 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/62cb0a02ae13
Status: ASSIGNED → RESOLVED
Last Resolved: 4 months ago
status-firefox65: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
status-firefox62: affected → wontfix
status-firefox63: affected → wontfix
status-firefox64: affected → wontfix
You need to log in before you can comment on or make changes to this bug.