On Fri Oct 20 16:29:39 2023 +0000, Jacek Caban wrote:
To be honest I'm not thrilled with the idea of doing full load like that. I was hoping for something "lighter". Sadly, I don't see a good alternative to do that in Gecko in a way fully compatible with MSHTML. I'm not sure how much we really care about this thing being exactly compatible, but if we do, I guess we need something like that... FWIW, one alternative would be to do `document.open(); document.close();`. It would work only on HTML documents (no SVG/XML equivalent) and it replaces a document instead of creating a new one, so it's not really a good fit. BTW, it 's hard to judge without seeing the code, but find it surprising that this thing matters for MessageEvent.source.
Yeah I tried a bunch of things and arrived to this one. I agree something lighter would be nicer, but I'm not sure if it's that bad since it happens on the document obj release (which is typically not that often, since it's the "root"), and we're already doing some other potential heavy things here, such as forcing a cycle collection. I haven't tested but this *might* also help with the gecko nsevents that hold refs (unsure if they're processed in sync bindings, I see it does have a "hidden" message loop in urlmon) since it's navigating away, so at least Gecko is "aware" of it.
Also what I meant is that at least I found it useful to test some behaviors of things required by MessageEvent.source, not itself; mostly related to ScriptHosts (that's how I found out about it in the first place), and of course we need SciptHosts fixed to be able to implement the CommandTargets that are ultimately needed for MessageEvent.source.
One weird behavior is, for example, "moving" the script hosts if they're on the initial (blank) window—this can happen if you obtain it via CommandTarget *before* loading the document via message pump, and it matches on the loaded document afterwards (but not after that).