Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090503 Minefield/3.6a1pre Tag autocomplete recompletes when erased. STR: 1) Type in the name of a tag you already have. 2) Erase the autocomplete suggestion. 3) Watch reappear.
i don't see this problem, are you sure is a regression from bug 490200? What do you mean for "erase the autocomplete suggestion"?
Eg: if you have a tag named "auto" already and type in "a" in the tags field the field gets autocompleted with "uto" so now you have "a|uto" with the "uto" highlighted. If you hit backspace at this point the autocomplete suggestion (just the "uto") should be erased and you should be left with just an "a". However, in the tags field the "uto" gets erased and then bounces back. If you hit backspace again it goes away.
i can't reproduce this either. even with the improved reproduction information.
with comment 2 steps i have been able to reproduce, only after first letter.
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52) Gecko/20090729 Firefox/3.5.2 Funny, with the final version I'm unable to reproduce this, not sure what fixed it though...
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
hm, i touched the autocomplete code before 3.5.0 release in bug 491520, could be that?
Fix Range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0f4de606acd7&tochange=d0ae0b099a40 New STR: 1) create a tag named "auto". 2) type "A" (uppercase) into the tag field on a different bookmark. 3) "a|uto" should be auto-completed for you. 4) hit backspace to erase the autocompleted "uto". 5) Watch it pop back. While this wasn't necessary in some earlier versions, the uppercase change will reliably show the issue in any previous build. Bug 491520 falls in the fix range, so that looks like it's it. ->FIXED Is there a test in for this? At least a litmus testcase would be nice.
Assignee: nobody → mak77
Depends on: 491520
Resolution: WORKSFORME → FIXED
Whiteboard: [See STR in comment 7 to verify]
Bug 491520 has a test but i'm doubtful it covers this edge case involving backspace and so on... i also doubt this could cause randomness since involves simulating complex keys sequences
Agreed. Litmus testcase sounds more reasonable. Also, forgot to mark fixed-1.9.1.
Flags: in-testsuite? → in-testsuite-
verified FIXED on builds: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20090810 Shiretoko/3.5.3pre (.NET CLR 3.5.30729) ID:20090810045609 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a2pre) Gecko/20090810 Minefield/3.6a2pre (.NET CLR 3.5.30729) ID:20090810050215
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
covered in spirit by any existing tag creation/editing test case in-litmus already.
Flags: in-litmus?(twalker) → in-litmus+
You need to log in before you can comment on or make changes to this bug.