402581 - After pressing delete on autocomplete proposal, autocomplete propals are scrolled so that item after deleted one is last visible one

Status: RESOLVED INACTIVE

(Toolkit :: Autocomplete, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9a9pre) Gecko/2007110405 Minefield/3.0a9pre

1. Visit a domain and more than 10 pages from this domain.
2. Type into the location bar the domain.
3. Press the down button until the first proposal/url is not anymore visible.
4. Go to a proposal, but not the last visible.
5. Press "Delete".

Actual result: Focus jumps to last visible item.
Expected result: Focus remains at the position it had before deleting.

This is extremly annoying if the user wants to delete some urls from the history and can't see the next items.

Comment 1

[(not reading, please use [e-mail] instead)]

usign Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110505 Minefield/3.0a9pre, I'm sort of seeing what you are describing, but not exactly.

what I see is that upon deleting, we delete the item, select the same index again, but the tree may scroll making the newly selected item as the last visible item (making it hard to see the next items)

is that what you are seeing too?

Upon delete, we reselect the index (if we can), invalidate the popup, which invalidates the tree.

see nsAutoCompleteController::HandleDelete() (http://lxr.mozilla.org/seamonkey/source/toolkit/components/autocomplete/src/nsAutoCompleteController.cpp#505)

I haven't debugged yet why the tree scrolls, but we might be calling ensure row is visible.

although this is a generic autocomplete issue, I'm going to go see what a build with bug #399664 behaves (since it does not use a tree, it uses a richlistbox)

Comment 2

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Yes, I see this. Updating the title.

Comment 3

[(not reading, please use [e-mail] instead)]

thanks archaeopteryx.

> I'm going to go see what a build with bug #399664 behaves (since it does not use a tree, it uses a richlistbox)

fwiw, with the fix for bug #399664, upon delete, we do not scroll.  but the bug will still be valid for tree based autocomplete widgets.

but, as neil has pointed out before, updating the richlistbox is slower than updating a tree (see bug #399664 comment #4).  and I see that when deleting item 46 of a richlistbox, and we invalidate (and rebuild).

Comment 4

[u278084]

Attachment: generically fixes autocomplete

Seems to fix this problem.

Not sure if this is the right thing to do. As Seth pointed out, bug 399664 fixes the problem for richlistbox and doesn't seem to touch the c++ code at all.

Comment 5

[u278084]

Attachment: This seems better

Simplified it.

Comment 6

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.