737022 - Re-enable strict warnings while parsing XUL

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[[e-mail]]

+++ This bug was initially created as a clone of Bug #385872 +++

Bug 383365 enabled strict warnings in debug builds by default, for both chrome and content.

Bug 385872, while trying to turn off strict warnings in content in debug builds, managed to completely disable strict warnings while parsing XUL, because the call to JSOptionChangedCallback was moved from nsJSContext::nsJSContext (where everyone gets it) to nsJSContext::InitClasses (where only HTML gets it).

Comment 1

[[e-mail]]

Attachment: Proposed patch

Comment 2

[:aceman]

What types of warnings does this enable? I see many warnings in debug builds that aren't seen in normal builds.
Like 'reference to undefined property' or 'variable redeclaration'.

Comment 3

[:aceman]

I mean in the Error console.
Is this bug about something else?

Comment 4

[[e-mail]]

(In reply to :aceman from comment #2)
> What types of warnings does this enable? I see many warnings in debug builds
> that aren't seen in normal builds.
> Like 'reference to undefined property' or 'variable redeclaration'.
This enables warnings generated while parsing XUL scripts. You may already be able to trigger those warnings in JS components or modules though; I don't know how their loaders work. Some of the warnings that may be involved: function does not always return a value; redeclaration of variable; test for equality mistyped as assignment? variable redeclares argument; mistyped ; after conditional?

Comment 5

[Mozilla RelEng Bot]

Try run for 438f35edbb51 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=438f35edbb51
Results (out of 219 total builds):
    exception: 2
    success: 175
    warnings: 28
    failure: 14
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-438f35edbb51

Comment 6

[[e-mail]]

Pushed changeset 5c13fce74f83 to mozilla-central.

Comment 7

[[e-mail]]

Mano moved the setting of the context options from InitContext to InitClasses so that it would have a chance to affect global windows after the context had been given a script global object; InitContext is too early for that...

Comment 8

[[e-mail]]

Attachment: More fixes

* Now sets the context options in InitClasses too where we have a window that we can check for chromeness.
* Tweaks checks for content windows so that they don't include XBL/XUL script prototype objects, which will use the chrome window preferences. (XUL actually gives us the script prototype object before it calls InitContext so in theory I could check for chrome XUL, but I hear nobody supports content XUL these days.)

Comment 9

[Philip Chee]

You can still whitelist content XUL via the permissions manager.

Comment 10

[[e-mail]]

Pushed changeset fb23c30e3d60 to mozilla-central.