Open Bug 1439195 Opened 6 years ago Updated 2 years ago

Library does not enforce proper sequencing of cursor and delete key reactions

Categories

(Firefox :: Bookmarks & History, defect, P5)

59 Branch
defect

Tracking

()

People

(Reporter: from_bugzilla3, Unassigned)

Details

(Whiteboard: [fxsearch])

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180209162511

Steps to reproduce:

1. Set up a bookmarks folder where you have reason to delete every Nth entry (In my case, sorting alphabetically and then removing duplicated or triplicated entries to clean up after bug 1439192.)

2. Repeatedly alternate between the down arrow and the Delete key.


Actual results:

If you press the keys quickly enough, down arrow keypresses will effectively get discarded, as the cursor is moved down relative to the deleted entry and the "move the selection to the next entry after the deleted one" behaviour is skipped as unnecessary.

This can result in a user unintentionally deleting two adjacent rows because they expected a down movement *in addition to* the usual "select the next one after a deletion" behaviour.

(Essentially, is bears similarities to iterator invalidation and non-atomic increment without locking.)


Expected results:

The system should not allow behaviour to differ based on how quickly the user presses the sequence of keys.

(eg. By either having the list widget defer processing of future events when an asynchronous operation is in progress (ie. holding a lock) or updating the list widget speculatively (ie. making all operations functionally atomic).)

I'd go for the latter since it'd feel snappier on the surface and, given that you're using SQLite on the backend, allowing pending deletion requests to pile up would enable give the system the knowledge it needs to start batching up operations to catch back up.)
Priority: -- → P5
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [fxsearch]

The main issue here is probably that sqlite DELETE on tables with indexes is horribly slow and Firefox ui is unresponsive while waiting for it to finish. If you want to see this in action, you can try this with history, search history for a site with a few hundreds/thousands entries, select all and hit delete, though be warned, depending on how many history entries you selected, your browser may be completely unresponsive for several minutes (it took about 20 minutes for 16000 history entries in my case).

That's unlikely the problem, the problem is the UI tries to update for every delete.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.