How can I refer the plugin settings from contentScript?

uphy · 2021-03-06T07:31:57.019Z

I'm developing a plugin that enables embedding PlantUML diagrams in markdown.

I have defined settings like below:

uphy/joplin-plantuml-plugin/blob/aa11e3b27e9f90680e54711bb07b7d7fbe32573f/src/settings.ts#L15-L38


export async function registerSettings() {
    await joplin.settings.registerSection(settingSection, {
        label: 'PlantUML',
        iconName: 'fas fa-sitemap'
    });

    await joplin.settings.registerSetting(settingKeyOpenMarker, {
        type: SettingItemType.String,
        value: '@startuml',
        description: 'String to use as opening delimiter.',
        section: settingSection,
        public: true,
        label: 'Open Marker'
    });

    await joplin.settings.registerSetting(settingKeyCloseMarker, {
        type: SettingItemType.String,
        value: '@enduml',
        description: 'String to use as closing delimiter.',
        section: settingSection,

This file has been truncated. show original

And I have tried to refer the settings from here in contentScript

github.com

uphy/joplin-plantuml-plugin/blob/aa11e3b27e9f90680e54711bb07b7d7fbe32573f/src/markdownItPlantUmlPlugin.ts#L4-L9


const markdownItPlantUml = require('markdown-it-plantuml');
markdownIt.use(markdownItPlantUml, {
    // How can I refer settings from here?
    openMarker: '@startuml',
    closeMarker: '@enduml',
});

But it seems that we can't use plugin's API from there.

How can I refer the plugin settings from contentScript?

roman_r_m · 2021-03-06T08:27:37.807Z

Send a message to your plugin, get settings in the plugin, send the result back to the contentscript.

uphy · 2021-03-06T08:46:01.822Z

Thank you for your reply!

I have defined onMessage() which returns settings and tried to get the settings from contentScript,

github.com/uphy/joplin-plantuml-plugin

Send settings with message.

committed 08:40AM - 06 Mar 21 UTC

uphy

+11 -0

But it seems not allowed for markdown-it plugin.

loadContentScripts: context.postMessage is not available to renderer content scripts

github.com

laurent22/joplin/blob/e595e19c0daa2f68792885b4b9b55960ccefff16/packages/lib/services/plugins/utils/loadContentScripts.ts#L18-L20


		if (scriptType === ContentScriptType.MarkdownItPlugin) {
			logger.error('context.postMessage is not available to renderer content scripts');
		} else {

laurent · 2021-03-06T09:58:46.613Z

Hmm, I don't think that's possible actually. You can post messages from the HTML that the content script generates, but you can't when you instantiate the Markdown-it plugin. Maybe some way to do this should be provided via the context variable.

laurent · 2021-03-06T10:01:38.925Z

If I may make a suggestion, it would make sense to use a fence like this to delimit the UML code:

```plantuml
Bob -> Alice : Hello
```

That would be consistent with how it's done for Mermaid, Fountain, etc.

uphy · 2021-03-06T10:27:34.547Z

Thank you for the suggestion!
Now I'm using it as fence.

By the way, I want to switch PlantUML server by settings.
Currently I'm using a public PlantUML server. This means that we can't use this plugin with confidential information.

To switch the server, would you consider to give us a way to get settings from content script?

laurent · 2021-03-06T10:32:23.460Z

Yes I think we should add this. Calling postMessage at this point would be tricky because it's async, and that function is synchronous. Perhaps it's a matter of allowing to pass variables from the plugins via the context parameter.

uphy · 2021-03-06T10:37:56.093Z

It's nice idea. I'm looking forward to the feature being implemented.

rxliuli · 2021-03-06T16:55:02.028Z

I do not recommend to provide it directly, because there are too many tool libraries for encapsulating postMessage/onMessage, the most typical one is ChromeLab’s comlink, ref: GitHub - GoogleChromeLabs/comlink: Comlink makes WebWorkers enjoyable.

ocelotsloth · 2021-03-31T16:12:34.352Z

+1

@uphy I just went down this same path trying to modify your plugin to add the ability to change the PlantUML server.

For a variety of reasons I cannot use the public PlantUML server for work.

In the meantime--I'll just run a custom version of your plugin that hard-codes the change.

victorkane · 2021-06-15T14:42:21.259Z

@uphy I am overjoyed with this plugin, thanks so much for creating it. I began using it and testing it out pretty thoroughly over the past few days.

I am using the Joplin desktop version with Dropbox sync both on a MacBook Air and on a PC with Ubuntu 20.04. What I describe below occurs equally, exactly the same, on both machines.

I found that it works well, but every now and then (after extended use, especially with standard library examples from the Hitchhikers Guide docs???) it causes Joplin to crash with an error report. This is sporadic, not connected to errors or length (previous short examples which worked fine before sometimes end up with a Joplin error page making a reboot in safe mode. When this happens, the page causing the crash causes it on both machines.

I am using everything out of the box, although I did install a local PlantUML server with docker, I did not see any settings page in order to try everything out with a local server (I have since read other comments touching on this).

I am willing to do extensive testing if when there are updates to the plugin.

Again, thanks so much for the contribution.

ocelotsloth · 2021-07-19T04:52:15.768Z

I think you're running into this issue: plugin causes a crash · Issue #3 · uphy/joplin-plantuml-plugin · GitHub

There's a patch (Fix plugin crashing joplin (#3) by mablin7 · Pull Request #4 · uphy/joplin-plantuml-plugin · GitHub) that's already been merged to fix. Hopefully we can get a new version released before too much longer.

marc0l92 · 2021-09-17T22:50:42.566Z

Hello, I'm facing the same communication issue with my plugin.
Do you have an example of plugin that is using the method you suggested with Comlink?

Thanks

laurent · 2021-09-18T00:00:50.656Z

What kind of content script? And what does it do?

marc0l92 · 2021-09-18T07:36:05.303Z

I would like to update the jiraIssue plugin I created in order to use content script.

The current version generates markdown that is automatically rendered.
The problem with this approach is that I pollute the note with a lot of text.
With a content script I could hide this inside the html and css and create a nicer output.

I'm currently not able to read the plugin settings from the content script.

The only way I found to communicate between content script and plugin is to use the webviewApi.postMessage. This api is only available in the rendered HTML and I cannot run it without a user input (like the click of a button or link like you did in the contentScript plugin example).

Can you suggest me another approach?

marc0l92 · 2021-09-23T11:20:00.081Z

The only way I found to get the settings from the contentScript is to:

create a contentScript plugin that does nothing
in the html rendered by the contentScript I call the webviewApi sending the content written inside the fence
the joplin plugin combines the content with the settings and replays with the new HTML that will replace the HTML that was calling the webviewApi

I had some problem figuring out how to call the webviewApi when the markdownIt page was rendered, but I finally managed to find a solution.

I use the event:

<style onload=" here the javascript to call the webviewApi" ></style>

I'm not sure this will help the plantuml plugin because it needs the settings to be accessed in the contentScript and not in the HTML rendered by the contentScript.

I hope this can help other plugin developers.
Let me know if you need more details.

extall · 2021-09-25T11:18:00.071Z

Well, exactly, this seems to be the only way to do it now and it imposes quite a few limitations. I've spent quite a bit of time trying to rework the BibTeX plugin but in the end I had to start digging into Joplin's source code as the plugin API just does not provide enough features at the moment. We'll see how that goes.

marc0l92 · 2022-02-17T11:32:38.988Z

Please, let us know if you find any ineresting hack to have access to some internal features

personalizedrefriger · 2022-09-18T22:29:09.428Z

Edit: Never mind! I was responding with a solution to a similar (but quite different) problem I was experiencing.

A workaround is for the content script to call repeatedly postMessage and await the result (because postMessage returns a Promise). The plugin's entrypoint script can then resolve that Promise when it wants to send a message to the content script.

Example

(Taken from the custom CodeMirror .vimrc plugin and modified)

Type definitions

// Type definitions

interface FooMessage {
	kind: 'foo';
}

interface BarMessage {
	kind: 'bar';
	content: string;
}

interface SetReceiveMessageCallback {
	kind: 'set-callback';
}

type ToContentScriptMessage = FooMessage|BarMessage;
type FromContentScriptMessage = FooMessage|SetReceiveMessageCallback;

// Content script:

type PostMessageCallback = (message: FromContentScriptMessage)=>Promise<string|ToContentScriptMessage>;
type OnMessageCallback = (message: ToContentScriptMessage)=>void;

const setupOnMessageCallback = async (
	onMessage: OnMessageCallback, postMessage: PostMessageCallback
) => {
	// Handle messages from index.ts in a loop:
	while (true) {
		const callbackResult = await postMessage({
			kind: 'set-callback',
		});

		// Result should be a ToContentScriptMessage
		if (typeof callbackResult === 'string') {
			throw new Error(`Invalid callback result: ${callbackResult}`);
		}

		onMessage(callbackResult);
	}
};

export default (context: { contentScriptId: string, postMessage: PostMessageCallback }) => {
	return {
		plugin: () => {
			setupOnMessageCallback(message => {
				console.log('Message from index.ts: ', message);
			}, context.postMessage);
		}
	};
};

// index.ts
joplin.plugins.register({
	onStart: async () => {
		const contentScriptId = `some-content-script-id-here`;
		let messageContentScriptCallback: MessageContentScriptCallback|null = null;
		await joplin.contentScripts.onMessage(contentScriptId, (message: FromContentScriptMessage) => {
			if (message.kind === 'set-callback') {
				return new Promise(resolve => {
					// Store resolve as a callback — we can use it to communicate with the contentScript.
					messageContentScriptCallback = resolve;
				});
			}

			// Handle other message types here.
		});
		await joplin.contentScripts.register(
			ContentScriptType.CodeMirrorPlugin,
			contentScriptId,
			'path/to/content-script.js',
		);
		
		...

		// Send a message to the content script
		messageContentScriptCallback({
			kind: 'foo'
		});
	}
});

laurent · 2023-11-03T19:56:55.454Z

From the next version, it will be possible to access the plugin settings from the renderer, using the provided options.settingValue() method (which only returns your own plugin settings).

For example:

export default () => { 
	return {
		plugin: (markdownIt, pluginOptions) => {	
			markdownIt.renderer.rules.fence = function(tokens, idx, options, env, self) {
				const mySettingValue = pluginOptions.settingValue('mySetting')
				// ...								
			};
		},
	}
}

Note that for now it's only supported by renderer content script (not CodeMirror ones).