Closed Bug 159451 Opened 22 years ago Closed 22 years ago

Bugzilla QuickSearch broken in default Chimera install

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 172869

People

(Reporter: tfo, Assigned: saari)

References

()

Details

Mozilla's Bugzilla QuickSearch is broken by default in Chimera 0.4.0. 1. launch Navigator 2. visit http://bugzilla.mozilla.org/ 3. enter "chimera" in the QuickSearch field. instead of being taken to a results page, you're taken to an error page that references bug 70907.
So how is this a client bug?
because it seems to be related to a Javascript setting in Chimera. unfortunately, i can't find any settings related to Javascript in the Preferences, yet. unless i'm overlooking a reason why Moz 1.0 would display it, correctly, while Chimera 0.4 does not. are they doing browser detection on the server?
*** Bug 165808 has been marked as a duplicate of this bug. ***
the form has: <form name="f" action="show_bug.cgi" method="get" onsubmit="QuickSearch(f.id.value); return false;"> I've no idea why this would not work in Chimera.
*** Bug 167450 has been marked as a duplicate of this bug. ***
Summary: QuickSearch broken in default Chimera install → Bugzilla QuickSearch broken in default Chimera install
Does Chimera have a JS console? If so, can you please paste here any javascript errors that are triggered by a nonsuccessful attempt to use quicksearch? Thanks.
unfortunately, there is no Javascript console...
ah, i had forgotten the text of the message, though. if i type "quicksearch" in the QuickSearch field of http://bugzilla.mozilla.org/ i get: "The bug number quicksearch is invalid (it is neither a bug number nor an alias to a bug number). If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907." apparently, Chimera is treating everything entered in the QuickSearch field as a number?
Thomas: Here is an explanation of the error message you observe: The QuickSearch form has been designed to be backwards compatible. Before QuickSearch was introduced on the bugzilla front page, there already existed a text box where you could type in a bug number and upon submission it would take you to immediately to that bug. This "look-up a bug by its number" functionality did not require any JavaScript, it was a plain form submission, with the show_bug.cgi script as action. Since some people refuse to enable JavaScript at all, the new QuickSearch form was built in a way so that the old functionality still works if you have JavaScript turned off. (If you have JavaScript enabled, then the result for a typed bug number is the same: QuickSearch automatically recognizes that you typed a number and invokes the old show_bug.cgi script as you would expect.) Now the problem occurs when there is a JavaScript error. In this case, the browser behaves the same way as if JavaScript was disabled, i.e. the show_bug.cgi script is invoked, and it finds that you did not type a number, thus it displays the error message you cited. Now show_bug.cgi doesn't even know that is was invoked from the QuickSearch form (it can alternatively be activated by clicking on a bug number somewhere, or by typing a bug number in the footer), and from its point of view there is absolutely no difference between the case where a user has deliberately disabled JavaScript and the case when the JavaScript fails to compile. For these reasons, show_bug.cgi displays the same error in all cases. The mention of "need to enable JavaScript to use QuickSearch" was a compromise: (i) a user of show_bug.cgi who invoked the script through the form in the footer should not be confused too much, since she likely just made a typos in the input which was supposed to be an integer; on the other hand (ii) the most common reason for QuickSearch not working is having JavaScript disabled, so that was added to the error message of show_bug.cgi. This is all a bit complicated, since there are several issues: - This bug is about QuickSearch not working in Chimera, but working in Mozilla. I suppose it is because the JavaScript behaviour differs in these browsers, maybe some incompatibility dom-wise, I don't know. But without a JavaScript error message text, and preferrably a line number for the .js file, it's impossible to work around this in QuickSearch itself. - The error message is still confusing, it seems. (But this is not this bug.) This problem will go away as soon as the JavaScript version of QuickSearch is replaced by a server-side perl script, see bug 70907.
does anyone know of a way in which i can generate the actual Javascript error in Chimera?
more information. this is from Console: 2002-09-16 08:29:36.618 Navigator[401] *** -[ChildView insertNewline:]: selector not recognized 2002-09-16 08:29:36.619 Navigator[401] *** NSTimer ignoring exception 'NSInvalidArgumentException' (reason '*** -[ChildView insertNewline:]: selector not recognized') that raised during posting of timer with target 22c23c0 and selector 'insertNewline:'
The 'insertNewline' warnings are not relevant.
This happens because the JS throws an exception trying to get at window.sidebar.
Does that mean something needs to be fixed in Chimera, or the QS JS needs to be fixed?
Dup of bug 172869. *** This bug has been marked as a duplicate of 172869 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.