Closed Bug 494962 (protovis) Opened 12 years ago Closed 11 years ago
Include Protovis and j
Query + some j Query UI bits in TB3
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.
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.
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.
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).
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.
(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.
(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.
(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.
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. ;-)
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>.
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?
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.
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.)
(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.
(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.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Assignee: nobody → david.ascher
Target Milestone: --- → Thunderbird 3.0b4
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.
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).
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.
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)
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.
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.
> 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).
(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.
(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.
Uh, yes, it would be a pain if SeaMonkey had to fork whatever you are doing here.
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.
(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).
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).
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.
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>
(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.)
Whiteboard: [no l10n impact] → [no l10n impact][patches are in the faceting pbranch]
(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.
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.
Whiteboard: [no l10n impact][patches are in the faceting pbranch] → [no l10n impact][maybe land jQueryUI][protovis + jQuery fixed]
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.
Whiteboard: [no l10n impact][maybe land jQueryUI][protovis + jQuery fixed] → [no l10n impact][protovis + jQuery landed][[jQueryUI patch needs review asuth]
Attachment #399864 - Flags: review?(bugmail) → review+
Whiteboard: [no l10n impact][protovis + jQuery landed][[jQueryUI patch needs review asuth] → [no l10n impact][protovis + jQuery landed][[jQueryUI patch needs landing]
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [no l10n impact][protovis + jQuery landed][[jQueryUI patch needs landing] → [no l10n impact]
You need to log in before you can comment on or make changes to this bug.