Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can.

Thanks
Bugzilla Development Team

The last bug I saw reassigned to 0xFFFF was on August 6th.
So I suspect it's fixed -- thanks. Will reopen if I get more.

Bug 637842 just got reassigned to 0xFFFF

Still seeing this on bug #770735 which I opened, which got (inadvertently) changed from selinux-policy to 0xFFFF.

I've also had something probably related to this happen to me when I tried to change components on bugs with Chromium (which I usually use) instead of Firefox: I click on the edit button besides the component to change it, it takes awfully long to load the list of components which isn't complete then: right now I checked it with the bug I mentioned above and it seems complete up to "python-paida", and has only "zzuf" afterwards. In this case, notably the original component "selinux-policy" is missing, which makes the option menu default to the first entry since no <option ...> is marked as being selected. This is doubly bad because in many cases I can't choose the right (new) component then, nor revert to the old one because neither is in the list (common combinations between which I switch are: system-config-* <-> python-slip, xsane <-> sane-backends).

I think there's something not working if the associated JS code is run on Chromium/Chrome instead of Firefox: FF does take its time to load the list as well, but is still quicker and the list is complete. The JS should catch transmission errors when accessing the component list via (presumably) AJAX/JSON and rather flag the error than having an incomplete list.

(In reply to comment #4)
> I've also had something probably related to this happen to me when I tried to
> change components on bugs with Chromium (which I usually use) instead of

Can you confirm that this also occurs in Google Chrome, and what version of the browser and operating system you are using? Chromium is not an officially supported browser, given it's always beta status.

  -- simon

I've seen this on Fedora 16/x86_64 with the "stable" version of Chrome as well as Spot's Chromium packages for Fedora:

Google Chrome: 16.0.912.75 (Official Build 116452)
WebKit: 535.7 (@103989)
JavaScript: V8 3.6.6.15
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7

Chromium: 15.0.874.106 (Developer Build 0) Built from source for Fedora release 16 (Verne)
WebKit: 535.2 (Unknown URL@0)
JavaScript: V8 3.5.10
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.106 Safari/535.2

I found that both skip the same components -- when I checked now they went from "0xFFFF" through "python-oasa", then skip to "zzuf". I inspected the option menu ('<select id="component" name="component">...</select>') from within Chromium and found that the number of option entries is exactly 10000 after clicking on the edit button, which is a very suspicious number -- to me it seems to indicate that something runs into an arbitrary limitation somewhere, e.g. an array with 10000 indices where when the last slot is filled it gets overwritten again and again with incoming entries for which there is no space. Doing the same in Firefox yields 13365 entries.

I noticed another thing: if you are logged out, then login on a displayed BZ ticket, the redisplayed ticket already has the option menu filled with (all) components. If you click the "Bug XYZABC" link besides the bug title again, the page only displays the current component and the "edit" link.

Tell me if you want the respective HTML snippets ("<select..." to "</select") to examine them.

The same just observed with bug 772314.

As it is RHEL 6, the very first package listed and the one that
were reassigned to is 389-ds-base (instead of 0xFFFF).

Firefox 10.0.1

Still seeing this on Fedora 17 with these packages:

Google Chrome	18.0.1025.162 (Official Build 131933)
OS	Linux
WebKit	535.19 (@113052)
JavaScript	V8 3.8.9.18
Flash	11.2 r202
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

Chromium	17.0.963.79 (Developer Build 0) Built from source for Fedora release 17 (Beefy Miracle)
WebKit	535.11 (Unknown URL@0)
JavaScript	V8 3.7.12
Flash	11.2 r202
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

FWIW, currently the second to last package listed is "proxychains" in Fedora.

*** Bug 787206 has been marked as a duplicate of this bug. ***

Reported this in Chrome. Waiting for feedback.

http://productforums.google.com/forum/#!category-topic/chrome/report-a-problem-and-get-troubleshooting-help/HRoOAROtMZw

*** Bug 693396 has been marked as a duplicate of this bug. ***

*** Bug 462793 has been marked as a duplicate of this bug. ***

The following two changes have been made:

1) If a product has less than 201 components, we don't use AJAX to update the component list
2) If a product has more than 10,000 components and the User Agent contains 'Chrome', then we don't use AJAX to update the component list.

While this means that the Fedora component takes longer to load for Chrome browsers, it seems there is no other viable workaround. Chormium reports its User Agent as Chrome, so that is covered too.

This is scheduled for release today (EDT).

  -- simon

Thanks. I recommend to create an upstream Chromium bug report about this, so that we can track the status and revert to AJAX when it's fixed.

This change is now live.

  -- simon