When a search result is returned for an image file (png, jpg, gif etc..) stored in a document library, it returns the dispform.aspx page for the item, and not the path to the file.

This is counterintuitive to end users, and should be resolved to better harmonize with the way modern views render images and documents stored on the same location.

Option to open document either by web browser or local application when searching.

The search within SharePoint should perform people searches from the organization level at all times. Users should not have to go to the search results page and traverse up to the Organization level. The autosuggest on the site search used to display people results when we first vetted SharePoint as an Intranet solution--now it doesn't.

The search autosuggest should display the documents' Title, if available. Currently, the (file) Name is displayed, which is not intuitive or legible. Displaying the document Title first is the normal pattern of all search engines.

A filtering flaw was recently discovered within SharePoint when using the ‘filter button’ on the right hand side while working within a specific view. If this filter is engaged and the ‘see all’ link is selected, the view ID disappears from the link. If this link is then sent to or shared with another user, they won’t be directed to the correct view.

Can you release an update to SharePoint Online to resolve this flaw?

When searching for files and the result is an image, it doesn't open the .jpg files when clicking on them.
It does open .png and .jpeg files as images, but not .jpg (this is the default extension for jpeg images).
It makes our work more difficult, sice we already have many images with the .jpg extension and we just found out that the search is useless.

We would like to extend SharePoint Online search result by implementing OpenSearch protocol. One thing is that it doesn't support authentication right now: https://sharepoint.stackexchange.com/questions/201521/authentication-is-disabled-in-opensearch-result-source-on-sharepoint-online/213775. Since the data we are exposing are from customer on premises environment, authentication protection is required. Thanks.

Providing a tool that helps break down the search result score that an individual search result has received would help remove the mystery around SharePoint search. This could then be used to understand why results aren't returning in an expected order and tune metadata, settings, etc appropriately.

When you soft-delete an Office Group, the connected team site is not removed from search index. When you click on the search result, an HTTP 403 is presented.
The workaround from MS Support is to manually delete the site from the index.

Also the site is still visible in "Recent Sites" and "Following" on SharePoint Home for every user. Workaround is that every user has to unfollow and wait until the site automatically removes from recent.

Both is not acceptable and looks like a bug for me.
Please remove soft-deleted sites from search index.

Currently draft items are not searchable in SharePoint 2013, I don't think this has changed in 2016 or online. If you have a library with half published items and half draft items, it would be very helpful to have the default behavior allow editors to search through draft items while readers only search production items.

We find out that sometimes the contents of files which has been attached to Custom List can be searched and sometimes cannot.
I want to know which one is correct in the specification of SharePoint Online, is the capable of searching correct or the incapable of searching correct.

Within search driven applications, actual values of columns within items are critical for users. Imagine a task, shown search driven in my open tasks. If user completes the task on the list, user will expect, that this tasks are not shown in the above mentioned my open tasks.

Therefore allow immediate (re) indexing for specific items (like tasks) - possibly configurable. This actually was possible with SP2010 server side code.

I love the search in the modern document libraries, however there are some issues displaying results when the search is too broad.

If a user types a keyword search in the top left-hand corner, then clicks "see more results", they will often get the message "no items match your search" despite just seeing some results in short list below the search box.

The error should either be "there are too many results", or the results should be split into pages.

At this moment a result set of a search query is ordered case sensitive. It would be great if this became case insensitive or perhaps with the possibility to choose between the two options

I would like to create a new account for new hires to join, but I would like to prohibit searching for pre-joining users in order to manage confidential information.

Our colleagues are used to work with SharePoint Search and do not want to use antother app for this purpose. Unfortunately people search in SharePoint doesn't bring up any Email attachments but only files stored in SharePoint or shared within OneDrive. I really hope that this is going to be changed soon...