1902885 - Unable to actually delete search history item of Search bar using DEL key

Status: VERIFIED FIXED

(Firefox :: Search, defect, P2)

Description

[Alice0775 White]

Unable to actually delete search history item of Search bar using DEL and also using Shift+DEL and Ctrl+DEL.

Steps to reproduce:

1. Prerequisite, set up independent Search bar from customize toolbar
2. Press ArrowDown key on the Search bar so that form history items will popup
3. Select a form history item with keyboard
4. Press DEL key (or Shift+DEL and Ctrl+DEL key) on a form history item
5. Again, Press ArrowDown key on the Search bar

Actual Results:
Screencast: https://youtu.be/kqEQu-frvrY
The form history item is not actually deleted from the database
The following error appears on Browser console when press DEL key.

TypeError: can't access property "ownerGlobal", this.input is null FormHistoryAutoComplete.sys.mjs:150:9
    removeValueAt resource://gre/modules/FormHistoryAutoComplete.sys.mjs:150
    handleDelete chrome://global/content/elements/autocomplete-input.js:577
    handleKeyDown chrome://global/content/elements/autocomplete-input.js:544
    AutocompleteInput chrome://global/content/elements/autocomplete-input.js:39

Expected Results:
The form history item should actually be deleted from the database.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8817b19391096abc4d12af946fb59f2867e3d087&tochange=33c9e2ecd2740e10fb165708ed97aa7a66c1cc44

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:dimi, since you are the author of the regressor, bug 1887007, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Mark Banner (:standard8)]

Given the code restructuring in the regressing bug, the best way to fix the regression would be to implement bug 1822297, and we should make sure we have a working test (we're not sure if we have one or not).

Comment 5

[Donal Meehan [:dmeehan]]

:standard8, the Fx129 soft code freeze starts on Thursday 2024-07-04, ahead of Fx129 merging to beta on Monday 2024-07-08.
RE: Comment 2, do you aim to land the patch under Bug 1822297 before we go to beta? If not, would it be safe for a later beta uplift?

In terms of Fx128, should that be a wontfix? Asking since this is an S2 but might be risky to patch in release

Comment 6

[Mark Banner (:standard8)]

(In reply to Donal Meehan [:dmeehan] from comment #5)

:standard8, the Fx129 soft code freeze starts on Thursday 2024-07-04, ahead of Fx129 merging to beta on Monday 2024-07-08.
RE: Comment 2, do you aim to land the patch under Bug 1822297 before we go to beta? If not, would it be safe for a later beta uplift?

This should be safe for a beta uplift. It isn't a massive patch, and it is basically splitting out existing code & adding a small fix to get the delete working again.

In terms of Fx128, should that be a wontfix? Asking since this is an S2 but might be risky to patch in release

I think so. This UI isn't very frequently used, so it shouldn't be affecting a lot of people (and we've only just started getting reports even though its been a release or two).

I am wondering about ESR 128 though. It is a bit of a privacy related issue since we're not clearing the data. Would this patch be likely to be accepted for uplift there once it has baked a bit in 129?

Comment 7

[Donal Meehan [:dmeehan]]

(In reply to Mark Banner (:standard8) from comment #6)

I am wondering about ESR 128 though. It is a bit of a privacy related issue since we're not clearing the data. Would this patch be likely to be accepted for uplift there once it has baked a bit in 129?

That makes sense, we can consider uplifting this after some time in 129.
Setting firefox-esr128 to affected.

Comment 9

[Mark Banner (:standard8)]

Fixed by bug 1822297.

Comment 10

[Cristian Baica [:cbaica], Release Desktop QA]

I've managed to reproduce the bug using Fx129.0a1.
The issue is verified fixed using Fx130.0a1 on Windows 10 and Ubuntu 23.04. The items are correctly deleted from the searchbar dropdown history and the "ownerGlobal" error is no longer displayed in the console.

Please note that while this functionality deletes the items from the search dropdown history, items are still displayed in library history (as per design).

Comment 11

[Donal Meehan [:dmeehan]]

:cbaica checking if you meant to set the Fx129 status to verified instead of affected?

Comment 13

[Cristian Baica [:cbaica], Release Desktop QA]

The issue verified fixed using the latest Fx 129.0b3 on Windows 10 and Ubuntu 23.04. The items are correctly deleted from the searchbar dropdown history and the "ownerGlobal" error is no longer displayed in the console.

@Donal I did not clear it. I only touched the 130 status since I was waiting for the 129 to verify there as well. On the related bug, the status was completely removed when I changed to verified the 130 branch. It's not clear what happened here. But now the issue is verifed nad I'll mark it accordingly on the 129 branch as well.

Comment 14

[Cristian Baica [:cbaica], Release Desktop QA]

The issue is verified fixed using the latest Fx128.1.0ESR on Windows and Ubuntu 23.04. The items are correctly deleted from the searchbar dropdown history and the "ownerGlobal" error is no longer displayed in the console.