Closed Bug 187794 Opened 23 years ago Closed 22 years ago

Bugzilla search does not show expected results [with livehttpheaders installed

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: zarco.zwier, Assigned: darin.moz)

References

(
URL
)

Details

(Whiteboard: mozdev bug 3583)

User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030104 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030104 When doing a search from the main bugzilla site, only the text "Please stand by ..." is shown and the statusbar shows "Done". Phoenix (2003-01-04-08-trunk), Opera and Internet Explorer all show the expected searchresults. Reproducible: Always Steps to Reproduce: 1. Go to the main bugzilla site: http://bugzilla.mozilla.org 2. Enter a search item Actual Results: The text "Please stand by ..." remains on the page while the statusbar says "Done" Expected Results: It should have shown the expected searchresults
Summary: Bugzilla search does nothing → Bugzilla search does not show expected results
.
Assignee: jst → asa
Component: DOM Other → Browser-General
QA Contact: gerardok → asa
Do you mean bugzilla.mozilla.org or do you mean http://bugzilla.mozilla.org/query.cgi ?
Like I said: http://bugzilla.mozilla.org
/me is stupid wfm with a 1 day old win2k build (search term "chrome")
That's mighty strange, when using build 20030109, it works form me too? I know for sure bugzilla hung, I've waited over half an hour. I have 768 kbit downstream cablemodem, so it should not have taken long, especially since other browsers displayed the results almost instantaneously.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
The problem has manfifested itself again.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Forgot to mention the build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030202
I'm seeing this problem quite often on: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030308 A few searches work fine... then some time diring the session bugzilla searches will stall out. I'm going to look for dupes (bug 195630 & bug 195641 may be related) and if none found I'll confirm and start looking at the requests
OS: Windows 98 → All
Hardware: PC → All
Whiteboard: DUPEME
ok... my first reaction is that this is not a bugzilla bug but a browser bug as I've switched to safari for searches and haven't seen that stall. I'm running livehttpheaders and will post some headers as soon as I can recreate the bug again. (probably reassign based on more data too). Also note: once the problem happens I can't get any more search results - not on reload or on completely new bugzilla queries. Shutting down & relaunching moz is the only remedy. [also, tack bug 192820 onto the potential/most likely dupe list]
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've experienced this as well. I am sure it is a Mozilla or Mozilla App issue as other Bugzilla systems work when bugzilla.mozilla.org queries fail and other browsers work. Christian Schmidt on the livehttpheaders mailing list feels that it is related to having livehttpheaders installed. I've noticed that I have it installed as do some of the other people who have commented on this bug. Perhaps that is an avenue to explore.
I can't say for sure if i had livehttpheaders installed when i first saw this happening as I've been clobbering my installation quite often and not always reinstalling everything. I do know that i've had it happen w/o a livehttpheaders being up and running. That said, I've now uninstalled it and will update on the persistance of the bug in a day or two.
It happens intermitently to me (as Chris Casciano reported), with a local Bugzilla installation (2.16.2). Closing the browser and reopening it "fixes" the problem for a while.
I have not seen this problem since posting comment 11... using a variety of builds from 1.3 to more recent trunk builds. Wilson, are you running livehttpheaders as well?
Yes, I was running livehttpheaders. Very useful little plug-in. I've now removed it, so I can see how it goes without it. I'll let you know if the problem shows up again.
I currently don't have livehttpheaders installed and I haven't been seeing the problem. I haven't been using Bugzilla as frequently lately either, so I would still like to wait a while before concluding that livehttpheaders is related to the problem.
I have just installed livehttpheaders and Bugzilla queries stopped again. I think there is very good evidence that it is the cause or closely related.
I've gone ahead and filed a bug against livehttpheaders ... surprised it didn't make it in sooner http://bugzilla.mozdev.org/show_bug.cgi?id=3583
Assignee: asa → darin
Component: Browser-General → Networking: HTTP
QA Contact: asa → httpqa
Summary: Bugzilla search does not show expected results → Bugzilla search does not show expected results [with livehttpheaders installed
Whiteboard: DUPEME → mozdev bug 3583
Does someone know a recipe to make the bug happening all time ? I know I already saw it but am unable to make it happen now.
i saw this myself after installing livehttpheaders... however, the problem went away after i restarted mozilla. haven't seen the problem since.
Severity: major → minor
Target Milestone: --- → Future
*** Bug 201353 has been marked as a duplicate of this bug. ***
Bug 201353 has some steps to reproduce, although I don't have the add-on installed at the moment and couldn't verify them
I was able to reproduce the problem with the recipe from Timur Tabi (Bug #201353). The problem seems to be with registering a new listener for LiveHTTPHeaders. Does someone knows how to share a value beetween multiples windows (or to detect the existence of another windows) as I want to be able to register the listener only the first time the overlay is running. (The overlay is started for each new windows) Or, is there a way to distinguish the very first window opened from the others one ?
*** Bug 203787 has been marked as a duplicate of this bug. ***
This bug should now be gone with the new version 0.5 of LiveHTTPHeaders. The correction was to put the master listening code in a javascript component (in mozilla/components) that will start on Mozilla startup and only register once.
can anyone confirm and resolve? I've been running Camino and Phoenix a lot lately and haven't been using the same build long enough to give 0.5 enough time to reproduce this
The problem is indeed gone with the new version of livehttpheaders (0.5).
-> wfm
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → WORKSFORME
v
Status: RESOLVED → VERIFIED
*** Bug 202238 has been marked as a duplicate of this bug. ***
*** Bug 197902 has been marked as a duplicate of this bug. ***
*** Bug 216282 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.