1779736 - The adaptive history autofill doesn't respect the old/new prioritization

Status: RESOLVED INVALID

(Firefox :: Address Bar, defect)

Description

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

Found in

• Fx103.0b9

Affected versions

• Fx103.0b9
• Fx104.0a1

Affected platforms

• Windows 10
• Ubuntu
• macOS

Steps to reproduce

1. Launch Firefox.
2. Navigate to https://www.reddit.com/r/Romania/comments/us7ee6/serviciile_de_ridesharing_au_devenit_noii/ by pasting the link the address bar and hitting enter.
3. Navigate to https://www.reddit.com/r/Romania/comments/us89hm/mam_saturat_sa_lucrez_ca_programator/ by pasting the link the address bar and hitting enter.
4. Create the first adaptive autofill for the link at step 3, by typing 'redd' and chosing the link in step 3 from the firefox suggest section (making it the first/old adaptive record).
5. Create the second adaptive autofill for the link at step 2, by typing 'redd' and chosing the link in step 2 from the firefox suggest section (making it the second/new adaptive record).
6. Type 'redd' in the address bar.

Expected result

• The https://www.reddit.com/r/Romania/comments/us7ee6/serviciile_de_ridesharing_au_devenit_noii/ is autofilled in the address bar according to the prioritization order (it's the newest adaptive record created).

Actual result

• The https://www.reddit.com/r/Romania/comments/us89hm/mam_saturat_sa_lucrez_ca_programator/ is autofilled.
  This could be because it's the newest history entry? At least this is what the evidence suggests.

Regression range

• This is not regression.

Additional notes

• Please note that this is an edge case where the history entry order is different from the adaptive creation order.
• The following is mentioned about the prioritization logic:

1. In descending order of use count. In other words, largest use count wins.
2. If the above is the same, the record whose search string does not start with “www” or a protocol like “http://” and “https://”.
3. If the above is the same, in descending order of frecency.
4. If the above is the same, newer records before older records. ----- if it's history that has a priority, and not actually the creation of adaptive records, feel free to mark the bug as invalid.

Comment 1

[Drew Willcoxon :adw]

Thanks for filing this. This is the expected behavior, so I'll close it.

(In reply to Cristian Baica [:cbaica], Release Desktop QA from comment #0)

4. If the above is the same, newer records before older records. ----- if it's history that has a priority, and not actually the creation of adaptive records, feel free to mark the bug as invalid.

Sorry, my fault -- it's actually newer URLs before older URLs. As you've guessed, the reason the link in step 3 autofills is because it's a newer URL in your history. (I updated the QA doc.)

I reproduced this, and the two URLs have the same frecency, and their adaptive history records have the same use count. So after that, the priority logic falls back to the newer URL, which is the one in step 3 since it was added more recently.

Comment 2

[Drew Willcoxon :adw]

Also, even though this is the expected behavior, we might want to change it so the newer adaptive history record wins. That might make more sense, but IMO it's not worth worrying about because I'd expect this to be a very small edge case since the two URLs' frecency and use counts must be the same, which probably won't be the case very often in practice. (Although one case it's more likely to happen is new profiles, since there's less data and history.) But even then, the user would need to be aware of which URL they added a record for most recently in order for them to be surprised by the current behavior.

It's good to have this bug as a record of this behavior, and we can watch for user feedback.