1804665 - Implement nsIClassInfo on nsDocshell so we stop having to QI it to tons of different things in JS

Status: NEW

(Core :: DOM: Navigation, task)

Description

[:Gijs (out for now; he/him)]

Besides being repetitive, the QIs are somewhat footgunny, for a few reasons:

0. From a frontend PoV it's tricky to work out what you can do/determine from the docshell directly in an interactive JS context like the debugger or console, because you have to know (a) that you could QI it to find other functionality and (b) all the things you could QI it to.
1. Presence of methods/properties on an object in e.g. the debugger at some specific point, or in the browser console, or... is no guarantee the JS wrapper will have those properties at the point where you write specific code that wants to use it. This leads to surprises, especially for people unfamiliar with QueryInterface in the first place (which at this point is probably more than half the frontend team - COM isn't a common pattern in modern code outside of Firefox, and this is a strange concept to them; most other things we interact with are exposed through Services or webidl, which largely bypass/hide the XPCOM machinery).
2. even for people who are reasonably familiar with (0) and (1), the fact that the JS wrapper that reflects these interfaces can get GC'd and as a result, re-fetching the docshell through a webidl interface or otherwise will result in a new wrapper, which won't have the properties/methods that were previously exposed as a result of the QI. With the advent of async/await, the GC can happen at "inopportune" moments, and the result is confusing for frontend folks without a detailed understanding of the mechanics of XPCOM/xpconnect and their interaction with the GC.

Comment 1

[Kris Maglione [:kmag]]

This is probably a good idea, but we also probably don't want to automatically expose all of the interface it implements, only the ones that JS actually actively uses. It might be good to add an ESLint rule to try to forbid QIing objects that look like DocShells so we don't miss any new ones.

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

COM isn't a common pattern in modern code outside of Firefox, and this is a strange concept to them

I mean, XPCOM is basically a clone of MSCOM, which is quite widely used by Windows developers... But nevertheless, I agree that hiding it as much as possible, at least from the JS side of things, would be an objective good.