A huge bug of Zotero 7 about running plugin

[iseexuhs]

Hello, I am a Zotero 7 plugin developer. These days, I found that sometimes (not always), the new added functions of the plugin will not take effect after installing the plugin and restarting Zotero. But if changing the language of Zotero (in preferences window) to another (e.g. from English to Chinese), and restart, the new added functions will work. AND if I again install an even newer version of plugin, the further added functions still does not work otherwise I change Zotero language again. 

It seems the newer js scripts of plugin failed to be loaded by Zotero 7 if the language is not changed.

Besides my own plugin, I also found this problem in other Zotero 7 plugins. So, for now I am sure that Zotero 7 has a serious bug on running plugin. It's very strange, so I report this here...

Hope to get an answer. Thank you.

[Dan Stillman]

On 7/14/23 6:37 PM, iseexuhs wrote:

Hello, I am a Zotero 7 plugin developer. These days, I found that sometimes (not always), the new added functions of the plugin will not take effect after installing the plugin and restarting Zotero. But if changing the language of Zotero (in preferences window) to another (e.g. from English to Chinese), and restart, the new added functions will work. AND if I again install an even newer version of plugin, the further added functions still does not work otherwise I change Zotero language again. 

It seems the newer js scripts of plugin failed to be loaded by Zotero 7 if the language is not changed.

I think there's some confusion here.

Zotero itself doesnt do anything other than call the plugin's bootstrap methods. It's the plugins themselves that perform various actions. So saying that "the functions of the plugin will not take effect" doesn't make sense. If you're saying that `startup()` isn't being called in some cases, then say that, and tell us exactly how to reproduce the problem. You can run Zotero with debug output to see logging for bootstrap method calls.

Beyond that, you're talking about changing the language as if that's a factor here, but presumably the only relevant thing is that changing the language prompts a restart. You can just as easily close Zotero and restart it yourself. So you're just bringing in multiple things that likely don't have any relevance and are obscuring whatever actual issue you're reporting.

If you can find steps to reproduce a specific problem, let us know, but we're not aware of any current problems with the plugin lifecycle methods.

[iseexuhs]

Thank you for your reply.

Yes, it is a strange issue. But I am very sure about it, and confirmed again and again.

To make it clear, I try to organize my words again as follows:

------

For example, in an old release of my plugin, I added an item menuitem called "Test" in my plugin, which corresponds to the command Zotero.getMainWindow().alert("Hello").

AND, in a newer release of the plugin, I change the command to Zotero.getMainWindow().alert("Hello bro")

1. First, I install the newer plugin, and restart Zotero.

2. When I click the  "Test" menuitem, it still alert "Hello", not "Hello bro".

3. Try to restart Zotero again, nothing changed.

3. Then I change the language of Zotero (e.g. from English to Chinese), then restart Zotero.

4. Now, when I click the  "Test" menuitem, it alert "Hello bro", as expected.

5. Then I modify  the command to Zotero.getMainWindow().alert("Hello my bro"), and install the plugin and restart Zotero.

6. Same issue happens, it still alert "Hello bro", not "Hello my bro". 

7. AND It works normally when I change the Zotero language back to English.

According to above steps, I am sure the Zotero language changes will influence the bootstrap plugin lifecycle methods, which is also found by myself in other Zotero 7 plugin.

Hope the issue report is clear. Thank you.

Ps: my testing environment is the lasted macOS Ventura + Zotero 7.

[Dan Stillman]

OK, so the problem is technically each plugin's loadSubScript() calls, which are cached by default, even across restarts. I didn't test locale changing, but I assume that clears the startup cache.

There's a way to do an uncached subscript load, but we're going to see if we can come up with a better solution here so that each plugin doesn't have to work around this.

Thanks for flagging this!

- 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 on the web visit https://groups.google.com/d/msgid/zotero-dev/44741101-8076-48c4-81ae-d23488f0c34fn%40googlegroups.com.

[iseexuhs]

got it. Thanks again.

[Emiliano Heyns]

One possible way around this is to add a spurious query parameter with the current time to the loadsubscript call.. I can't tesg this as I don't have access to my pc, but it's a common way to force a cache miss. 

[Dan Stillman]

This should be fixed in beta 20, which will be available shortly.

> One possible way around this is to add a spurious query parameter with
> the current time to the loadsubscript call.. I can't tesg this as I
> don't have access to my pc, but it's a common way to force a cache miss.

As I say, there's a way to do an uncached loadSubScript call — not with
a query parameter — but just doing that on every call would be a bad
practice, since it would make all loads uncached, even when the plugin
hadn't changed. So please don't do that.

[Emiliano Heyns]

Has this been fixed since?

[iseexuhs]

I think it is fixed.