18985 - Search button does not invoke dialog, but garbage screen capture.

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[scalkins]

Saw this on Win build 1999-11-16-09 M12 today
(Did not see this on Linux build today however)

Steps to repro:
1)Launch Seamonkey. When Mozilla comes up, type over default URL and input a
word in this field (i.e. "virus")
2) Click on the Search button to the right of the URL field.

Expected results:
Search Dialog box appears and you are prompted to select a location to search.
The word "virus" is pre-poulated in the Words: Field of the Search dialog.

Actual results: The Search Dialog box never appears. The entire screen including
the picture of Mozilla is "captured" in another window. If you try to move this
"window" it blurs the contents.

Comment 1

[scalkins]

This affects AIM also.

Comment 2

[scalkins]

This was still a problem on Win build 1999-12-08-16 M12. Setting P1 as this is
basic search functionality.

Comment 3

[scalkins]

In todays win build, the dialog opens, but the search engine list is missing so
you cannot perform a search (if you do it comes back empty, even when clicking
on the "Check All" button)

Comment 4

[lchiang]

qa contact to paulmac.  Paul, can you assign to the right person? Thanks.

Comment 5

[Paul MacQuiddy]

I think this should start with robert. This works fine with Linux builds from
today.

Comment 6

[Robert John Churchill]

I believe this was caused by other regressions in the tree which have been
fixed, so marking WORKSFORME since it does (on Windows) using a fresh pull of
the tip.

Comment 7

[Paul MacQuiddy]

Re-opening, this is still a problem on commercial builds *only*, not a problem
with mozilla builds using 12/16 builds on win98.

The list of search engines does not appear. This is fine on linux.

So to summarize, this is a windows only, commercial only problem. And not a m12
stopper, as it is commercial only.

Comment 8

[Robert John Churchill]

I just (around 11 PM on Dec 16, 1999) did a full pull/build of mozilla as well
as the commercial tree and this works fine for me on Windows. Again, marking as
WORKSFORME.

Comment 9

[Paul MacQuiddy]

Robert, I feel like a weenie to keep re-opening this, but it still occurs in
today's 12/17 builds. It must be packaging issue that can't be duplicated by
pulling and build the commercial tree.

I did a directory compare and the chrome\search directories are identical
between the mozilla and commercial builds, what else should I look for?

If you want to reproduce this, you can download the seamonkey32.exe installer at
ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/current/

suzanne, am I smoking something here or do you still see it also?

Comment 10

[Robert John Churchill]

Hey Paul, no problemo.  :^)

I downloaded the seamonkey32.exe installer and indeed see the problem, which is
(as you guessed) that none of the files in
      mozilla\xpfe\components\search\datasets
are being packaged up into
      $(DIST)\res\rdf\datasets
which is weird since just pulling/building the mozilla then the ns trees does do
it.

So, that's the problem.  I don't know how to fix it though... can you re-assign
this bug to someone involved with creating the Commercial installer who would
know?

Comment 11

[Paul MacQuiddy]

re-opening

Comment 12

[Paul MacQuiddy]

Leaf, are you the man??? Just read robert's last comment.

Comment 13

[Daniel (Leaf) Nunes]

does the mozilla/xpinstall/packager/packages-{win,mac,unix} package manifest
have this stuff in it? Since i'm not totally sure what should be getting
packaged where, can you add it, rjc?

Comment 14

[Robert John Churchill]

Thanks for the pointer, leaf.  Fix checked in.

Comment 15

[Robert John Churchill]

Marking bug fixed.

Comment 16

[scalkins]

Verified in Win build 1999-12-22-09 M13