DOMParser is not defined in Zotero 7

[David Hoff-Vanoni]

I'm working on a bootstrapped plugin in Zotero 7 (7.0.0-dev.6+bb5fe45f3), and I'm having trouble creating a DOMParser as described in the Zotero 7 documentation.

If I try to use `new DOMParser()` from my bootstrap code, I encounter the following error:

ReferenceError: DOMParser is not defined

I've been able to get it to work using `new (Zotero.getMainWindow().DOMParser)()`, but I'm not sure if that's the recommended approach.

Is there something special I need to do to get access to DOMParser as documented?

Thanks!

[Dan Stillman]

On 2/8/23 2:32 AM, David Hoff-Vanoni wrote:
> I'm working on a bootstrapped plugin in Zotero 7
> (7.0.0-dev.6+bb5fe45f3), and I'm having trouble creating a DOMParser
> as described in the Zotero 7 documentation.
>
> If I try to use `new DOMParser()` from my bootstrap code, I encounter
> the following error:
> ReferenceError: DOMParser is not defined

Fixed in the latest build — thanks.

- Dan

[XY Wong]

I wrote a `getDOMParser`[1] in the toolkit, which works on both Zotero 6 & 7.

Besides the DOMParser, the environment in which the plugin runs lacks many, many global variables that are available in a browser window environment. I would strongly recommend you try the plugin-toolkit package with `getGlobal`[2] to get any variable you want with a type hint.

[1] zotero-plugin-toolkit/zotero-plugin-toolkit.basictool.getdomparser.md at master · windingwind/zotero-plugin-toolkit (github.com)

[2] zotero-plugin-toolkit/zotero-plugin-toolkit.basictool.getglobal_12.md at master · windingwind/zotero-plugin-toolkit (github.com)

[Dan Stillman]

On 2/9/23 9:47 AM, XY Wong wrote:
> I wrote a `getDOMParser`[1] in the toolkit, which works on both Zotero
> 6 & 7.
>
> Besides the DOMParser, the environment in which the plugin runs lacks
> many, many global variables that are available in a browser window
> environment. I would strongly recommend you try the plugin-toolkit
> package with `getGlobal`[2] to get any variable you want with a type hint.

We appreciate your efforts to make things easier for plugin developers,
but if there's a problem in the default environment, please just report
that. People should be able to create plugins without becoming
permanently dependent on a third-party API.

[XY Wong]

I will.

The lib is open source, if people don't want to rely on it, they can directly copy code from it.

Looking for a solution to a certain realization, like virtualized table, item box, item tree, etc. is difficult. We have to dive into the source code of different repositories and these realizations are not extensive in most cases. And once the Zotero API/platform API changes, we have to adapt to these changes by ourselves. I would wish the toolkit can become a first-party API in the future, a group of APIs designed for plugin development that some other open-source communities have.

Thanks for your support and kind help, Dan!

[Emiliano Heyns]

Would (absense of) 6/7 compatibility shims fall under the category of "problems in the default environment"?

[XY Wong]

I suppose missing some variables from the main window in the plugin's env is expected behavior with bootstrapped sandbox. It's acceptable for me to bind these missing variables to plugin global this manually.

The nsIDOMParser -> DOMParser, createXULElement, and other compatibility issues are listed in dev:zotero 7 for developers [Zotero Documentation]

[Dan Stillman]

On 2/10/23 9:43 AM, Emiliano Heyns wrote:
> Would (absense of) 6/7 compatibility shims fall under the category of
> "problems in the default environment"?

It depends.

I was mainly talking about Zotero 7 — if a plugin targeting only Zotero
7 needs to use third-party code for basic functionality, that's a
problem, and we really want to avoid a situation where all plugins start
depending on a third-party API that we can't provide support for, that
may not have future core changes in mind, and that may not have the
longevity of the official project. So if something can't be done easily
in Zotero 7, we want people to let us know so we can improve the default
experience.

For Zotero 6, we haven't added any compatibility shims for Zotero 7 APIs
because a plugin developer couldn't necessarily count on a user being on
a new-enough Zotero 6 version to have the shim, whereas if they
explicitly handle both APIs or bundle a compatibility shim, they'd know
it would work. For many existing plugins, compatibility might be as
simple as leaving in existing code behind some
`Zotero.platformMajorVersion < 102` checks.

That said, the vast majority of Zotero users do upgrade immediately, and
we don't provide official support for older versions anyway, so if a
plugin developer is comfortable just showing an error if someone is on
an outdated Zotero 6 version, that seems totally reasonable to me. So if
there's general interest in our incorporating some compatibility shims
to make the transition easier, we'll happily take patches for that. (I
don't know that it makes sense for us to spend time developing such
shims at the expense of actually finishing Zotero 7.)

But a shim is a shim — it implements a newer API in an older version.
And that's not what plugin-toolkit is. XY Wong and others have created
some truly incredible plugins, but I think it would be a real mistake
for other unaffiliated developers to start filling their codebases with
third-party abstractions on top of things that there are already
perfectly standard ways of doing in Zotero (e.g., `FilePickerHelper` vs.
`new FilePicker`, or `ui.createElement` instead of native DOM methods).
I understand that it can be hard to find the best ways to do things in
200K or so lines of Zotero code, and that some things (particularly
Mozilla-isms) that we on the core team are quite used to could be made
easier for outsiders, but I think effort would be better spent improving
documentation, proposing/implementing new official APIs, perhaps adding
TypeScript definitions, etc., rather than creating unofficial
dependencies. This is something we may be able to put some resources
towards, but the first step would be feedback on the places where people
are having trouble.

- Dan

[Dan Stillman]

On 2/10/23 9:11 PM, XY Wong wrote:
> I suppose missing some variables from the main window in the plugin's
> env is expected behavior with bootstrapped sandbox.

It's not, necessarily — that's why you should report it. E.g., DOMParser
was just missing. But plugins' default scope isn't a window, and it's
not appropriate for everything on a specific window to be available
globally, because there won't always be a single main window in Zotero.

This is part of what I mean about a third-party API not necessarily
considering future core changes in Zotero. There are reasons certain
Zotero or Mozilla APIs work the way they do, with some being in window
scope or requiring a `window` parameter and some not.

[XY Wong]

Hi, Dan,

We are also working on a typescript definition package, https://github.com/windingwind/zotero-types, and have covered most of the commonly used (and some more) APIs of the Zotero source code. I am glad to know there will be an official type definition.

We write the toolkit for ourselves. As long as we still maintain the plugins, we will maintain the toolkit. The modules of the toolkit are isolated from each other, so it would not be too difficult if we reach a time when we must remove the toolkit from our code.

We write these APIs because they are really useful. Take the `createElement` as an example, it creates element(s) in JS, no matter if it's HTML or XUL, if it runs on Zotero 6 or 7, and these elements can be removed automatically, along with other registered modules by one call `unregisterAll` when plugin exits. Asking the plugin developer to remove all these tons of elements, as well as other modules (e.g. item tree) one by one manually is anti-humanity I believe.

Besides, third-party packages roots in the JavaScript culture. If a plugin developer is expert enough, ze could decide whether to use the toolkit (and other third-party packages); if not, I would rather believe it would be nearly impossible for zirself to implement what the toolkit provides.

[XY Wong]

I've changed the backend of Filepicker in the toolkit to Zotero's built-in one. Thank Dan for pointing this out.