Bug 1644572 added the browser.urlbar.restyleSearches pref. Its intended purpose was to restyle search history results as form history. It's still preffed off as of this filing, but it is being used in a limited way as of bug 1664760. That bug added the pref browser.urlbar.update2.restyleBrowsingHistoryAsSearch which calls the same code as browser.urlbar.restyleSearches.

This meta tracks bugs to improve this feature, especially now that it's used in production via browser.urlbar.update2.restyleBrowsingHistoryAsSearch. I added bug 1644572 as see-also. This meta depends on update2 landing, but it shouldn't be added to update2's dependencies (for now, at least).

I closed bug 1667897 since it was pretty much a duplicate of this meta. I'm going to dupe relevant comments here so they don't get lost:

Bug 1667897 comment 0:

restyleSearches is brittle to unexpected differences in SERP URLs. It restyles browsing history by extracting the q parameter from a SERP page in history. It then constructs a URL that matches what that SERP's SearchEngine would construct. If the history result matches the constructed URL, we dedupe the former with the latter.

This doesn't reflect how some organic SERP URLs are constructed; notably Google. For example, if I go to google.com and search for "mozart", I get sent to the URL https://www.google.com/search?hl=en&q=mozart. The hl parameter throws off the matching described in the first paragraph and the mozart SERP isn't restyled.

There's a fine line to walk here, since not all query parameters can be ignored. Some might point to image search, or non-first result pages. Those kinds of URLs shouldn't be deduped. This work will probably require per-engine tuning.

Bug 1667897 comment 1:

There's also the URL https://www.google.com/search?hl=en&ei=emFyX8WIDoSltQaO4o_IDw&q=mozart&oq=mozart&gs_lcp=CgZwc3ktYWIQAzIKCC4QsQMQQxCTAjIFCAAQsQMyBAgAEEMyBAgAEEMyAggAMgIIADICCAAyBAgAEEMyAggAMgIIADoHCC4QQxCTAjoKCC4QxwEQowIQQzoHCAAQsQMQQzoCCC46CAgAELEDEIMBOggILhCxAxCDAToFCC4QsQNQ71VY-pYBYJCcAWgCcAB4AIABWogB4wOSAQE2mAEAoAEBqgEHZ3dzLXdperABAMABAQ&sclient=psy-ab&ved=0ahUKEwjFrY3_8IzsAhWEUs0KHQ7xA_kQ4dUDCAw&uact=5 in my history. It shows up in the Urlbar when I search for "mozart"; ideally, it would not.

Bug 1667897 comment 2:

Another major win here would be ignoring the attribution parameter in the two URLs. That way, both a search from the Urlbar and an organic search would be considered duplicates, as long as the other parameters were the same. This would require removing the check that the two URLs have the same number of parameters and adding an exception for the attribution parameter in the every() check below, like we do for the terms parameter.