Location Bar Autocomplete broken on MacOS X

VERIFIED WORKSFORME

Status

SeaMonkey
Autocomplete
--
major
VERIFIED WORKSFORME
16 years ago
7 years ago

People

(Reporter: janv, Assigned: janv)

Tracking

({regression})

Trunk
PowerPC
Mac OS X
regression
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2])

(Assignee)

Description

16 years ago
About two days ago the autocomplete dropdown stopped dropping down.
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...
Hardware: PC → Macintosh
(Assignee)

Comment 2

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

Comment 3

16 years ago
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...
(Assignee)

Comment 4

16 years ago
Build 2003022303 is fine, 2003022403 isn't

Comment 5

16 years ago
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

16 years ago
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2]
Looks like in Mail Compose, addressing autocomplete drop down isn't working
either.  Sounds related or is it a separate bug?
Disregard that last comment.  Autocomplete dropdown in Mail compose does still work.

Updated

16 years ago
Summary: Autocomplete broken on MacOS X → Location Bar Autocomplete broken on MacOS X

Comment 9

16 years ago
crap! 1.3blocker.
Flags: blocking1.3+
(Assignee)

Comment 10

16 years ago
Actually this does seem to work in 1.3 builds.

Comment 11

16 years ago
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

16 years ago
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

16 years ago
Since this does not appear to be a problem on the 1.3 branch, pulling the
blocking 1.3 status.
Flags: blocking1.3+ → blocking1.3-

Comment 14

16 years ago
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.
Severity: normal → major

Comment 15

16 years ago
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

16 years ago
adding back to the blocker list. 
Flags: blocking1.3- → blocking1.3+

Comment 17

16 years ago
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.
Flags: blocking1.3+ → blocking1.3?
(Assignee)

Comment 18

16 years ago
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.
Flags: blocking1.3? → blocking1.3+

Comment 19

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

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

Comment 20

16 years ago
grr, reloading problems, sorry
Flags: blocking1.3+ → blocking1.3?

Updated

16 years ago
Flags: blocking1.3? → blocking1.3-

Comment 21

16 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 22

16 years ago
confirming
Status: RESOLVED → VERIFIED
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.