To improve compatibility with Firefox extensions that might be ported to Thunderbird (like Personas in bug 483743), it would be useful for the main Thunderbird window to define the same conventional shortcuts to XPCOM global objects that Firefox defines: const Cc = Components.classes; const Ci = Components.interfaces; const Cr = Components.results; const Cu = Components.utils; (Note: Firefox defines at least two of these <http://mxr.mozilla.org/mozilla/source/browser/base/content/browser.js#61> as variables, not constants, but they seem better as constants.)
Depends on: 420147
Do you happen to know *where* you're getting it from in Fx? None of the 25 non-test "const Cc" in /browser/ look like very likely candidates to be doing global scope pollution, and by now I've forgotten what it was that used to do the Mac-only pollution that made people land things that failed on Linux and Windows.
browser.js provides Ci and Cu, declaring them with |let| <http://mxr.mozilla.org/mozilla1.9.1/source/browser/base/content/browser.js#63>. Cc could come from utilityOverlay.js, which is included in baseMenuOverlay.xul via a <script> tag, which is included in browser.xul via a <?xul-overlay?> processing instruction. But utilityOverlay.js also declares Ci as a constant, which presumably would conflict with browser.js's declaration, throwing an exception, so maybe that's not where Cc comes from. I can't figure out where Cr comes from.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Target Milestone: --- → Thunderbird 3.0rc1
(In reply to comment #4) > We should definitely do this for rc1. Why? > Also, we now have tools that can help us find who might already be defining > things: > > http://clicky.visophyte.org/examples/live/doccelerator/_design/doccelerator/index.html#n=Cc Tat doesn't seem to include toolkit files, which I'd be most concerned about conflicting with.
(In reply to comment #5) > (In reply to comment #4) > > We should definitely do this for rc1. > > Why? The rationale for doing it at all is that our code is prettier with the short-hand. Writing out them out in full is problematic when trying to fit lines of code into 80 columns... XPCOM boilerplate ends up a multi-line mess that is not particularly easy to read. The rationale for doing it for 3.0 is that: - We can reliably state that Cc/Ci/Cu/Cr are defined in all of our global scopes for Thunderbird 3.0. No caveats. - We are already doing various things that break extensions. One of the reasons I understood we were avoiding doing this was fear that extensions would fight us and break us or break themselves. By defining them as "const", we provide a strong guarantee that extensions can't hurt us. Extensions will break if they try and do that themselves, but they should not be doing that, and the failure mode is very obvious. > Tat doesn't seem to include toolkit files, which I'd be most concerned about > conflicting with. Honestly, just doing "const" is likely to smoke out any problems immediately, but it's easy to add toolkit files if desired.
blocking+ assuming this is an easy fix.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Assignee: bugmail → sid.bugzilla
We still very much would like this for Tb3, but we've decided that we wouldn't hold if it were the last bug standing, so marking as blocking-.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
You need to log in before you can comment on or make changes to this bug.