Description

When a end-user use the "quick search" box (top right corner of the Share UI) to search for some keywords the result page is shown.
This page display a new search form with its submit button enabled.
For some end-users it is not obvious that the search query as already been sent to the server and they don't pay attention to the element showing the status.
The result is that they are clicking the search button of the result page leading to another identical FTS query being sent.

Most of the time this is not a big issue but when the search server is struggling to handle a query this could have dramatic effect since it doubles the number of those queries.

Steps to reproduce

1- Install Alfresco 4.1.4 with Solr
2- Set log4j.logger.org.alfresco.repo.search.impl.solr.SolrQueryHTTPClient=debug
3- Start Alfresco and login as admin
4- On the admin dashboard fill the quick search box with a complex FTS query such as "*t*" and press enter
5- As soon as the search form of the result page is shown press enter again

Expected Behaviour

The search button of Share result page should be disabled (or replaced by a cancel button) when search is in progress.
Another option could be to display a "loader" popup to prevent the user from searching the same keywords once again.

Observed Behaviour

A second identical FTS query is sent to the server before Solr returned the result of the first one (See SolrQueryHTTPClient output is alfresco.log).

Analysis to date

Some complex FTS queries can consume up to several GB of memory on Solr.
So we should do our best to avoid multiples of those to be sent at the same time.
Customer is complaining because Solr is often becoming unresponsive because end-users are searching for complex queries like *xxyyzz* from their dashboard (so by default search is executed against all sites). It seems most of those users are not reading the search status displayed on the result page and execute their searches many times leading to solr becoming unresponsive handling identical FTS queries.