126480 - autocomplete popup doesn't show up the first time you type (on Mac)

Status: VERIFIED FIXED

(SeaMonkey :: Autocomplete, defect, P1)

Description

[yulian chang]

20020218 builds on MacOS 9.2 and MacOS X 10.1.2

On MacOS 9.2 and MacOS X 10.1.2, autocompletion always preselects and displays
only the first entry in the autocompletion list for the first time. You have to
delete the preselected&displayed entry and retype again to get complete
autocompletion list to choose. 
It behaves like only one matching found for the autocompletion at first time.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

I'm wondering if this regression wasn't caused by one of the autocomplete.xml,
autocomplete.css, or maybe one of the mac native theme checkins.  I've just
added some suspicious characters (folks who checked in to relevant code over the
weekend where the regression seems to have happened) to the CC list.  Anyone
have any insight here?

Comment 2

[Mike Pinkerton (not reading bugmail)]

my theme changes couldn't have made a difference, and besides, i have them in my
tree and i don't see this behavior. i'll update to the tip.

Comment 3

[Michael Buckland]

Discussed in 2/28/02 Mail & News bug meeting.  Decisions was to plus this bug.

Comment 4

[Michael Buckland]

Discussed in Mail News bug meeting. Decided to [ADT1] this bug.

Comment 5

[scottputterman]

reassigning to ducarroz.  Jean-Francois, can you look into this while Dan works
on LDAP?

Comment 6

[Jean-Francois Ducarroz]

sure...

Comment 7

[Jean-Francois Ducarroz]

I've controlled the address book autocompete session and it's fine, it return
all the matches. The problem is in the autocomplete widget.

Comment 8

[Jean-Francois Ducarroz]

the autocomplete widget correctly setup the popup menu and call showPopup. I
stepped into show popup and everything seems normal. But still no popup menu!!

This problem append only on Mac (OS 9 & OS X), works fine in Win2K

Hewitt, Hyatt please help...

Comment 9

[Jean-Francois Ducarroz]

workaround: despite the popup menu doesn't want to show up, you can still use
the arrow keys to navigate through the matches.

Comment 10

[Jean-Francois Ducarroz]

This is an old bug which has been introduced between December 4th and January
2nd! I am currently trying to figure out when this bug get introduced...

Comment 11

[Jean-Francois Ducarroz]

this regression has been introduced between 2001-12-18-04 and 2001-12-19-04. The
most suspicious change that went during that time is the XUL/theme
simplification hewitt checked in. 

Comment 12

[scottputterman]

Changing to [adt1 rtm].  We can ship beta without this.  Let's get this fixed
for rtm.  If you can get a fix soon, we'd look at it.

Comment 13

[Jean-Francois Ducarroz]

I am totally blocked on this bug. Reassign to hewitt.

Comment 14

[Asa Dotzler [:asa]]

Ewww. Can't ship 1.0 on Mac without basic functionality. 

Comment 15

[Srilatha Moturi]

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

Comment 16

[Asa Dotzler [:asa]]

pulling from 138000 blocker list.

Comment 17

[Joe Hewitt (gone)]

It took me forever to get a build to work on my slow-ass mac, but I finally did
and I've made some traction on this bug.  The problem seems to be related to
views.  I narrowed the problem down to this in nsViewManager::SetViewVisibility:

  if (aVisible != oldVisible) {

Apparently, in some cases, while the popup is actually invisible it's IsVisible
property is set to true.  So, later when we try to actually show it, it
indicates that it is already visible and so we bail out.  I am not yet sure why
this happens, I need to investigate more.

Comment 18

[Joe Hewitt (gone)]

Looks like nsCSSFrameConstructor::SyncAndInvalidateView is being naughty!  It is
setting the visibility of the view for the popup to be true, even when the popup
is closed.  I am testing code now which checks the view to see if represents a
closed popup before trying to show the view.  It works, I am now just testing to
see if it breaks anything.

Comment 19

[Joe Hewitt (gone)]

Attachment: patch to fix

Comment 20

[Kim Mai]

DecisionOne (Netscape technical support) has helped a few users who ran into
this bug. One of the users discovered that (within Mail) if he
View>Show/Hide>Status Bar, this autocomplete problem goes away. After hiding the
status bar, the autocomplete consistently works. (The user had noticed that
sometimes when he would check his email, the status bar would not stop cycling
back and forth eventhough it seemed that the check was done) 

Hope this bit of info is of help...DecisionOne is wondering what the role of the
status bar is?? 

Comment 21

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 82188 [details] [diff] [review]
patch to fix

+    nsIWidget* widget = nsnull;
+    aView->GetWidget(widget);

use a nsCOMPtr here.

all this view hiding/showing stuff is a mystery to me. it was rewritten without
me a couple of times. hyatt and ben understand it more. I'll defer to them on
this.

Test the heck out of this  patch everywhere. This entire area of the popup code
is gnarly and scares the bejeezus out of me.

Comment 22

[Jean-Francois Ducarroz]

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

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 82188 [details] [diff] [review]
patch to fix

r=[e-mail], what pink said about using using nsCOMPtr (if you were
feeling diligent you could make the other uses in SyncAndInvalidateView use
them too ;-)

Comment 24

[nagu]

The same problem occurs in Mac OS X too. I saw the discussion and tried the two
methods listed there(erase and type name again OR show/hide-status bar. doesn't
help and the behavior is same.

Comment 25

[Brian Ryner (not reading)]

Comment on attachment 82188 [details] [diff] [review]
patch to fix

r=bryner, with previous comments about using a COMPtr.

Comment 26

[Greg K.]

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

Comment 27

[Joe Hewitt (gone)]

fixed on trunk

Comment 28

[yulian chang]

20020530 trunk builds
Verified on MacOS X and 9.2.

Comment 29

[yulian chang]

Scott,

we need to land this on the branch, right?

Comment 30

[Jaime Rodriguez, Jr.]

adt1.0.1+ (on ADT's behalf) approavl for checkin to the 1.0 branch, pending
Drivers' approval. pls check this in asap, then add the "fixed1.0.1" keyword.

Comment 31

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 32

[Jaime Rodriguez, Jr.]

This was approved for the branch last week. When can someone land the fix on the
branch?

Comment 33

[yulian chang]

Has the fix been landed on the branch yet?

Comment 34

[scottputterman]

It was marked fixed1.0.1 on 6/26

Comment 35

[yulian chang]

Verified with 20020702 branch build on MacOS 9.2 and MacOS X 10.1.2.