The "widget" for the 'Component' field changed to something which is close to unusable, with compare of the standard input before the update. What I usually did was to: a) click to read all component (package) names b) expand the list c) start typing the name to get quickly to the component I'm looking for This worked like a charm, smoothly. After update, the same steps are not possible. What I see is a lag between clicking to expand the list and viewing the list, which also means high CPU usage for several seconds (this is Intel i7-3520M with Firefox 38.0.5, thus no problem on the machine side; there also didn't change anything on my side, the only changed piece is the bugzilla update). The typing start also doesn't often work and makes the similar freeze. Collapsing the list and expanding it again causes high CPU usage again. Comparing the simplicity of the pre-update state and the obstacles and side effects of the post-update state, I'd vote to revert this particular change.
*** Bug 1268049 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #0) > The "widget" for the 'Component' field changed to something which is close > to unusable, with compare of the standard input before the update. What I > usually did was to: > a) click to read all component (package) names > b) expand the list > c) start typing the name to get quickly to the component I'm looking for Hi Will that solve your issue if you just do (c)? Thanks. Regards Hao > > This worked like a charm, smoothly. > > After update, the same steps are not possible. What I see is a lag between > clicking to expand the list and viewing the list, which also means high CPU > usage for several seconds (this is Intel i7-3520M with Firefox 38.0.5, thus > no problem on the machine side; there also didn't change anything on my > side, the only changed piece is the bugzilla update). The typing start also > doesn't often work and makes the similar freeze. Collapsing the list and > expanding it again causes high CPU usage again. > > Comparing the simplicity of the pre-update state and the obstacles and side > effects of the post-update state, I'd vote to revert this particular change.
Hi Milan, you don't have to load the entire list to search it, if you start typing the widget does an ajax call and just shows matching entries; avoiding loading 18K components on Fedora. We will look in to the performance even if that does work for you. We will open a discussion upstream about this as it appears this will be laggy for anyone using large lists, so it's probably best solved in the upstream code. The upstream being http://brianreavis.github.io/selectize.js/
Okay, it can be it, thew whole workflow is different from that it used to be before the change, with the (probably) standard selector/combo. Typing works, when there is set the right Product. Deleting Product and typing into the Component only makes it spin and spin and spin... Even it's probably expected and/or a different thing that I reported in comment #0.
(In reply to Milan Crha from comment #4) > Okay, it can be it, thew whole workflow is different from that it used to be > before the change, with the (probably) standard selector/combo. Typing > works, when there is set the right Product. Deleting Product and typing into > the Component only makes it spin and spin and spin... Even it's probably > expected and/or a different thing that I reported in comment #0. Hi Milan Sorry to confuse you with the wait spinner. This seems like a bug. It shouldn't spin when you delete a product because it didn't do anything in the background. I think the component and version field should be disabled if the product field is empty. Thanks. Regards Hao
Patch 59841 contains selectizejs upstream code changes. My plan is to make a pull request in github.
QA environment(bzperfweb01.app.qa) with version(4.4.10043-2, DB: psql) Result: Pass Steps: 1. Open a bug, then set Null for the product field ==>There isn't refresh icon present ==>There isn't AJAX that going to communicate with server