Improper Flagging of variable name = window in Components

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
7 years ago
3 years ago

People

(Reporter: whitedavidp, Unassigned)

Tracking

Details

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Firefox/3.6.23 ( .NET CLR 3.5.30729; .NET4.0C)
Build ID: 20110920075126

Steps to reproduce:

My ThunderbirdBiff addon employs a couple components written in JS. In one of them, my code uses a local variable named "window".

The current version of the validation suite on AMO <https://addons.mozilla.org/en-US/developers/addon/validate> flags this variable as in conflict with a global variable of the same name.

It is my understanding that components do NOT have access to the global window variable. If so, shouldn't this test not be applied to files under components? 


Actual results:

Improperly flagged as a warning.


Expected results:

Should be ignored because there is no global variable called window in a component's scope (if my understanding is correct).
Components usually don't access the global window object, but they can, so there's still a possibility for that warning to be valid. In most cases it won't be a problem, and editors are the ones who make the determination if it should matter or not.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

7 years ago
Wow. This is new info to me. I would like to do this from a component in one of my addons. Can you please tell me how I can reference the global object called window from inside my XPCOM components? It seems from here <https://developer.mozilla.org/en/Working_with_windows_in_chrome_code#From_XPCOM_components_and_modules> that it should not be available. Same thing here <http://kb.mozillazine.org/Implementing_XPCOM_components_in_JavaScript> under the heading "XPCOM Drawbacks". Thanks
The Window Mediator service gives you access to all windows: https://developer.mozilla.org/en/nsIWindowMediator. There are other components that can give you access to content windows, like progress listeners and http listeners: https://developer.mozilla.org/en/XUL_School/Intercepting_Page_Loads

I'm sure there are other ways. There are security considerations that need to be made when mixing content and chrome, but it is certainly possible to pull that off.
(Reporter)

Comment 4

7 years ago
Jorge. I am confused. The original question related a variable named window located in a component with a warning that the variable named window would interfere with the global variable of the name window that is located in typical window overlays. The fact that someone can access the window variable through the window mediator interface doesn't change the fact that there is NO global variable named window in the component's scope. One of us is missing something. I am not convinced it is me. Will you check my thinking here please?
A component could contain code that runs in the window context, like an event handler, which could have a variable named window that does exactly the same as you would in a chrome script. The warning is there in order to ensure all cases are covered.

Our general policy is to err on the side of caution, and that's the reason the validator generates many false positives.
(Reporter)

Comment 6

7 years ago
Thanks Jorge. I did not consider that circumstance. I like to learn something new every day. Today this was it!
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.