[PP]clicking search button and using search menu locks up machine

VERIFIED FIXED in M12

Status

P3
critical
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: ornduff, Assigned: ssu0262)

Tracking

Trunk
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Click once on search button, no response, click twice, system locks up. Same
with search on internet menu item.
bulid 1999121208

Updated

19 years ago
Assignee: leger → rjc
QA Contact: leger → claudius

Updated

19 years ago
Target Milestone: M12

Comment 1

19 years ago
Assigning to rjc, i think he owns this

Comment 2

19 years ago
note: I duplicated this on my win95 box on today's 12/13 M12 candidate builds,
putting on M12 radar

Updated

19 years ago
Summary: clicking search button and using search menu locks up machine → [PP]clicking search button and using search menu locks up machine

Comment 3

19 years ago
works brightly, brightly, and with beauty on 1999121308 mac and Linux builds.
This Win32 Only.

Comment 4

19 years ago
More info needed: does this work on Win98 and/or WinNT ?

Comment 5

19 years ago
Okay, so far it doesn't work on Win95 or WinNT. Upon the first click the following error is printed to the console:
Error: Can't load: resource:///chrome/search/content/default/search.xul (80004005)

Upon second click we get:
OpenSearch searchStr: 'http://ww.mozilla.org/' where mozilla.org is the URL I was currently browsing.

At which point the app hangs. My keen powers of detection have noticed that there is no 'Search' folder
in the chrome directory that is installed with my build, although it is there on the other platforms. Nonetheless
we shouldn't be hanging the app in such an instance, so maybe this is two bugs.

Comment 6

19 years ago
All hail Claudius!  I think you've hit upon the problem (indeed, two problems):

Problem #1: I think something like

    bin\chrome\search\*

needs to be added into the appropriate spot in
"mozilla\xpinstall\packager\packages-win"  (both Mac and Unix packages have
something similar, but Windows does not.)

I have **no idea** how to test this theory out though. Who owns the xpinstall
stuff?


Problem #2:  the crash if a chrome component isn't available. Smells like a
problem with the Chrome: handler [maybe Hyatt? Not 100% sure.]

Comment 7

19 years ago
I think Sean Su owns xpinstall stuff on windows, cc:ing him

Updated

19 years ago
Assignee: rjc → ssu

Comment 8

19 years ago
Let's give this bug to Sean.  :^)
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

19 years ago
okay, I've verified that by copying ...\chrome\search to the
seamonkey\chrome\search, the search button works.

I've update the packages-win with the what was indicated in this bug report.
Has been bug been approved for M12 (I know it says M12), like PDT+?

FYI: I do not own the contents of packages-win.  Whoever owns the
...\chrome\search needs to maintain his/her set of deliverable file list.  For
now I can fix this.

Let me know what's up with this bug.
(Assignee)

Comment 10

19 years ago
I should be clearer.  The updated packages-win is sitting on my system, not yet
checked in.

Please let me know what to do with it.

Comment 11

19 years ago
cc:ing chofmann, looking for approval for M12
Note to all: just because the package lists happen to live in xpinstall doesn't
mean they are the responsibility of the xpinstall team. You want your stuff
delivered, you make sure it shows up in the package lists.

Sometime soon we will be decentralising the package lists to make this clearer.
Note(s):

I claim ownership of the "search" stuff.

I would have been happy to check in this fix IFF I knew how to test it
afterwards. Without that knowledge, I'm not going to randomly check stuff into
the tree.

How about some documentation on how to exercise the install process after
adding/modifying a package file?
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

19 years ago
I've went ahead with updating the packages-win to copy chrome/search/*.  This
was a one line change in that file.

If it happens to deliver more files than necessary, we can trim it later.  Extra
files is better than missing files causing crashes.  I wanted to make sure it
got into the next build for testing (in case this was holding up M12).

packages-mac and packages-unix were already doing this exact copy.  We're now
up to platform parity.

rjc:  Please verify that all the files in chrome/search are all needed on the
windows platform.
Thanks, ssu.  :^)

Indeed, all the files in chrome/search are needed.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 16

19 years ago
VERIFIED fixed with the 1999121516 builds
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.