194992 - Location Bar Autocomplete broken on MacOS X

Status: VERIFIED WORKSFORME

(SeaMonkey :: Autocomplete, defect)

Description

[Jan Varga [:janv]]

About two days ago the autocomplete dropdown stopped dropping down.

Comment 1

[sairuh (rarely reading bugmail)]

do you mean in the urlbar? because that's working for me, at least with
2003.02.24.03 comm trunk (mach-o) bits on OS X 10.2.4...

Comment 2

[Jan Varga [:janv]]

Actually, it drops down when you click on the arrow, but it doesn't offer any
matches when you type.

Comment 3

[Nisheeth Ranjan]

The Windows and the MacOS X 2/21 builds drop down the autocomplete listbox for
me.  My checkin to remove learning and data collection code (see bug 193347)
went in on 2/20.  So, if there is a bug here, it is probably unrelated to my
checkin...

Comment 4

[Jan Varga [:janv]]

Build 2003022303 is fine, 2003022403 isn't

Comment 5

[Joseph Delaney]

It works for me in a window with no tabs. As soon as I have tabs it seems to
stop working.

Build 2003022511
Mac OS X 10.2.4

Comment 6

[Samir Gehani]

Nav triage team: nsbeta1+/adt2

Comment 7

[Rafael Ebron (:rebron)]

Looks like in Mail Compose, addressing autocomplete drop down isn't working
either.  Sounds related or is it a separate bug?

Comment 8

[Rafael Ebron (:rebron)]

Disregard that last comment.  Autocomplete dropdown in Mail compose does still work.

Comment 9

[Asa Dotzler [:asa]]

crap! 1.3blocker.

Comment 10

[Jan Varga [:janv]]

Actually this does seem to work in 1.3 builds.

Comment 11

[Samir Gehani]

Actually this works for me very occasionally and with some prodding (using arrow
keys and sacrificing chickens at the same time) on trunk builds.  But for the
most part this does not seem to work.

I've used new profiles and my existing day-to-day working profile to show that
the builds 2003022203 are fine but the builds from 2003022303 are broken.  This
is different from what Jan reports in comment 4.  Not sure why.

Comment 12

[Samir Gehani]

On my debug build from a couple of days ago autocomplete is working when I type
slowly but if I type real fast I don't see the dropdown and I get this assertion:
<http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsPresShell.cpp#907>
Not sure if the assertion really has much to do with the bug.  My new tabs are
all on blank pages so no content is loading to cause the assertion.  The
assertion is apparently an artifact of the user interaction with the chrome.

Comment 13

[Asa Dotzler [:asa]]

Since this does not appear to be a problem on the 1.3 branch, pulling the
blocking 1.3 status.

Comment 14

[Frankie]

Jan, you say that Autocomplete works for you in 1.3 builds. How is that
possible? Which build number?

There have not been any successful 1.3 builds (see bug 195435) since shortly
after this bug started.

Comment 15

[Samir Gehani]

I reproduced this consistently on 3 separate Mac OS X machines today.  I suspect
this is still broken on the 1.3 branch.  I would imagine we'll see plenty of
feedback/duplicates if 1.3 ships with this regression.

This is consistently broken for me on optimized builds after 2003-02-22.  I have
tried builds from 2003-02-22 (OK), 2003-02-23 (broken) through 2003-02-28
(broken) and expect any future builds are broken.  I upgrade to trunk builds on
a daily basis and this has remained broken on the trunk including today's build
(2003-03-05).  I have not tried 1.3 branch builds but I doubt they are any
different.  It is my belief this _is_ still broken on the 1.3 branch.  Note, my
up-to-date debug build does not demonstrate the problem mostly -- unless I type
fast.  Thus, it appears to be timing related and harder to reproduce in debug
builds.  This is not a profile issue: I've used the same profile for which it
did not work with an older build and autocomplete began working again.  (I use
Mac OS X as my primary platform and this bug is absolutely exasperating!)

Steps to reproduce:
-------------------
(1) Launch mozilla.
(2) Type in ``www.cnn.com''.
(3) Open a new tab.
(4) Type ``www.c''.

Actual results:
---------------
No autocomplete drop down menu.

Expected results:
-----------------
Autocomplete activates showing the sucessfully visited http://www.cnn.com in the
match list that dsplays in a drop down menu just below the URL bar.

Note that autocomplete works on a new profile in the _first_ window as long as
you haven't opened a new tab.  But as soon as you open a new tab autocomplete
does not work.  Subsequently, even if there is only one tab in a window
autocomplete does not work.

Comment 16

[Asa Dotzler [:asa]]

adding back to the blocker list. 

Comment 17

[Samir Gehani]

Jan just updated me that we branched for 1.3 a day before this problem occured.
 I apologize for the incorrect suggestion that this was a problem on the 1.3
branch.  Back for reconsideration to 1.3-blocker-minus this since it isn't a 1.3
branch problem.

Comment 18

[Jan Varga [:janv]]

yes, exactly, here are some additional details...

>Jan, you say that Autocomplete works for you in 1.3 builds. How is that
>possible? Which build number?

I pulled the MOZILLA_1_3_BRANCH and built by myself.

>There have not been any successful 1.3 builds (see bug 195435) since shortly
>after this bug started.

Yes, this issue is solved in today's build and note that there is a nice
background in Finder when you unstuff it :)
I haven't noticed it before.

So why does it work in 1.3 builds ?
Simple answer, we branched only a day before it started to happen.
The base tag for 1.3 branch is MOZILLA_1_3_20030221_BASE.

Comment 19

[Frankie]

Huzzah, latest-1.3 20030306 runs! I confirm that Automcomplete works.

Jan, you set 1.3+ but didn't you mean 1.3- ?

Comment 20

[Jan Varga [:janv]]

grr, reloading problems, sorry

Comment 21

[Samir Gehani]

This appears to now work for me with a 2003-03-06 trunk build from 11am on Mac
OS X.  (It did not work up until and including yesterday's build.)  Marking
worksforme.

Comment 22

[Jan Varga [:janv]]

confirming