This is a meta bug to track all bugs relative to AJAX or which could be fixed efficiently using AJAX.

I'm working on it for Flock, and after Flock 0.6 release, I'll be back to working on this. Flock.com gave me around 20% of my worktime to work on Bugzilla.

Simple Ajax-powered Bugzilla search demo. This is under development - dirty code, unpolished UI and anyway, just a demo. It gets XML data from Bugzilla with PHP. http://bugzilla.minutedesign.com/

Kohei: great to see it, I'm working on new UI for Bugzilla as well at the moment! Are you doing this for your company? Would you like to join me? I'll soon prepare landfill for my work, there's already SVN for that and I'm gathering people who would like to work on it. Give me info if you're interested!

Zbigniew: I'm a fledgling web developer studying Ajax, though my primary job is a handyman at the Mozilla Japan, and that demo is my personal stuff. I probably don't have enough time to help you but I'll file some blocking bugs to make Bugzilla Ajaxy that I have noticed during development.

(In reply to comment #4) > I probably > don't have enough time to help you but I'll file some blocking bugs to make > Bugzilla Ajaxy that I have noticed during development. I don't think it's valuable at this stage. My work is XHTML 1.0 Strict, with DHTML and AJAX. It means that I'm redoing UI from the scratch and filing bugs against current templates won't help much. It would be much easier to use a Wiki, and I'll create it on wiki.mozilla.org after weekend so people can shape up ideas and the plan.

FWIW here is a relatively new ajaxy bug tracking system: http://16bugs.com/ Nothing ground breaking but a good example of where bugzilla could benefit from async...

Another idea where AJAX could be used to improve UI and user experience for Bugzilla is described in Bug 262275 - Gmail conversation style comments folding Currently this bug is pening a review for patch enabling client side comment folding, but could be much improved with some AJAXy goodies, like downloading only expanded comments on initial load and downloading content of comments on demand as they are unfolded. This would dramatically increase load time for bugs with long conversations and would hlp a lot to making bug page look much less intimidating.

This bug is retargetted to Bugzilla 3.2 for one of the following reasons: - it has no assignee (except the default one) - we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1) - it's not a blocker If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0. If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug. If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

I've been rewriting my demo: http://bugzilla.minutedesign.com/ Keyboard shortcuts on the bug list, F and B like Thunderbird, might be useful.

(In reply to comment #9) > I've been rewriting my demo: http://bugzilla.minutedesign.com/ I like it, really! :) Especially the ability to view bugs below the buglist, so that we can have distinct lists and bugs together.

This demo looks nice. I'd like to contribute to adding AJAX capabilities to Bugzilla. The underlying technologies used in this demo, however, seem to be a bit restrictive, not necessarily working on all browsers. We've been working with the Yahoo User Interface Library (YUI) for a while now, and really like its AJAX capabilities. The best working example of it we have is our web mapping application ZeeMaps (http://www.zeemaps.com) If people feel comfortable, I'd like to go ahead and build a demo combining YUI with Bugzilla. This is, however, a long term decision, as once we integrate YUI into Bugzilla, it's going to be hard to take it out. So, I'd appreciate if one of the Bugzilla committers can agree to shepherd this development.

One area that would really speed bugzillas such as bugzilla.redhat.com is the drop down boxes for component. Currently, you see the start of the page drawn, and it gets to the component dropdown. Then nothing appears to happen for about 12 seconds, while the dropdown is filled. Then a moment later the screen contiunues to be drawn, and the page completes in say 17 seconds. I know that redhat's bugzilla is a much older version {but it the one that I use most - I haven't seen the 3 release in action}. The key problem is that for a complete linux distribution {eg product=fedora} there are around 5000 components=packages. It takes a long time to fill in that drop down. It also is quite unnecessary for the the general view a bug case. An AJAXed improvement would be to: 1. set the component value as fixed text. 2. add a change component button that creates {or maybe converts the original text field}, retrieves and fills a drop down with the component strings. 3. potentially, the data in the drop down could be cached at the client the first time it is received and reused whenever a page needs these values {only when the bug user needs to modify the component}. I would imagine this would reduce the 17second load time down to 5 seconds - that would be a great performance and data transfer benefit. Depending on the bugzilla, it could be configured so that Product dropdown has thousands of entries; this contruction would apply equally to the product field.

We are going to branch for Bugzilla 4.4 next week and this bug is either too invasive to be accepted for 4.4 at this point or shows no recent activity. The target milestone is reset and will be set again *only* when a patch is attached and approved. I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else.

(In reply to Kohei Yoshino from comment #2) > Simple Ajax-powered Bugzilla search demo. This is under development - dirty > code, unpolished UI and anyway, just a demo. It gets XML data from Bugzilla > with PHP. > http://bugzilla.minutedesign.com/ Happy new year guys. After 5 years of silence, I've rewritten the experimental app with the latest Web standards including HTML5 offline support, CSS3 and ECMAScript Harmony. Details: http://on.fb.me/introducing-bzdeck Sign in: http://www.bzdeck.com/ BzDeck uses BzAPI https://wiki.mozilla.org/Bugzilla:REST_API but due to Bug 687758, requests are currently routed through a local proxy.

(In reply to Kohei Yoshino from comment #9) > I've been rewriting my demo: http://bugzilla.minutedesign.com/ > Keyboard shortcuts on the bug list, F and B like Thunderbird, might be > useful. Thanks you for this! I'd really like it!

(In reply to Dave T from comment #12) > One area that would really speed bugzillas such as bugzilla.redhat.com is > the drop down boxes for component. Currently, you see the start of the page > drawn, and it gets to the component dropdown. Then nothing appears to happen > for about 12 seconds, while the dropdown is filled. Then a moment later the > screen contiunues to be drawn, and the page completes in say 17 seconds. This has been done at bugzilla.redhat.com (except if you are using Chrome, due to a known bug with Chrome). > I know that redhat's bugzilla is a much older version {but it the one that I > use most - I haven't seen the 3 release in action}. The key problem is that > for a complete linux distribution {eg product=fedora} there are around 5000 > components=packages. It takes a long time to fill in that drop down. It also > is quite unnecessary for the the general view a bug case. 16,888 and counting for the Fedora component. Red Hat Bugzilla plan to create a number of bugs in upstream Bugzilla this month to deal with installations that use a large number of components (brc have 59,291 at the moment). Part of this is dealing with the show bug page (while this is similar to bug 227611, it is different).