1468057 - Heuristic result doesn't show the page title or a star if the url is known

Status: RESOLVED DUPLICATE of bug 1440784

(Firefox :: Address Bar, defect, P5)

Description

[Qwerty]

Steps to reproduce:
1. Open https://www.youtube.com/watch?v=HEXWRTEbj1I in tab.
2. Check that when you paste this url in new tab, firefox suggests you not only "Visit" entry, but also second entry with page title "Haddaway - What Is Love [Official] - YouTube". Also tab icon on the left side and "Switch to Tab" text on the right, if you are not holding ctrl or shift (in this case just title and url on the right)
3. Now close twitter tab.
4. In new tab paste this url again. Observe suggestions.
5. Open url and bookmark it. Then close tab.
6. In new tab paste this url again. Observe suggestions.
7. Now try 4 and 6 steps, but remove last letter from url ("I") for example.

Actual results:
ESR 52 behaves in 4 and 6 steps similarly to 2. By pasting you directly see that you have this url in history or bookmarks, and you see title of the page, which is useful. In case of bookmark you see star on the left side.
60 and Nightly don't show any indications that you have this page in history or bookmarks. But funny enough, they do it if you paste/type not full exact url, like in step 7 or with just "HEXWRTEbj1I".

Expected results:
Firefox should behave the same with all 3 cases by default (enabled check-boxes in about:preferences#privacy): with existing tab, with presence in history and presence in bookmarks. No matter if you type only part of url or full exact url.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

this is due to de-duping that was indeed fixed in 60, if a url is already provided by a previous match, we don't further add it. Switch to tab is an exception because we don't support switching to an existing tab for the heuristic entry.
Removing one letter makes the first and second entry point to different urls, so they are properly not de-duped.
The current behavior is the expected one.

The bug pretty much boils down to the fact the heuristic result doesn't show details like the title and the star, and as such it's an enh request.

Comment 2

[Qwerty]

Why is it P5? Bug makes uncomfortable this workflow:
1. Get a link without preview/title from another application or webpage (especially sites that disable coloring for visited link, like github).
2. Switch or create new tab, paste link.
3. If you have it in history, you see title before visiting it, and maybe decide to not visit it.
4. If you not seeing title, visit it just by pressing enter and then decide if you want to read or close it.

Now with this bug I need to either:
2. Open library/history and check there.
3. Open link from there if decide to visit.
4. If not present in history, need to switch to main window or close library window, then switch or create new tab, paste and visit it.

Or:
2. Switch or create new tab, paste link, delete one letter from it.
3. See if suggestion WORKS AS IT SHOULD for visited page, then bring back deleted letter if decide to visit.
4. If not seeing title even after deleting letter, bring letter it back and visit.

Both are ridiculous methods to get around a bug that breaks basic UI functionality. Why even treat suggestion for full url that match history different than suggestion for bookmarks, existing tabs and even cut url (not full) that match history? That's inconsistent and makes no sense.
If showing details is not expected behavior, then break all of them, not just this one case. If it's expected behavior, then it's at least P3.

Reminder that Firefox have special setting in GUI (about:preferences#privacy) that controls suggestions for: history, bookmarks, open tabs. Default: all three are enabled. Right now setting for history suggestions is not working as expected, and moreover it's not working for most easier case from user perspective: full macthing url (unlike partial url, that looks harder to suggesting correct history entry). That's nothing like P5.

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Because we have a lot of higher priorities to deal with, we'll gladly take a patch from the community, but we're unlikely to find time to work on this ourselves. Additionally  we didn't see lots of reports about it, so it doesn't sound a common enough concern for now. If the situation will change in the future we'll re-evaluate.
We are a small team, setting it as a P3 wouldn't change much, we have barely resources for P1s and P2s. But luckily we are open source and the community is huge.