After bec4223 JS isn't loaded into window.openDialog

[dominichayesferen]

As of bec4223, JS that loaded fine in the commit before in windows spawned by window.openDialog no longer have that JS, leading to errors like these:

Even though, as clearly shown by https://github.com/angelbruni/Geckium/blob/archive/pre-mpl2/Profile%20Folder/chrome/JS/GeckiumMaterial.uc.js#L46, the function has no reason to cease existing per documentation including changes.

Running the exact same URI as the dialog's target URI in the browser instead results in the JS loading as expected in every other case but with openDialog.

[MrOtherGuy]

Yeah, this has been quite annoying / interesting to deal with. Windows opened via window.openDialog() seem to be loaded differently than those simply using window.open() and there doesn't appear to be a good way to detect the created window's "dialoginess" after the fact - or if there is, I haven't found one. This then causes scripts to not be loaded into dialog windows.

So in 8da9268f7afcbf5d438b099e976fe8aa46a111d0 I added what is IMO quite a hacky way to detect dialog-likeness, which simply uses window.toolbar.visible property lookup as a proxy. I have been testing this for quite some time now and haven't really run into problems with it, so I suppose its okay for the time being. But it's entirely possible that it doesn't work for every kind of situation you could run into.

Still, I'm interested if this solves this particular issue.

[dominichayesferen]

It does solve it, however I have noticed some other differences between it and a standard popup:

1. openDialog windows have '<window' instead of '<html' as their beginning opener
2. windowtype isn't 'navigator:browser' but rather whatever the HTML dictates as 'windowtype'
3. role="dialog" is inside the opening '<window' line
4. chromehidden="menubar toolbar location directories status extrachrome "
5. containertype="window", which doesn't exist in the popup.

whether those differences are unique enough, idk for sure

[MrOtherGuy]

Well that's good to hear.

If I recall, we can't really use DOM attributes here, because we need them before the document which describes that DOM is loaded - although in case of dialogs the initial document can be the actual document. Regardless, the only thing that we can rely on to exist is the newly created window global object which luckily does have the toolbar property that we can use to check if it's "eventually going to be visible". If the toolbar prop doesn't exist then the code currently behaves as if the window is a dialog, but I'm not actually sure if that ever happens.