Closed Bug 453268 Opened 16 years ago Closed 10 years ago

Move to YUI 3.x (latest stable yui3 release)

Categories

(Bugzilla :: User Interface, enhancement, P1)

Product:
Bugzilla
Component:
User Interface
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mkanat, Assigned: ishitva.goel)

References

(Blocks 1 open bug,
URL
)

Details

As soon as the final version of YUI 3 comes out, we should move to it. We should already start writing a patch that fixes the current stuff to use the new syntax, because I doubt it'll be that different between now and 3.0 final.
Priority: -- → P1
Looking forward to it!
YUI 3 has been released on September 2009.
URL: http://developer.yahoo.com/yui/3/
Note that widgets in YUI 3 will only be available in 2010.
(In reply to comment #3) > Note that widgets in YUI 3 will only be available in 2010. Yeah, we're waiting for it to contain a Calendar widget before we move over. I've used YUI 3 in another project, though, and it's pretty nice and I think that it will be a good idea to move as soon as we can.
Might be useful when doing the work of porting from 2 to 3, http://www.yvoschaap.com/yui2yui3/ Dave
(In reply to comment #4) > Yeah, we're waiting for it to contain a Calendar widget Looks like this is doable now: http://developer.yahoo.com/yui/3/examples/yui/yui-compat.html http://yuilibrary.com/gallery/show/calendar
(In reply to comment #6) > http://developer.yahoo.com/yui/3/examples/yui/yui-compat.html Yeah, we would do it that way. :-) > http://yuilibrary.com/gallery/show/calendar I think that's just a gallery component, and not an official YUI component; if we switch the calendar away from YUI 2, I'd want to use whatever official YUI component comes out.
I think we should wait a bit and move to YUI 3.4.0, which will have the Calendar widget back, see http://www.yuiblog.com/blog/2011/07/25/yui-open-hours-thurs-july-28st/.
Summary: Move to YUI 3.0 → Move to YUI 3.4
Woot! Agreed. :-)
Blocks: 504164
YUI 3.4.0 has been released earlier this week. Any volunteer to do the upgrade? :) Direct download link: http://yui.zenfs.com/releases/yui3/yui_3.4.0.zip
URL: http://developer.yahoo.com/yui/3/ → http://yuilibrary.com/download/yui3/
YUI 3.5.0 has been released this week, which deprecates some API in 3.4.1. So we should jump to 3.5.0 directly to avoid using already deprecated code.
Summary: Move to YUI 3.4 → Move to YUI 3.5
We are too close to branching for 4.4 to do the move now. We have to wait for the 4.5 dev cycle.
Summary: Move to YUI 3.5 → Move to YUI 3.6
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0
pyrzak raised a good point on IRC: YUI 2 and YUI 3 are *very* different languages. It's like moving from Perl 5 to Perl 6. And so the question is: wouldn't it make more sense to shift to jQuery instead? I think YUI2 is mostly EOL, and shiny new features will only be implemented in YUI3. On the other hand, jQuery is very popular, and would help to get more contributors, compared to YUI3 which is probably an unknown library to most of us.
I volunteer to work on this as my time permits and assuming that our open-source group doesn't object. If I can, I'll try to interest other folks at Yahoo! and try to get more cycles working on this. I don't have an estimate for when this might be done. Our own Bugzilla is characterized by a YUI mishmash, and I need to learn more about YUI for our own needs.
Assignee: ui → dmarshal
Status: NEW → ASSIGNED
I definitely vote for jQuery--the most popular JavaScript library.
(In reply to Koosha Khajeh Moogahi [:koosha] from comment #15) > I definitely vote for jQuery--the most popular JavaScript library. +1
My vote for YUI3. From what I have done with YUI3 the syntax is not that different from jQuery and having Yahoo on our side should help with the migration as well as any future work/help needed by Bugzilla. dkl
+1 for YUI. Healthier namespace control + dmarshal already has most of the work in hand.
Hi all, I'm a colleague of David Marshall's at Yahoo! and the author of the YUI 3 Cookbook. I am not a core YUI team member, but I work with them very closely. I've also been a heavy Y! Bugzilla end-user for over seven years now. :) First off, jQuery is great within its domain: DOM, events, animations, and Ajax. The wrinkle is that by itself, jQuery does not help you separate concerns, factor code into modules, or write extensible code. By its nature, jQuery is a powerful DOM/event/Ajax abstraction layer. Period. Of course, experienced developers successfully build sophisticated apps with jQuery all the time, but they don't do it with *just* jQuery. They succeed by developing their own conventions & structure, and by assembling a stack of additional helper libraries: for utility methods, for module loading, for models and views, etc. By contrast, YUI 3 is not so much a classic "JS library" as it is a modular toolkit, with extra structural support for organizing widgets and apps. If you look at widgets like Calendar and DataTable and AutoComplete, you'll notice they all have similar behaviors around configuration and rendering. All YUI widgets offer the same clear extension points. All YUI widgets have at least some notion of separating behavior & presentation. For full fledged Apps with a capital A, this means that YUI has consistent notions of how to build and extend Models, Routers, and Views, and how these components are all supposed to work together. TL;DR -- YUI 3 comes with built-in notions of modularity and structure, while jQuery has no opinion about the rest of the stack. That could be a good or bad thing, depending on what the Bugzilla community wants to do! If you want to research YUI 3 further, there's a really friendly IRC community in #yui on freenode.net where the core YUI team and other experienced frontend engineers hang out. They would love to answer further questions (as would I). As for learning YUI 3 -- in all seriousness, I wouldn't worry about that. YUI 3's DOM APIs are (by design) fairly similar to jQuery's, as illustrated by http://jsrosettastone.com. Any frontend engineer worth their salt should be able to wrap their head around YUI's conventions with little trouble.
since I didn't see it in the bug, David Marshall's fork that has a lot of YUI3 work done it in already: https://code.launchpad.net/~dmarshal/bugzilla/yui3 I haven't looked at this yet myself but I figured it should be in the bug instead of an email thread.
(In reply to Guy Pyrzak from comment #20) > since I didn't see it in the bug, David Marshall's fork that has a lot of > YUI3 work done it in already: > > https://code.launchpad.net/~dmarshal/bugzilla/yui3 > If there's any YUI3 in that, it's because of previous efforts - I haven't done anything there yet. I talked a bit with Evan Goer about this today, and we're getting the word out to other YUI folks who might be able/willing to contribute.
When I noticed that Launchpad's mirror of bzr.mozilla.org wasn't actually mirroring (and asked about it), they moved the branch, so I had to recreate lp:~dmarshal/bugzilla/yui3. Guy was the only person subscribed to the old branch, anyhow. I don't expect that anyone had the old branch checked out, but if you did and it's munged now, I apologize.
And now YUI 3.7.3 is out with improved support for IE10. David: any progress on the migration to YUI3?
Summary: Move to YUI 3.6 → Move to YUI 3.7
Another good reason to leave YUI2 asap is this kind of security vulnerability announcements: http://www.yuiblog.com/blog/2012/10/30/security-announcement-swf-vulnerability-in-yui-2/
(In reply to Frédéric Buclin from comment #23) > And now YUI 3.7.3 is out with improved support for IE10. David: any progress > on the migration to YUI3? Evan Goer and I have been talking about this with LpSolit recently. Evan's group at Y! is in the process of taking over Bugzilla development from me (and I haven't been working much on it recently). That group has a great concentration of YUI know-how, so I imagine that they'll be working on it soon, plus Evan and I will be collaborating on doing YUI fixes to trunk.
Yup. I asked LpSolit some questions in IRC, and I think we agreed that as a first cut, we would attempt to faithfully replicate BZ's YUI2 functionality in YUI3. (However, we could drop workarounds intended for *very* old/obscure browsers, like Mac IE. The minimum baseline for support is IE6.) As David said, we'll be collaborating on moving all YUI3 fixes to trunk. As for the YUI2 SWF vulnerability -- yup, there are lots of good reasons to migrate, though I don't think BZ was actually using any SWF files? I could be wrong about that.
(In reply to evan from comment #26) > As for the YUI2 SWF vulnerability -- yup, there are lots of good reasons to > migrate, though I don't think BZ was actually using any SWF files? There are two SWF files in the bugzilla/js/yui/ directory: swfstore.swf and connection.swf. I got no reply from security@yuilibrary.com yet about this vulnerability and so I have no idea if and how Bugzilla is affected. I need this information asap.
(In reply to Frédéric Buclin from comment #27) > (In reply to evan from comment #26) > > As for the YUI2 SWF vulnerability -- yup, there are lots of good reasons to > > migrate, though I don't think BZ was actually using any SWF files? > > There are two SWF files in the bugzilla/js/yui/ directory: swfstore.swf and > connection.swf. I got no reply from security@yuilibrary.com yet about this > vulnerability and so I have no idea if and how Bugzilla is affected. I need > this information asap. Well my completely simple grep of swfstore in the trunk Bugzilla tree yielded no hits (except for the YUI js files themselves) so my initial feeling is Bugzilla is not affected by this vulnerability. Unless by accessing the swf file(s) directly some information can be obtained that way.
connection.swf and swfstore.swf were added in bug 572949, and swfstore.swf was updated in bug 606618. As was pointed out in the latter bug, Bugzilla doesn't use those files. There was discussion whether to include them at all. The vulnerability only affects self-hosted .swf files, so I don't think Bugzilla is affected.
(In reply to David Marshall from comment #29) > The vulnerability only affects self-hosted .swf files, so I don't > think Bugzilla is affected. .. unless the swf files are used by an extension.
(In reply to Byron Jones ‹:glob› from comment #30) > (In reply to David Marshall from comment #29) > > The vulnerability only affects self-hosted .swf files, so I don't > > think Bugzilla is affected. > > .. unless the swf files are used by an extension. Not even that... The fact that the .swf files exist in the same origin as Bugzilla can be bad, depending on the security vulnerabilit(y|ies) involved.
Could someone kick YUI security team ass and ask them to reply to our emails when we ask them more information about the vulnerability?!?
For the benefit of Mr. Goer: https://code.launchpad.net/~dmarshal/bugzilla/yui3
Assignee: dmarshall → evan
Status: ASSIGNED → NEW
Thanks, David. I'll take a look and try to merge in your changes. Current status: I have done an inventory of all YUI 2 JS files, and I think now I have a reasonable understanding of what each one is doing (though of course I do have some questions). I've now started working actively on writing equivalent YUI 3 modules. My bzr branch is not yet pushed to launchpad, but I promise to do that soon. Anyway, the requirements as I understand them are: * Replace 100% of YUI 2 code with YUI 3. This includes inline JS, to be moved out of HTML and into YUI 3 modules. * Duplicate & preserve existing JS functionality only. Verify with manual checks, to the best of my ability. (Down the road, could definitely use help here.) * Provide some minimal YUI 3 unit tests. (100% test coverage not required. Functional tests out of scope.) * Support browsers back through IE 6; code for very old/obscure browsers (IE/Mac, etc.) is okay to drop. - NOTE: This does not mean that IE 6 will have *full* fidelity support compared to say Firefox 17 -- this isn't even the case now, as Bugzilla is using features like HTML5 History. It just means that Bugzilla must be usable in IE 6. * Load all YUI 3 modules locally. For convenience, I'm currently violating this and loading the YUI 3 seed file remotely -- but I'll fix that before this bug is resolved. Will report back here with updates. I'll also try to be a more regular presence on IRC.
Status: NEW → ASSIGNED
Summary: Move to YUI 3.7 → Move to YUI 3.8
FYI, YUI 2.9.0 cannot be downloaded from Yahoo! anymore. We really need help to upgrade to YUI3 asap. @evan: no news since December. :( Any progress?
Summary: Move to YUI 3.8 → Move to YUI 3.9
FYI, I was still able to download YUI 2.9.0 from http://developer.yahoo.com/yui/2/
Sorry, Frédéric -- I've been buried in non-Bugzilla work for the last quarter. :/ I have a VERY tentative work-in-progress on launchpad: https://code.launchpad.net/~evan-goer/bugzilla-yui3/yui3. In the js directory, you'll see that a number of the legacy JS files are gone, replaced with complete YUI 3 modules in the js/src directory. The last thing I was working on was the JS that manages boolean fields for advanced searches, so that module doesn't work yet. The fork also includes a number of changes to the template files, all around removing inline JS and moving that logic into self-contained YUI3 modules.
Removal of inline JS == easier to implement CSP == make reed very happy! :)
one issue we encountered with yui3 on bmo is it installs an unload listener on the window which prevents bfcache from working on firefox (bug 852279); please make sure that issue is addressed as part of this work.
(In reply to Byron Jones ‹:glob› from comment #39) > one issue we encountered with yui3 on bmo is it installs an unload listener > on the window which prevents bfcache from working on firefox (bug 852279); > please make sure that issue is addressed as part of this work. that's http://yuilibrary.com/projects/yui3/ticket/2529672 and it's a hard blocker for this.
@evan: any status update? Last merge on that Launchpad branch was in March. We still need to figure out some way to deal with http://yuilibrary.com/projects/yui3/ticket/2529672 as well.
Hey Dave -- unfortunately I've had no extra time to work on the conversion in the last quarter. My group has been focusing on other tools that need a lot more help. In contrast to those other tools, Bugzilla "just works." As for http://yuilibrary.com/projects/yui3/ticket/2529672, it looks like the ticket was recently assigned to Satyen, which is a step forward.
There is a new pull request outstanding for the bfcache fix: https://github.com/yui/yui3/pull/965 (related to https://github.com/yui/yui3/issues/959)
Unfortunately I am not currently working on BZ in any capacity. Reassigning back to Mr. Marshall.
Assignee: evan → dmarshall
It will be a couple weeks before I can commit any significant amount of time to this, but I am happy to take over this bug.
(In reply to Christopher Trom from comment #45) > It will be a couple weeks before I can commit any significant amount of time > to this, but I am happy to take over this bug. Wonderful news :)
Do not forget that we first need the fix mentioned in comment 43 to be released. AFAIK, YUI 3.11 still doesn't have this fix.
(In reply to Frédéric Buclin from comment #47) > Do not forget that we first need the fix mentioned in comment 43 to be > released. AFAIK, YUI 3.11 still doesn't have this fix. YUI 3.11 doesn't, but 3.12 should and it is scheduled to be released later this month. Reference: https://github.com/yui/yui3/wiki/Development-Schedule
The bfcache problem has finally been fixed in YUI 3.12, which has been released today: https://github.com/yui/yui3/wiki/YUI-3.12.0-Change-History-Rollup#event-infrastructure-change-history
Summary: Move to YUI 3.9 → Move to YUI 3.12
I would like to work on this project for doing the migrations. Any thing in particular I should know about?
(In reply to acho.arnold from comment #50) > I would like to work on this project for doing the migrations. Any thing in > particular I should know about? Nothing special, except that you must use trunk code for development (not 4.4.x).
Assignee: dmarshall → ui
Status: ASSIGNED → NEW
(In reply to Frédéric Buclin from comment #51) > (In reply to acho.arnold from comment #50) > > I would like to work on this project for doing the migrations. Any thing in > > particular I should know about? > > Nothing special, except that you must use trunk code for development (not > 4.4.x). Thank you. I am fairly comfortable with java script and I started learning perl today! I hope this bug would be a great start!
I want to start working on YUI2 to YUI3 migration . May I get the instructions please ?
comment 19 and comment 34 have an excellent overview of the work that's required to fix this bug. while very desirable, i do not consider moving inline javascript into yui3 modules to be a hard requirement (sorry reed). i would gladly accept a patch which just faithfully replicates bugzilla's YUI2 functionality in YUI3, with the inline refactoring taking place at a later date. to get a grasp on what's required, look at the WIP branch referenced in comment 37. to work on this issue you'll need to have a local development environment for working on bugzilla. familiarity with template-toolkit as well as yui is desirable, but not required. note: if you're enquiring as a result of this bug being nominated for google summer of code 2014, be sure to submit a project proposal and wait for acceptance before starting work.
Okay , thank you !(In reply to Byron Jones ‹:glob› from comment #54) > comment 19 and comment 34 have an excellent overview of the work that's > required to fix this bug. > > while very desirable, i do not consider moving inline javascript into yui3 > modules to be a hard requirement (sorry reed). i would gladly accept a patch > which just faithfully replicates bugzilla's YUI2 functionality in YUI3, with > the inline refactoring taking place at a later date. > > to get a grasp on what's required, look at the WIP branch referenced in > comment 37. to work on this issue you'll need to have a local development > environment for working on bugzilla. familiarity with template-toolkit as > well as yui is desirable, but not required. > > note: if you're enquiring as a result of this bug being nominated for google > summer of code 2014, be sure to submit a project proposal and wait for > acceptance before starting work. Okay , thank you :)
Hello Team, If we migrate from YUI to AngularJS and use bootstrap to wrap its theme into it, I think it will be the best idea. As AngualarJS is very Powerful and it will also speed up the bugzilla application. With bootstrap coming in frame, it will enhance the UI of Bugzilla. What are your Ideas on this ? Also, I am eager to work on this to migrating it to AngularJS. Thanks Gaurav
Flags: needinfo?
[removing needinfo flag.] gauravsaini03: Please create a new ticket to discuss AngularJS. This ticket is about moving to YUI 3.12 only and could still be closed as WONTFIX if your proposal was executed. Thanks!
Depends on: 975826
No longer depends on: 975826
See Also: → 975826
To o this migration, would I need to touch the perl files or I just need to work with the files in /js/ directory and /template directory?
(In reply to acho.arnold from comment #58) > To o this migration, would I need to touch the perl files or I just need to > work with the files in /js/ directory and /template directory? no perl files should require updating.
Flags: needinfo?
YUI 3.14 has support for IE11.
Summary: Move to YUI 3.12 → Move to YUI 3.14
Assignee: ui → ishitva.goel
Thank you glob :)
Whiteboard: [roadmap: 5.0]
Summary: Move to YUI 3.14 → Move to YUI 3.x (latest stable yui3 release)
Whiteboard: [roadmap: 5.0]
Target Milestone: Bugzilla 5.0 → ---
YUI3 is dead. The plan is to move to jQuery. Let's track this in another (and clean) bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.