Have problems with promisified chrome.contextMenus.create method

[q00n]

Hi, promisified chrome.contextMenus.create method doesn't returns id of the created menu

[KeithHenry]

@q00n well spotted - that method has a slightly different pattern to most. The common pattern (in TS syntax) looks something like action(...params, callback: result: T => void): void and we turn it in to action(...params): Promise<T>.

However, chrome.contextMenus.create is a little different as it immediately returns the created menu, more like create(createProperties, callback: result: () => void): string | number, and this gets turned into action(createProperties): Promise<void>.

I think this method (and any others where the callback doesn't get passed the result) need a different promisify function.

[dlh3]

This is pretty old now, but as @KeithHenry pointed out, it seems that chrome.contextMenus.create accepts a callback, but it isn't actually an asynchronous action (since it returns immediately). As an aside, I'd love to know how this inconsistency came about; I suspect it was an intern and an overworked lead reviewing the PR, but who knows 🤷🏻‍♂️.

While this project could absolutely implement a completely separate promisify function, I had a couple ideas for working with the existing one:

1. Remove non-standard contextMenus.create #26 was my initial solution. By simply removing the offending method(s) from the applyMaps argument, the function return wouldn't be suppressed by the promise wrapper. This would work fine for async/await constructs, but would fail for .then() or any other uses of the Promise API, since there would be no promise returned. Of course, the developer could easily wrap the call in Promise.resolve(...). This solution would also be less durable, since any other inconsistencies would have to be identified and removed from the applyMaps argument.

2. To address the pitfalls of Remove non-standard contextMenus.create #26, I arrived at alternative solution Handle edge case with no callbackArgs #27. This one is more consistent, since it still wraps the chrome.contextMenus.create function in a promise. It's also (hopefully) more durable, since it would automatically apply in the cases where the target function's callback provided no arguments. In this implementation, when callbackArgs is undefined or zero-length, we resolve the promise with the value returned by the function itself.

I recommend #27. 🙂