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:

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.
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. 🙂

Have problems with promisified chrome.contextMenus.create method #23

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions