494962 - (protovis) Include Protovis and jQuery + some jQueryUI bits in TB3

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[David Ascher (:davida)]

This bug is about adding some third-party OSS code to Thunderbird 3.

The criteria that drive me to suggest them are the following:

a) we want to have a development platform that is as easy to work with for as many people as possible, both for add-on authors and core contributors.

b) if we can include open source code which is well maintained and provides unique, modular capabilities that fit well with our stack, then we should consider including them.  

c) we want to enable rich interactions and user experiences, and building frameworks to support these in-house is a huge investment, which even the Firefox team is unable to do (witness the lack of an animation framework even though there's lots of UX desire for more animation support).

Today, doing visualizations or animations in TB3 is currently very hard, because the platform doesn't provide it. 

I'm proposing that we include two libraries:

 - protovis, for visualizations, as I use in bugs 489999 and 492158.
 - jquery + some of jqueryUI, for easy DOM/CSS manipulation, including animation and fade effects.

Some background:

Protovis is described at http://vis.stanford.edu/protovis/.  It's an actively developed project by the people behind prefuse and flare, which were both very popular, but flash-based systems.  Protovis is heavily based on technologies we promote, such as canvas (in their first version), SVG (in their current version), and advanced JavaScript usage.

Protovis is covered under the BSD license, so is easy for us to include.  The examples are worth looking at to get an idea of the capabilities of the package: http://vis.stanford.edu/protovis/ex/.

The authors of protovis have made changes to the code to make it easier for us to include (e.g. avoiding namespace pollution, providing a versioning scheme), and if we have specific objections I think it's likely we can get them to make changes.

Protovis is not only useful to deliver compelling features, but also provides a really simple way for us to provide a great visualization toolkit as part of the Thunderbird 3 platform.  As an example, the "tag pie" feature (see http://ascher.ca/blog/2009/05/08/getting-insight-into-ones-own-email/) which I don't think is useful enough to include in Thunderbird 3, is trivial to build as an extension:  the visualization bit is as follows:

    var tagPie = {
    [...]
      render: function tagPie_render() {
        let data = [];
        let totalCount = 0;
        for each ([tag, count] in Iterator(this.tagCounts)) {
          totalCount += count;
          data.push([count, this.tagInfo[tag].tag, this.tagService.getColorForKey(this.tagInfo[tag].key)]);
        }
        if (data.length < 1) return;
        data.sort(function(a,b) a[1] > b[1]);
        let tagpie = this.context.idoc.createElement('div');
        tagpie.setAttribute('id', 'tagpie');
        tagpie.setAttribute('class', 'tagpie');
        this.context.idoc.getElementById('column').appendChild(tagpie);
        let vis = new this.context.pv.Panel().canvas(tagpie);
        vis.width(128).height(128);
        let scale = (2 * Math.PI) / totalCount;
        let wedge = vis.add(this.context.pv.Wedge)
          .data(data)
          .left(64).top(64).outerRadius(60)
          .angle(function(d) d[0] * scale)
          .fillStyle(function(d) d[2])
        wedge.anchor("center")
            .add(this.context.pv.Label)
            .text(function(d) d[1])
        vis.render();
      }
    }


There is obviously some implied commitment to deal with eventual bugs, maintenance releases, and figure out an upgrade strategy, like with any embedded 3rd party software.  Given the low complexity of the package (one javascript file), this feels like an overall win.  Andrew Sutherland is the likely person who'd own maintaining protovis, given his interest in visualization and use of protovis in the past (see exptoolbar).

Open questions:

 - where in the tree would this go?
 - how should it go? (I would suggest that it be loaded as chrome://content/messenger/protovis2.js, so we can update minor bugfix releases but have to explicitly change things if there's a non-backwards-compatible major version update)

2) jQuery + jQuery UI

(jQuery is available under the MIT license).


The big drivers for jQuery inclusion are, in my opinion:

 - support for animations and effects would be really, really easy, at least for HTML parts of the UI
 - it would provide a massively popular layer of utility code which we currently lack, in particular around DOM manipulation.

I don't think that all of jQueryUI is ripe for inclusion, though -- the widgets in particular would I suspect be too hard to integrate from a look and feel point of view, and the "interactions" are not that useful.  But the JQueryUI core + effects would give us 90% of the benefit while limiting scope.

A few other points about jQuery:  

 - I suspect (but have no real data to back it up) that there are an order of magnitude more developers using jQuery and filing bugs against it and testing it than any bit of Gecko, let alone comm-central.  

 - Jetpack for Firefox embeds jQuery, for many of the same reasons that I argue we should.

 - jQuery had a reputation for stepping hard on other libraries.  That has AFAIK been fixed, and you can even use jQuery w/o the $() function (but using jQuery(), which we may want to say is a requirement for in-tree code if the $ scares people.

The cost to the TB team of maintaining jQuery is likely even less than Protovis, because it has hundreds of thousands of users, and is already embedded in a lot of products.  Apple, Nokia, Microsoft, etc. all use jQuery in various ways.  I don't think I need to remind people that jresig works for MoCo. ;-).

If Thunderbird 3 provided built-in Protovis & jQuery, combined w/ our much better JS APIs (folderpane, gloda, whatever part of STEEL we end up with), I think we have an exciting and solid platform to get add-on authors excited.

A few other notes:

 -- I don't know what the download size delta would be, but I would be surprised if it was significant, given that we can ship minified JS code if we want. 

 -- If we go ahead, we will have to think about when we update these third-party libraries, much like the Gecko guys think about when to update sqlite. 


Discussion!

(It'd be good to have this discussion soon, as the two bugs mentioned above require protovis and are currently blocking tb3b3).

Comment 1

[Magnus Melin [:mkmelin]]

I'd be more positive to including protovis than jquery. The protovis functionality is a lot more typical framework functionality that's just not that likely to get standardized/into core. 

jQuery on the other hand do less such things, i think. (Like animation, why isn't it core functionality.)

Not sure the argument that it would be any significant gain to extension authors. They can easily include it themselves as needed.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

It would be really nice if the animations that jQuery provides were in core and I believe Alex F. has been trying to make something like that happen.

I think both of these libraries can be seen as not necessary for extension developers because they can just include anything themselves.  I see these libraries as lowering the barrier to entry for extension development and challenging people to work on cool stuff and not the annoying bits.

What including these libraries means to me is that we'll be able to create a positive environment around extensions that are well designed.  Simply that if we don't include protovis people might include a copy and use it in their extension.  If we do include protovis then people might start using it in more places because it's already there.  Spark lines and nice looking graphs would likely be more common in extension offerings just by pulling in the library.

With protovis included I think it makes a lot of sense to offer good documentation and examples of add-ons that use the built in protovis.  Without including protovis we could try to offer the same documentation that informs people how to grab a local copy of protovis and use it inside their extension, but that seems to add a barrier that we could easily remove.

When Mozilla Labs is starting a new extension they use the extension wizard to give them the boiler plate they need and then add a local copy of jQuery to give them decent javascript tools and animations to work with.  For extensions I've worked on this is a common pattern and for future extension, especially inside Thunderbird, I think this is something we'll want to encourage.

I'm glad people are positive on protovis and I can understand how protovis has a much more obvious impact but the simple and subtle animations plus the additional DOM manipulations tools that jQuery provides are very useful.  That's my take as someone who has done a lot of different interactive web applications.  I'm not sure how many times I've seen (temporary?) code inside Thunderbird to add/remove a class or show and hide a widget, these aren't things that are fun to write or good for multiple extension authors to all write themselves.

Comment 3

[David Ascher (:davida)]

Just a couple of points about what jQuery provides that the platform doesn't:

 check out http://docs.jquery.com/Tutorials:Live_Examples_of_jQuery

and look at the code snippets.  All of those things _could_ be in the platform, but they're not.  My point is that if we think those capabilities make sense in the platform, given that they're not there today, we can 

 a) write it ourselves
 b) just use jquery

I see very, very little upside in doing it ourselves, given that it'll take months we don't have, and won't have nearly as many users (or testing) as jquery.  A gecko evolves to have css transitions, SMIL, or whatever, then jquery will leverage those.

For animation examples, see: http://jqueryui.com/demos/addClass/ and other demos in the effects category.

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

From what I understand we can't just have the jQuery animation bits appear in core; they can act in content, but because chrome is XUL and not HTML, you'd need to port jQuery to work in XUL.

Alex F isn't (at all) alone in wanting a set of animation primitives in XUL (see the discussion here: http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/5a76df6df8102608/ ) and we've been advocating for it for quite some time. If this bug happens to get the drum beat going louder, so be it, and fantastic. What I've been told is that the upcoming work on beforePaint will pave the road for the neccessary primitives for a CoreAnimation equivalent in XUL.

As for jQuery vs. Protovis; I think the better option than embedding one or the other wholesale is to determine which bits are most useful and used, and embed those in ways that are discoverable for content and fast-pathed in terms of our execution, or even use them to model APIs for equivalent function. As I have it from Vlad, embedding such libraries will have a non-trivial cost to load times while giving us a bunch of stuff that nobody will use.

Apologies if this seems like stop-energy; it isn't meant to be. Quite the opposite, I hope to prevent stop-energy by trying to acknowledge problems that have been pointed out and bring context and information for ways around those issues.

Comment 5

[David Ascher (:davida)]

Mike, thanks for the input, it's appreciated!  Knowing the issues faced in the past is useful.  I want to clarify a few points, because I think some of the points you bring up might not apply in the TB context.

As everyone on this bug probably knows, chrome doesn't have to be XUL.  While it'd be great to have something work for everything (XUL & HTML), I think that HTML + jQuery can be a compelling UI platform, and that's the underlying thesis -- in particular, for add-on development, putting stuff in an HTML chrome iframe w/ jQuery is a powerful and attractive bit of stack, even if it'd be nicer if the same tech was applicable to every bit of chrome.

I'm not advocating including anything in "core", if by that you mean anything like Gecko, xulrunner, platform, firefox, or anything like that -- I'm quite sure that the tradeoffs for those layers are very different.  I also know that jQuery won't work w/ XUL.  I'm suggesting that jQuery will give us significant benefits for HTML chrome, and some lesser benefits for XUL chrome (I wouldn't be surprised if the selectors and some of the basic functions work, although I haven't tested them).

I'll be totally psyched when core gains animation primitives (and in general, more utility functions around DOM, selectors, etc.).  I suppose I could have split this bug in two, as it conflates adding protovis (for features that we have implemented today) and jQuery, which I'd love to use today, but which I think is more compelling from the perspective of making developing add-ons for TB3 more approachable to a wider audience (HTML devs), simply by promoting the option of doing stuff more like what they know, viz. HTML chrome + jQuery.

I'm not very keen on extracting specific bits of jQuery/Protovis to build a model API, because I think that would guarantee us a) an effective fork, with larger ongoing maintenance costs, and b) lose any leverage from those existing communities.  I'll claim that at least on the TB side we don't know better than the Protovis or jQuery communities how to make visualization and jqueryish libraries that are useful for add-on authors.  Whatever skills we do have I'd rather have apply to making those tools better, rather than reinvent.

If people who want to evolve the XUL platform want to use those as foundational bits on a new set of APIs, that's more than fine by me.  But I don't think there's time/appetite for that in TB land.

As for load time, TB3 would load stuff as needed -- the current plan is to use protovis in several very common scenarios (account selection, folder selection), which I will argue (without data) gives enough value that the load time hit from protovis (once per messenger.xul window) is worth paying.  We wouldn't load jQuery if we didn't need it -- all I'm suggesting is that it'd be available in chrome://, for add-on authors.  (although we might decide that it brings enough value in some html chrome to take the load hit, tbd). 

To summarize: I want all this stuff to be supported by the xul platform, but that could realistically take years, while we can have them in HTML today, and I think that will make TB3 a much more compelling add-on platform than otherwise.  This bug isn't about what should be in "the platform", but in "the thunderbird platform", if that makes sense.

(Aside: I agree that it'd be great to have a version of jQuery that had only gecko-relevant stuff in it, to optimize load time.  I believe that approach is part of what Nitobi did for webkit-based mobile browsers.  I wonder if the jQuery folks would be interested in maintaining that packaging process).

Comment 6

[Dan Mosedale (:dmosedale, :dmose)]

From a product standpoint, Protovis offers a visualization toolkit that works today (and that we've got code that uses), and enabling visualizations in and around email sooner rather than later seems very worthwhile to me.  jQuery offers something broader: a toolkit that has tremendous momentum in the web community. 

I don't see adding this sort of functionality to the XUL platform as being (over the long haul) nearly as leveraged as using the HTML platform in chrome: there will always be many orders of magnitude more developers and better tools for HTML than for XUL.  It strikes me as likely that having full toolkits like this included will attract a set of extension developers who would otherwise never consider writing for the Thunderbird platform.

There is undoubtedly logistical work that this brings to the table (we'd need a security review, verification of a lack of footprint/performance regressions, etc).

Strategically, this strikes me as sound, and I support it.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #6)
> There is undoubtedly logistical work that this brings to the table (we'd need a
> security review, verification of a lack of footprint/performance regressions,
> etc).

jQuery is inert unless we use it, so is unlikely to create footprint/performance regressions in and of itself, unless you are talking about download size/installed size as footprint.

What specifically would you see needing to be audited about it, security-wise?  I think our general exposed surface is in HTML message and feed item display, and it's not clear how having jquery be available via a local URL is meaningfully any more dangerous than jquery in a multipart message.

Comment 8

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #7)
> (In reply to comment #6)
> > There is undoubtedly logistical work that this brings to the table (we'd need a
> > security review, verification of a lack of footprint/performance regressions,
> > etc).
> 
> jQuery is inert unless we use it, so is unlikely to create
> footprint/performance regressions in and of itself, unless you are talking
> about download size/installed size as footprint.

A fair point. I was partly talking about download size, which seems quite unlikely to be an issue.  I also was thinking about how the performance characteristics of the app will change over time (as, for example, Firefox's performance characteristics changed as people started doing more and more AJAXy stuff with it).

> What specifically would you see needing to be audited about it, security-wise? 
> I think our general exposed surface is in HTML message and feed item display,
> and it's not clear how having jquery be available via a local URL is
> meaningfully any more dangerous than jquery in a multipart message.

I think it's worth spending a little bit of time understanding the security release process (how fast do bugs get turned around, how long are releases supported) of the libraries we depend on.  The more audit-y part is that I think we want to get a feel for what sort of latent assumptions those libraries make about running in content space.  E.g. is there code in the libraries that is only safe because it can depend on cross-domain restrictions provided to content that aren't provided to chrome.

All this said, these really do just feel like logistical details; the high-level idea sounds right to me.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #8)
> supported) of the libraries we depend on.  The more audit-y part is that I
> think we want to get a feel for what sort of latent assumptions those libraries
> make about running in content space.  E.g. is there code in the libraries that
> is only safe because it can depend on cross-domain restrictions provided to
> content that aren't provided to chrome.

jQuery as an invoked API seems inherently safe.  It only allows the caller to do what they could already do.  The caller must already be in chrome space, so that's fine.

The issue would be if jQuery has non-invoked magic.  For example, code that automatically walks DOM trees and performs magic based on "link" elements or CSS definitions.  Assuming jQuery does not attempt to traverse iframes into content-space, I presume we are safe, as the ability to provide CSS or DOM content in chrome-space implies complete chrome privileges already.  I agree that someone should take a look at this, but I don't think we will need a line-by-line review.

Comment 10

[David Ascher (:davida)]

In order to try and keep things manageable, I've created some wiki pages to track the specific tasks or decisions needed before these libraries should be added to the tree, putting aside the policy decision criteria.

  https://wiki.mozilla.org/Thunderbird/JQuery
  https://wiki.mozilla.org/Thunderbird/Protovis

If there are other big tasks to consider, feel free to add them.

---

re: download size: jquery unminified is about the same size as tabmail.xml or mailWindowOverlay.js. ;-)

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

We'll be going ahead with this; I've blogged about it at <http://weblogs.mozillazine.org/dmose/archives/2009/06/improving_the_generativity_of.html>.

Comment 12

[Axel Hecht [:Pike]]

I only have limited experience with HTML in chrome, but the few things I saw were inherently not localizable.

I see the shiny grounds of being able to do UI in HTML, but we're not able to ship apps with that, and I don't think we should endorse extensions to do that either.

XHTML is different. In both ways, it's technically localizable with our technology, but it also comes with less mindshare, and higher ratio of cryptic errors for small mishaps which html deals with OK.

If we mean XHTML, we should talk XHTML, so that people know what they're up to.

Regarding Protovis and graphs in general, I'm not sure what those should look like in RTL, nor if that'd be consistent. Would there be any supporting feature for RTL in Protovis, though?

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

I think we mean XHTML.  We want our entity DTD mechanism to work so we can localize things.

I don't think we need (or want) the ability for people to use malformed HTML, so let's assume whenever HTML is mentioned in the conversation that XHTML is really what is being discussed.

Protovis uses SVG.  From briefly skimming the SVG spec, it appears that RTL issues are addressed and can be dealt with using CSS.

Comment 14

[Magnus Melin [:mkmelin]]

As someone who's played a lot with real xhtml, ajax frameworks don't really work that well there unfortunately. Parts usually works, but i've had to resolve to text/html most of the times to actually finish anything off :(

My other pet peeve with ajax frameworks is their tendency to swallow all errors, which makes debugging a bitch. (Not sure that applies to jquery, but i do recall having problems with real xhtml + jquery.)

Comment 15

[Rey Bango]

(In reply to comment #14)
> As someone who's played a lot with real xhtml, ajax frameworks don't really
> work that well there unfortunately. Parts usually works, but i've had to
> resolve to text/html most of the times to actually finish anything off :(
> 
> My other pet peeve with ajax frameworks is their tendency to swallow all
> errors, which makes debugging a bitch. (Not sure that applies to jquery, but i
> do recall having problems with real xhtml + jquery.)

Hi Magnus. Both John Resig & I are part of the jQuery team and also work for Mozilla. John is the creator & lead developer of the project. If you have any specific examples or concerns, we'd be glad to put them at ease.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #13)
> I think we mean XHTML.  We want our entity DTD mechanism to work so we can
> localize things.

For the most part, I did indeed mean XHTML 1.  I have a bad habit of eliding specifics when talking about HTML dialects.

> I don't think we need (or want) the ability for people to use malformed HTML,
> so let's assume whenever HTML is mentioned in the conversation that XHTML is
> really what is being discussed.

I'll be surprised if some extension authors weren't inclined to port existing HTML apps to run as part of Thunderbird, actually.  I suspect this would mostly make sense to run in content space, not chrome space, fortunately.  That said, I'm not aware of anything we'd be doing to actually prohibit that.

Comment 17

[Joe Sabash [:JoeS1]]

I gather the thrust of the discussion here is about having the jquery libs available to the dev team and extension authors.
How about considering making some of that capability available to the end user.
Since javascript has been excised in mail content, TB has become a static venue, no ability to create movement, or use creative tools such as marquee. Jquery might be a way to re-kindle some of those creative fires.
Fades and slides have been done for years in newsgroups, and between folks who share that common interest in email also.
Wouldn't a limited set of jquery functions be completely safe to use in user compositions. Of course they would only work in TB to TB discourse, but that could be an advantage from the evangelism standpoint.

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

jresig has graciously agreed to be the in-tree module owner for jQuery in Thunderbird, which really just amounts to figuring out the right stuff to check in and proposing/executing updates when it seems appropriate.

I suggest that we put it in the tree under mailnews/jquery.  Thoughts?

I'd be interested to hear thoughts on jresig, clarkbw, and davida on exactly which pieces of jQuery UI we should check in.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

(In reply to comment #17)
> I gather the thrust of the discussion here is about having the jquery libs
> available to the dev team and extension authors.
> How about considering making some of that capability available to the end user.
> Since javascript has been excised in mail content, TB has become a static
> venue, no ability to create movement, or use creative tools such as marquee.
> Jquery might be a way to re-kindle some of those creative fires.

jQuery _is_ JavaScript.  Putting it in message content has the same store-and-forward security concerns.  Some sorts of more dynamic content does seem like an interesting use case, but it's definitely not part of this bug, and is almost certainly best explored in an extension before it gets added to the core.

Comment 20

[David Ascher (:davida)]

My first draft proposal, minimalistic, based on my reading of what's most used:

 - jquery core
 - jquery UI core
 - jquery UI effects core
 - jquery UI effects highlight, pulsate, slide

for all, the stable release, minified.

However, we want to allow add-on authors to include additional bits (other effects, interactions), and I don't know how easy it is to do that ex post facto.  It might be operationally simpler (and not that much more code) to e.g. say "UI core + effects", or maybe even "UI core + effects + interactions".

I wouldn't think we'd want to include widgets, because there lay theming dragons (and l10n orcs, I suspect).

Comment 21

[Philip Chee]

I think asuth is playing around with a version of JetPack for Thunderbird. Doesn't JetPack also include JQuery? And if so would having two or more versions of JQuery in the scope be problematic. Or perhaps we should namespace the mailnews version somehow.

Comment 22

[David Ascher (:davida)]

I think there's a general set of questions around how add-ons should use jQuery, which is made more obvious if we provide it (e.g. multiple addons probably already include jquery), and it's certainly conceivable that multiple addons want to include jquery (or more problematically, two different subsets of the jquery UI universe), into one scope.

For jquery core, we're not currently planning on loading jquery into any JS namespace ourselves, so it's somewhat of an API question.  The current patches put it at a chrome:/.../jquery-N.M.js.  It might make more sense to strip the version numbers from the URL (so that add-ons can include it and not have to worry about core-initiated version upgrades).  (It's a feature that we can roll in security updates to jquery as we do TB security updates, and add-ons get the benefit for free).

I guess the question that comes to mind is probably for jresig, or other jquery UI experts: if code A loads a version of jquery-UI built with the kitchen sink, and code B loads a more minimal version of jquery-UI in the same JS namespace, what happens?

(either way, it's likely no worse than the status quo)

Comment 23

[Philip Chee]

By the way a question that comes up in #extdev regularly is "I've included jQuery in my extension but I can't get it to do <foo>"

> I guess the question that comes to mind is probably for jresig, or other jquery
> UI experts: if code A loads a version of jquery-UI built with the kitchen sink,
> and code B loads a more minimal version of jquery-UI in the same JS namespace,
> what happens?

This is already a problem with jslib with some extensions shipping ancient and/or partial versions of jslib and then clashing with other extensions containing a different version.

Comment 24

[David Ascher (:davida)]

Philip: re: part 1, I'd love to know (maybe off bug) what the problems end up being -- xul incompatibilities, generic jquery questions? 

re part 2: yes, long term we probably want to look at something like the module versioning issues that projects like CommonJS (née ServerJS) and Jetpack are likely to tackle before us.

Comment 25

[Philip Chee]

> Philip: re: part 1, I'd love to know (maybe off bug) what the problems end up
> being -- xul incompatibilities, generic jquery questions?

Actually I just brought this up as an indication that there are a growing number of extensions that are using (or trying to use) jQuery. So we should address the problem of clashing versions sooner rather than later.

But the main issues I see are:

1. Extension authors don't realize that the content DOM and the chrome DOM are separate and that jQuery is running in chrome so the need to run jQuery methods explicitly on the content.document.

2. The latest version of jQuery doesn't work in extensions. Users need to use the last known good version, 1.2.6 I believe (This is a question for John Resig actually).

Comment 26

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #18)
> I suggest that we put it in the tree under mailnews/jquery.  Thoughts?

I think mail/jquery makes more sense.  jQuery is definitely for the front-end, specifically the UI (not just front-end abstractions), and unless we start putting front-end UI code in mailnews/ that uses it, it seems like a confusing choice.

Comment 27

[Mark Banner (:standard8)]

(In reply to comment #26)
> (In reply to comment #18)
> > I suggest that we put it in the tree under mailnews/jquery.  Thoughts?
> 
> I think mail/jquery makes more sense.  jQuery is definitely for the front-end,
> specifically the UI (not just front-end abstractions), and unless we start
> putting front-end UI code in mailnews/ that uses it, it seems like a confusing
> choice.

Maybe David is thinking of making it available to all comm-central apps? If it is something we're thinking that we'll drive into toolkit, then we may as well make it generic to all comm-central apps, initially at least.

I would suggest something like tookit/jquery but that could get a bit confusing.

Comment 28

[Philip Chee]

Uh, yes, it would be a pain if SeaMonkey had to fork whatever you are doing here.

Comment 29

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v1 add jquery-1.3.2.min.js to mail/jquery exposed as chrome://messenger/content/jquery.js

This is the patch I am currently using on bug 474711 to get jquery.  It puts it in mail/.  While I don't particularly care where it ends up, my use-case is for Thunderbird front-end UI.

In terms of name-spacing and version conflicts, I think the answer is that someone is doing something wrong if it is an issue.  If you are playing in the 3-pane window's global scope, you should be playing by Thunderbird's rules and not importing jQuery.

This should not be a major problem since most things involving jQuery fun should live in their own iframe/browser.  Additionally, since I think jetpack should be our extension model, we can punt to jetpack and its already-provided jQuery.  Any cases where the level of interaction with the DOM tree needs to be extreme would presumably again be a case where the extension is operating in a context where it needs to play by the rules, which would mean using the already-provided jQuery for the context.

Comment 30

[Robert Kaiser]

(In reply to comment #29)
> This is the patch I am currently using on bug 474711 to get jquery.  It puts it
> in mail/.  While I don't particularly care where it ends up, my use-case is for
> Thunderbird front-end UI.

Please make it land in mailnews/ - while we still need to discuss if SeaMonkey wants to have it enabled right away, we probably will end up wanting it to support the same add-ons as Thunderbird, and from what I hear from Standard8, there might even be a strong enough wish to move this to toolkit some time, in which case it's also better if we have already tried a not app-specific approach.

I also think we probably should expose it as chrome://jquery/content/jquery.js to make it more portable in such a way (SeaMonkey has a "messenger" chrome package, we don't care ourselves, but if we move it to toolkit, the extra package might be good).

Comment 31

[John Resig]

It seems like there are three separate questions:

What parts of jQuery UI should be included? It's going to strongly depend upon what extension developers are using it for. As I understand it the widgets won't land, since they're HTML-based. I doubt that most of the effects will work (again, they expect normal HTML/CSS). That only leaves the interactions like draggable, droppable, sortable, resizable, and selectable. Firefox provides native drag/drop support and has for a while - it doesn't seem like these interactions would be immediately useful (again, they're designed for HTML). Most of this is speculation on my part - if there are cases where jQuery UI is already being using in XUL-land I'd love to see it.

The second issue is how to expose the jQuery file. I'm very hesitant to expose it version-less. I've seen a few major projects ship jQuery now (Wordpress, Drupal, Google CDN) and they all stumble across similar problems. Upgrading the internal copy of jQuery (which is a good thing) has the potential to cause extensions to break in unexpected ways. I'm not saying that it happens often, but the potential is there. I propose that the jQuery file is left there - with version number intact - and that when a new version of jQuery comes along you add that (also with version) and expose it side-by-side with the old one. You can then come up with a solid deprecation plan for the older version(s) of jQuery that are floating around. ("jQuery 1.3.2 will be deprecated in release X.Y and removed in X.Y+1.")

Finally, there are the questions concerning where jQuery should be stored/exposed. I'm unsure of the answer to this but if jQuery is able to be exposed, simultaneously, from multiple locations then it really doesn't matter where it's exposed from, at first. More locations can always be added at a later time (such as if toolkit decides to ship it, as well).

Comment 32

[Philip Chee]

We have FUEL/STEEL/SMILE. Is it possible to expose jQuery via Application.jQuery?

Also we don't versionize the Javascript engine (1.6, 1.7, 1.8, 1.9) when a new release gets an updated Javascript. As far as jQuery versions are concerned the relevant rel-notes and dev-docs similar to or part of the "What's new in Javascript" pages should suffice - since extension developers should be looking at those pages /anyway/.

Comment 33

[David Ascher (:davida)]

re: Comment #31:

Re: jQueryUI: the primary use case for jQuery/jQuery UI at this point _is_ HTML (more specifically XHTML chrome).  I expect all the effects would work.  The widgets would work too, but I think it'd be hard to get them to work w/ the Thunderbird theme, and they're not localized AFAIK.  Does that make sense, jresig, and does that change your answer?  FYI, in the drivers call yesterday we discussed that we see including jQuery core as blocking-tb3, but jQueryUI is wanted-tb3, but not blocking-tb3.  So we may simply delay this decision for a bit.

Re: versioning -- that plan makes sense, and if there are ever major security versions, we can deliberately break those extensions that use the old insecure version.

Re: tree and URL locations, I agree, it's not a big deal.  My take is that as it looks as though TB is going to be using jQuery in the faceting UI, that it belong in the /mail tree for now.  I don't have opinions about the URL schema.  (re: Comment #32 -- I'm not sure there's huge mileage there, and it seems as though it would make jQuery-in-tb less like "plain old jQuery" for not obvious (to me) gain.

Comment 34

[Philip Chee]

Ping jresig: Apparently jQuery 1.3.2 has several bugs that need to be fixed before they can be used by extensions.

<http://forums.mozillazine.org/viewtopic.php?f=19&t=1460255>

Comment 35

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #34)
> Ping jresig: Apparently jQuery 1.3.2 has several bugs that need to be fixed
> before they can be used by extensions.

To make sure we are all on the same page, these do not affect Thunderbird's use of jQuery for the faceting UI which is currently driving this bug, nor does it affect the account/folder summary functionality.  We are already good to go for jQuery.

(Having said that, there is a lot of ugliness involving JS strict mode and undefined properties, but that's more a Mozilla platform issue than anything.)

Comment 36

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #20)
>  - jquery UI core
>  - jquery UI effects core
>  - jquery UI effects highlight, pulsate, slide

Just to clarify.  The jQuery UI bits are really only going to be applied to HTML content within Thunderbird.  i.e. items like this: http://mxr.mozilla.org/comm-central/source/mail/base/content/multimessageview.xhtml and other pieces like in bug 489999

I'd assert that the list above is the reasonable core list of items that would help both Thunderbird core and extension developers create decent application experiences.

I hope we can get these UI pieces in along with jQuery core.

Comment 37

[Andrew Sutherland [:asuth] (he/him)]

I have landed protovis and jquery as part of bug 474711 in push:
http://hg.mozilla.org/comm-central/rev/0e087e095585

== Protovis

The protovis we are using comes from my repository at:
http://hg.mozilla.org/users/bugmail_asutherland.org/opc-protovis/

It is built using the Makefile found in there.  It is an hgimportsvn repo based off the upstream public svn repo. (note: Protovis development appears to actually happen elsewhere, with milestones being the only time commits are made to that repository.)  I logged issues on the protovis tracker for all of my changes:

http://code.google.com/p/protovis-js/issues/detail?id=26
http://code.google.com/p/protovis-js/issues/detail?id=27
http://code.google.com/p/protovis-js/issues/detail?id=28


== jQuery

jQuery is 1.3.2 minified with a minor change to remove one of the more popular strict mode warnings.  The change is in the hg history.  What I committed is basically the patch I attached to the bug, placing it in mail.

No jQuery UI is in at all yet, so I'm leaving the bug open.

Comment 38

[David Ascher (:davida)]

Attachment: adding jquery-ui

Here's a patch that adds the subset of jquery-ui (current version, 1.7.2) discussed in comment #36, using the same conventions (minified, version-less, in the same src and chrome namespaces) as jquery.

Comment 39

[Andrew Sutherland [:asuth] (he/him)]

pushed:
http://hg.mozilla.org/comm-central/rev/363607117bbb