@brendandahl Now that you're hacking in Positron, perhaps you can review this change? It's a prerequisite to supporting the sample browser app.
Currently, a ModuleLoader is created for a BrowserWindow when the process global is accessed in the window. That's fine for the "hello world" app, which accesses that global. But the sample browser doesn't access process, and process is actually lazily instantiated, which means that we don't currently create a ModuleLoader for the sample browser's BrowserWindow.
And since the <webview> element is initialized by Electron's web-view.js module, which gets loaded by the ModuleLoader, that means there's no <webview> in the sample browser. Making the process global create the ModuleLoader was always a hack that we needed to fix eventually; it just so happens that eventually is now.
This branch instead creates the ModuleLoader on document-element-inserted, which is before the document's script is executed (and any <webview> elements inserted) and unconditional. Along the way, it fixes up the WebIDL binding for the process global in three ways:
Removes the [Throws] attribute from the binding and atomBinding method declarations, per https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Throws, which says, "For interfaces flagged with [JSImplementation], all methods and properties are assumed to be able to throw and do not need to be flagged as throwing."
Recreates the error thrown by process.binding, per the comments in the code about needing to do that in order to preserve its message.
Defines process.type in the WebIDL binding, as it can be called via the binding.
@brendandahl Now that you're hacking in Positron, perhaps you can review this change? It's a prerequisite to supporting the sample browser app.
Currently, a ModuleLoader is created for a BrowserWindow when the process global is accessed in the window. That's fine for the "hello world" app, which accesses that global. But the sample browser doesn't access process, and process is actually lazily instantiated, which means that we don't currently create a ModuleLoader for the sample browser's BrowserWindow.
And since the <webview> element is initialized by Electron's web-view.js module, which gets loaded by the ModuleLoader, that means there's no <webview> in the sample browser. Making the process global create the ModuleLoader was always a hack that we needed to fix eventually; it just so happens that eventually is now.
This branch instead creates the ModuleLoader on
document-element-inserted, which is before the document's script is executed (and any <webview> elements inserted) and unconditional. Along the way, it fixes up the WebIDL binding for the process global in three ways:[Throws]attribute from the binding and atomBinding method declarations, per https://developer.mozilla.org/en-US/docs/Mozilla/WebIDL_bindings#Throws, which says, "For interfaces flagged with [JSImplementation], all methods and properties are assumed to be able to throw and do not need to be flagged as throwing."