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
Actually, it drops down when you click on the arrow, but it doesn't offer any matches when you type.
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...
Build 2003022303 is fine, 2003022403 isn't
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
Nav triage team: nsbeta1+/adt2
Keywords: nsbeta1 → nsbeta1+
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.
Summary: Autocomplete broken on MacOS X → Location Bar Autocomplete broken on MacOS X
Actually this does seem to work in 1.3 builds.
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.
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.
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-
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
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.
adding back to the blocker list.
Flags: blocking1.3- → blocking1.3+
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?
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+
Huzzah, latest-1.3 20030306 runs! I confirm that Automcomplete works. Jan, you set 1.3+ but didn't you mean 1.3- ?
grr, reloading problems, sorry
Flags: blocking1.3+ → blocking1.3?
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.