I guess it's Greasemonkey's own problem again, so we have to look it up on Wiki until we see Greasemonkey Manual:Environment . There is a passage in it

Depending on the usage, the special Greasemonkey environment may seem perfectly normal, or excessively limiting.
The Greasemonkey environment is a vanilla XPCNativeWrapper of the content window, with only certain extra bits added in to emulate a normal environment, or changed. Specifically:

• window is an XPCNativeWrapper of the content window.
• document is the document object of the XPCNativeWrapper window object.
• XPathResult is added so that document.evaluate () works.
• Unless the @ unwrap metadata imperative is present in the user script header, the entire script is wrapped inside an anonymous function, to guarantee the script's identifiers do not collide with identifiers present in the Mozilla JavaScript sandbox. This function wrapper captures any function definitions and var variable declarations made (vari = 5;) into the function's local scope. Declarations made without var will however end up on the script's this object, which in Greasemonkey is the global object, contrary to in the normal browser object model, where the window object fills this function. In effect, after i = 5 See also: Global object, the values of window ['i'] and window.i remain undefined, whereas this ['i'] and this.i will be 5. See also: Global object
• In order to access variables on the page, use the unsafeWindow object. To use values defined in a script, simply reference them by their names.

is that Greasemonkey is safe, so Greasemonkey scripts are executed in a sandbox and restrict some content. This includes that the window object is not the browser's native object, but rather the XPCNativeWrapper .
so, what is XPCNativeWrapper .? (one Greasemonkey has too many holes-sharp vomits blood)
We found two articles

• XPCNat ive Wrapper
• Use XPCNativeWrapper

after reading it, you only know that XPCNativeWrapper is used in the extension to protect untrusted objects, not the API of the browser client itself.

well, with all this talk, what is the solution?

the answer is simple. In fact, using unsafeWindow object can behave in the same way as using a native window object, even if this is not recommended, but sometimes it is still necessary!