I have an chrome XHTML file with a script that should be deferred. It is to be loaded inside a browser element (because Thunderbird, we're weird). The script is not deferred but runs immediately.

It works fine if the file has the .html extension but not if the file has a .xhtml extension.

It works fine if the file has a file:// URL but not a chrome:// URL. This is also the case if I build Firefox with the file, so it's not something weird that Thunderbird is doing.

In fact I don't think it's working for any chrome XHTML documents, including messenger.xhtml where I've been told it's supposed to be working. Add console.log(document.body); to the top level of any of the scripts loaded there and null is logged.

Any script that uses the XUL prototype cache won't handle defer correctly.

What is the use case for defer in chrome context?

Maybe I have wrong assumptions about the chrome context, but the use case is not different from the web use case: basically performance gain compared to not having defer + being able to rely on the elements of the markup to be directly available to the scripts.
The alternative (which I've seen in chrome code as well) is putting the scripts before end of the document but semantically that's not nice.

Being able to prototype from file:// and rely on it working the same way for chrome:// would be good for productivity.

Emilio, Olli: is this something that would be easy to fix, or not easy at all?

I guess not super hard to implement, but not trivial either. And I still don't quite understand the use case.
If the script gets put to XUL prototype cache, loading it is very fast and it is stored in a bytecode format.

Do we have some examples when using defer would speed up thing?
And if "being able to rely on the elements of the markup to be directly available to the scripts" is important, wrap the code in the script inside a function and call it in load event listener or so?

There are of course workarounds like that.

I was using defer on the theory that it's usually best practice.
If you're saying there should be no performance gain for chrome, I guess it's not so bad though still a slight annoyance for developers who would expect it to work the same between chrome and file.

Is there something we can do about this?
Maybe following the suggestion in comment6?

Not something I would know how how to fix at least without guidance.

I don't care that it doesn't work other than the fact that it should work. It's not affecting anything, just something to be aware of.