define Cc, Ci, Cr, and Cu in Thunderbird just as in Firefox

ASSIGNED
Assigned to

Status

Thunderbird
General
--
enhancement
ASSIGNED
9 years ago
4 years ago

People

(Reporter: myk, Assigned: sid0)

Tracking

(Depends on: 1 bug)

unspecified
Thunderbird 3.0rc1
Bug Flags:
blocking-thunderbird3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [no l10n impact])

(Reporter)

Description

9 years ago
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.)
We have been explicitly avoiding adding these constants due to the mess it leaves javascript files in... You never know if Ci etc is already defined or not, and if you get it wrong, then you have clashes. Plus it gets nightmare-ish for extensions.

So we have consciously decided not to get into that mess (and with the mapping/spread of the mailnews js files its likely to be even worse to manage).

IMHO The only way this is likely to be fixed is by getting core to fix bug 420147 in a sensible manner.
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.
(Reporter)

Comment 3

9 years ago
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.
We should definitely do this for rc1.

This is easily tractable given our small number of top-level windows, and at
worst we introduce a Thunderbird-specific global javascript file that primes
the scope.

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

I am assigning this to myself, but if someone else wants to snipe it, it's
fine.
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
Flags: blocking-thunderbird3?
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+

Updated

9 years ago
Whiteboard: [no l10n impact]
(Assignee)

Updated

9 years ago
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.