zotero 8 beta coming soon — plugin updates required

[Dan Stillman]

We'll soon be releasing a beta version of Zotero that's built from Firefox 140 ESR instead of Firefox 115 ESR (Zotero 7.0) or Firefox 128 ESR (the "Zotero 7.1" beta). This beta will become Zotero 8, which we plan to release later this year.

All plugins will need to be tested for compatibility and updated as necessary. We don't expect most plugins to require significant changes.

After testing/updating, plugins will need to be updated to declare "8.0.*" for strict_max_version. If your plugin is already compatible, you should be able to update strict_max_version in your update manifest without releasing a new version with an updated manifest.json. Be sure to update manifest.json for your next release.

We're planning to push out a Firefox 140–based beta build on Monday, July 28, 2025.

See Zotero 8 for Developers for the platform changes we're aware of. You can install a Firefox 140-based dev build from that page for testing your plugins.

As always, you can use Zotero.platformMajorVersion to test whether a Zotero build is based on Firefox 115, 128, or 140, which will allow you to update your plugin in advance of the Zotero beta that includes these changes.

Let us know if you have any questions or if you have any trouble updating your plugins.

- Dan

[iseexuhs]

Great work! Thanks for the Zotero Team.

I just tried the Zotero 8, and found some bugs.

The most serious one is that the menu-item "export note" failed to work. I guess there is something wrong with the translator for converting html to markdown.

Hope this bug will be fixed soon, which is also important for my plugin.

Dan Stillman <dsti...@zotero.org> 于2025年7月17日周四 15:18写道：

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/01000198173f62fe-d0019fd6-2d76-4350-beae-c57401dcdece-000000%40email.amazonses.com.

[Abe Jellinek]

Thanks, pushed a fix which will be available in the next dev build.

What are the other bugs you’ve found?

Note that this is a very early dev build and, although it isn’t as rough as early 7.0 or 7.1 dev builds, it’s absolutely not ready to be used for anything other than verifying your plugin’s compatibility with platform changes. Bugs are to be expected.

On Jul 17, 2025, at 9:19 AM, iseexuhs <isee...@gmail.com> wrote:

Great work! Thanks for the Zotero Team.

I just tried the Zotero 8, and found some bugs.

The most serious one is that the menu-item "export note" failed to work. I guess there is something wrong with the translator for converting html to markdown.

<image.png>

Hope this bug will be fixed soon, which is also important for my plugin.

Dan Stillman <dsti...@zotero.org> 于2025年7月17日周四 15:18写道：

We'll soon be releasing a beta version of Zotero that's built from Firefox 140 ESR instead of Firefox 115 ESR (Zotero 7.0) or Firefox 128 ESR (the "Zotero 7.1" beta). This beta will become Zotero 8, which we plan to release later this year.

All plugins will need to be tested for compatibility and updated as necessary. We don't expect most plugins to require significant changes.

After testing/updating, plugins will need to be updated to declare "8.0.*" for strict_max_version. If your plugin is already compatible, you should be able to update strict_max_version in your update manifest without releasing a new version with an updated manifest.json. Be sure to update manifest.json for your next release.

We're planning to push out a Firefox 140–based beta build on Monday, July 28, 2025.

See Zotero 8 for Developers for the platform changes we're aware of. You can install a Firefox 140-based dev build from that page for testing your plugins.

As always, you can use Zotero.platformMajorVersion to test whether a Zotero build is based on Firefox 115, 128, or 140, which will allow you to update your plugin in advance of the Zotero beta that includes these changes.

Let us know if you have any questions or if you have any trouble updating your plugins.

- Dan

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/01000198173f62fe-d0019fd6-2d76-4350-beae-c57401dcdece-000000%40email.amazonses.com.

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/CAOmNm5K7ZJx6xzK-qKSBm0txtUMiYaYRBjZOmCGS_-uV0dW_Cw%40mail.gmail.com.

[Northword]

I got error `Cu.unload is not a function`,  it‘s not available after esmify, does the plugin need to perform these extra cleanups on onShundown?

source: https://github.com/windingwind/zotero-plugin-template/blob/dfd8682d771bd96fda9fcec4d9a5f3b8591d9447/addon/bootstrap.js#L68

[Abe Jellinek]

We don’t use Cu.unload() in Zotero, and I doubt it’s necessary for plugins - plugin scripts are run in a sandbox that Zotero destroys on shutdown. Did you observe a specific memory leak issue that the unload() call is intended to prevent?

-- 
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/98cef1e2-04b1-4b56-abda-2cfabccc9c89n%40googlegroups.com.

[Abe Jellinek]

Yeah, I’m pretty sure you don’t need that, since it doesn’t actually unload instances of the script, just clears the cache for future loads, which Zotero already does.

[Emiliano Heyns]

In the list of changes, can they be marked whether they work in Zotero 7 (so I can make the changes now) or whether they will only work in the beta? Where relevant of course, the move away from bluebird can obviously be done now. 

[iseexuhs]

Continue with the "Export Note" bug I reported yesterday, here I will report the other bugs I found for now.

## the style rendering problem of "textarea" tag

There are  style rendering problems of "textarea" tag both for .xhtml and .html

### <html:textarea> in .xhtml

As shown in the following  figure, there is no border for the  <html:textarea> elements  in .xhtml, which are both found in the Zotero Preferences Pane and my plugin xhtml dialogs.

### <textarea> in html

I introduced  some html in my zotero plugin by injecting iframe. But I found that all the <textarea> elements in html show strange style.

That is to say, the background  color of the  <textarea> is always gray.

## the gray background color of <menulist>

In my plugin,  I introduce some <menulist> elements to Zotero reader sidepane by "document.createXULElement('menulist');"

But in Zotero 8, all the  <menulist> have a gray background, which looks ugly.

Hope these bugs will be fixed soon, which is important for plugins and Zotero itself, I think.

Thanks very much.

[XY Wong]

For menulist, please use `native="true"` for native appearance.

We'll look into other UI issues. Thanks.

[Abe Jellinek]

I’ve been working on the textarea issue. It’s a bit tricky, but we’ll fix it globally so plugins won’t need to do anything special.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/e13eb0f7-d29d-454a-967b-fdcf1bda76a8n%40googlegroups.com.

[iseexuhs]

Thanks, it is very helpful.

[iseexuhs]

Thanks. In fact, I found that if a style "border: 0" is set to the textarea, it will look normal. But, obviously, this is not an elegant way.😂 Anyway, look forward to the solution from the Zotero Team.

[iseexuhs]

still struggle with this.

previously, I use the following codes to convert html to markdown.(these codes are also inside the Zotero editorInstance.js file)

```

function html2markdown(html) {

   let item = new Zotero.Item('note');
   item.libraryID = Zotero.Libraries.userLibraryID;
   item.setNote(html);
   let text = '';
   var translation = new Zotero.Translate.Export;
   translation.noWait = true;
   translation.setItems([item]);
   translation.setTranslator(Zotero.Translators.TRANSLATOR_ID_NOTE_MARKDOWN);
   translation.setHandler("done", (obj, worked) => {
      if (worked) {
      text = obj.string.replace(/\r\n/g, '\n');
      }
   });
   translation.translate();
   return text;
}

```

However, in Zotero 8, the codes fail to work.

Look forward to the favor from the Zotero Team. Thanks very much.

在2025年7月17日星期四 UTC+8 21:19:40<iseexuhs> 写道：

[David Hoff-Vanoni]

Hi Zotero devs, looking forward to Zotero 8!

I want to clarify something about this point from the Zotero 8 for Developers page:

> Preference panes now run in their own global scope, so a var defined in one preference pane's script won't automatically be accessible to other preference panes. Set variables on window explicitly if you need to share them between preference panes.

It appears this new private scope is not available in my pane's XHTML fragment. In my pane's script, I will have to set a variable on `window` if I want to access it from an `onload` attribute in my XHTML, is that correct?

I don't need this variable shared between preferences panes—I just want to use it in my own pane. Is assigning to `window` the only way to make my script available to my XHTML? Is there a better alternative to the `onload` attribute to call an init function in my script?

Thanks!

[Abe Jellinek]

That’s a good point. I’ll see what we can do.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/7565d634-b8de-4558-a1b7-191bafdf0e5cn%40googlegroups.com.

[Abe Jellinek]

You should be able to fix this with a one-line change in your build.mts file: change the preferences.tsx globalName from ‘notero' to ‘window.notero'. That shouldn’t cause any problems on older versions of Zotero.

More in-depth explanation:

We made this change because many preference scripts are going to need to declare top-level variables for imports now. We don’t want those to cause global variable clashes, since a let/const clash throws an error, and a clash with a generically-named variable like lazy could cause unexpected behavior. We also want to avoid panes accidentally relying on another pane being loaded. For example, if you happen to always open General before opening your own pane, you could accidentally end up relying on something General imports.

We could make it so only vars, not lets/consts, would be exposed globally, but I think that’s confusing in its own way. The current best practice seems to be keeping definitions local by default — ES modules work the same way — so I think it’s best for us to stick with that.

So define your object on window if you want it to be accessible from outside your pane’s scripts. There shouldn’t be any backwards-compatibility issues, since you’re just explicitly specifying the implicit default behavior in previous versions of Zotero.

[Emiliano Heyns]

Wrt esmification - is there a syntax (eg using importESMModule) that will work across zotero 7 and 8? That would allow me to keep to one codebase until zotero 8 is released and established. 

[David Hoff-Vanoni]

Thanks, Abe! The motivation for sandboxing each preference pane makes sense. I ended up going with a slightly different approach since changing my build config to assign to `window.notero` didn't seem to work. I think it was perhaps declaring a new `window` variable that shadowed the global one.

Emiliano, I found that `importESModule` is available in Firefox 115 (Zotero 7) and seems to work just fine in both Zotero 7 and 8. I also found that the `.sys.mjs` versions of platform modules work in both Zotero 7 and 8. I was able to refactor my code so it uses the new modules without the need for any version checks.

[Northword]

> is there a syntax (eg using importESMModule) that will work across zotero 7 and 8?

An example  by winding in zotero-plugin-toolkit can also be referenced: https://github.com/windingwind/zotero-plugin-toolkit/blob/5acecb98254f39ef9c6941eca03996761d4afe33/src/basic.ts#L522-L535

[Abe Jellinek]

Zotero modules went from .jsm to .mjs, Mozilla modules (anything without /zotero/ in the URI) went from .jsm to .sys.mjs.

Plugins still have access to ChromeUtils.import() via a shim that converts the path and calls importESModule(). The shim logs a warning every time it’s called, but you could copy it into your own codebase without the warning if you wanted to use it until Z8 is stabilized.

-- 
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/661a1773-3128-425f-af29-6dc0a06c3dc3n%40googlegroups.com.

[Emiliano Heyns]

Thank you, that does solve most of the problems.

[Emiliano Heyns]

What is the status of 7.1 beta vs 8.x beta? My test setup currently accomodates one release and one beta channel, as does zotero-deb. In my current setup, that means 7.0 and 8.x beta.

[Sebastian Karcher]

Dan said on the forums that 7.1 will turn into 8 and they are planning to switch beta to the 8.0 release today.

S

Sent from my phone

--

You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/7eb64d4f-b4f2-40e6-ac4e-2d3d196a6989n%40googlegroups.com.

[iseexuhs]

Hello, Zotero Dev Team.

In the latest Zotero 8 beta 4, the <textarea> issues still exist somewhere. 

The <textarea> now displays well in PreferencesPane of Zotero and plugins. However, in xhtml window etc., there is no apparent border for <textarea> elements. Also, in embedded html window, the background of <textarea> is still gray.

This is very important, Hope It will be fixed soon. Thanks.

[Will S]

I could use some help with updating my plugin (Zutilo). I ran the migration scripts, which I think were helpful (the plugin mostly seems to work after running them). After some additional changes, things are mostly working but the main issue that I am having is that the script associated with the preference pane does not seem to be loading its objects into the context that the preference pane html expects. In particular the plugin runs:

        Zotero.PreferencePanes.register({
            pluginID: Zutilo.id,
            src: Zutilo.rootURI + 'chrome/content/zutilo/preferences.xhtml',
            scripts: [
              Zutilo.rootURI + 'chrome/content/zutilo/preferences.js'
              // Zutilo.rootURI + 'chrome/content/zutilo/keyconfig_adapted.js'
            ],
        })

which does get run and from printing to the log it could be confirmed that preferences.js does get executed. However in the error console I see:

Uncaught ReferenceError: initializePrefWindow is not defined
    onload chrome://zotero/content/preferences/preferences.xhtml:1
    _initImportedNodesPostInsert chrome://zotero/content/preferences/preferences.js:590
    rest chrome://zotero/content/preferences/preferences.js:331
preferences.xhtml:1:1
    onload chrome://zotero/content/preferences/preferences.xhtml:1
    _initImportedNodesPostInsert chrome://zotero/content/preferences/preferences.js:590
    rest chrome://zotero/content/preferences/preferences.js:331
    InterpretGeneratorResume self-hosted:1425
    AsyncFunctionNext self-hosted:800

The xhtml file has `<vbox onload="initializePrefWindow(); buildMenuPrefs();">` in it and preferences.js defines `function initializePrefWindow()`. I see this comment in the migration guide: "Preference panes now run in their own global scope, so a var defined in one preference pane's script won't automatically be accessible to other preference panes." Do the functions like `initializePrefWindow` need to be referenced in some other way in the xhtml file?

For reference, the updated version of the plugin is in this branch: https://github.com/wshanks/Zutilo/tree/zotero8 (any other comments on things to update for Zotero 8 are appreciated as well).

One minor comment about the migration scripts -- they run `eslint --fix` with different formatting rules than my project, so a lot of changes unrelated to the migration get created as well.

[XY Wong]

@Will: You can attach the methods to the `window` object and then access them directly.

re eslint: you can comment out that line if you don't use eslint.

[Will S]

Thanks, XY! Adding `window.initializePrefWindow = function() ...` fixed the preferences issue.

[XY Wong]

Better to namespace the method with e.g. your plugin name so that there won't be potential conflicts between plugins.

[Abe Jellinek]

Yes, please namespace things you define on `window` and be sparing with that - the aim of putting pane scripts in separate scopes was to reduce conflicts. Also, people might copy Zutilo’s preference pane code when writing their own plugins, and using a name that includes “Zutilo” will make it clearer that it should be changed in derivative works.

After the commit I just pushed makes it into a beta, you’ll also be able to access vars/functions defined by your scripts under `Zotero_Preferences.getScope('your-pane-id’)`. If you prefer, you can use that instead of defining things on `window`.

(We run ESLint --fix because jscodeshift, the tool that applies the transformation, has a bad habit of removing spaces before parentheses and adding extra parentheses around awaits.)

-- 
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/zotero-dev/2d918222-60ea-4382-9f6b-e088da64a628n%40googlegroups.com.