`GM.info` / `GM_info` not working in the page context

[wolfissimo]

According to documentation, GM.info / GM_info should be available without having to @grant it. In version 1.5.0/4.5.0 this is no longer the case, which is bad because using @grant leads to other issues. Please fix this.

[ACTCD]

Please provide more information or further proof.
After testing, the issue you described cannot be reproduced.

[ACTCD]

I see that the problem is that now GM.info is no longer available when @inject-into page, which is indeed a different behavior than before.

But I think this is working as expected, all privileged APIs should only be available when @inject-into content.

Leaking GM.info into the page context tends to lead to privacy risks such as user fingerprinting.

I'm not sure we'll get that behavior back.

[ACTCD]

So, it fits the documentation's description that you can use GM.info / GM_info without @grant them in the content script context.

For reference, could you describe your use cases in detail and the reasons you think it's required to use them in the page context?

For the record, the change was introduced in the refactoring of #560.

[scholtzm]

Just ran into this sudden breaking change.

What's the recommended way to access GM_info now in scripts that run via @inject-into page?

[wolfissimo]

So, it fits the documentation's description that you can use GM.info / GM_info without @grant them in the content script context.

I think, documentation is not absolutely consistent in this point:

• in "Metadata" it says "GM apis are only available when using content"
• in "API" it says "GM.info && GM_info ... is available without needing to add it to @grant"
  The latter was the case until the recent update.

For reference, could you describe your use cases in detail and the reasons you think it's required to use them in the page context?

1. My script uses a XHR proxy, which only works in page context. As soon as I add a @grant, it stops working.
2. The page my script is for is updated every few days, so I also need to update may script very often. So users should always see which script version they are running, for which I use GM.info / GM_info. So at least GM.info.script.version and GM.info.script.name should be available without@grant.

[ACTCD]

Just ran into this sudden breaking change.

What's the recommended way to access GM_info now in scripts that run via @inject-into page?

@scholtzm I am sorry you guys are having issues for this, but as I said before, I don't think this is a "breaking change", it's more like fixing a previous accidental leak.

So, the best way is to describe your use case in detail to help evaluate its necessity.

I think, documentation is not absolutely consistent in this point...

@wolfissimo As I've already explained, it's not a contradiction, you don't need to "grant" this API in the "content script context", it's always available.

As for your use case, I don't understand it. Could you please add more details?

If you mean that you show the version of the script on the page by reading GM.info, I think you can do that by updating the variables in the code at the same time as you update the script, reading through GM.info isn't necessary is it? Example:

// ==UserScript==
// @name        NewScript-j2qot9yz
// @version     1.0.0
// @description This is your new file, start writing code
// @inject-into page
// @match       *://example.com/*
// ==/UserScript==

(function () {
	const version = "1.0.0";
	// do whatever...
})();

[scholtzm]

My use case is simple, I display script version and icon (URL) from GM_info in the UI elements added by the script.

[ACTCD]

@scholtzm Then consistent with the example I made above, you could just add a variable to the code and update them at the same time as you update the script.

I know this may be a bit repetitive and redundant, but considering the security of the page context, it's worth it.

[scholtzm]

It that's what it takes, I will remove the usage of GM_info.

I am sorry you guys are having issues for this, but as I said before, I don't think this is a "breaking change", it's more like fixing a previous accidental leak.

Agree to disagree here. Just using the API as documented in the README. This is a breaking change and the API should have been properly deprecated for use in page context.

Keep in mind this change might have broken hundreds of scripts that worked previously.