Enter Key Does Not Submit Search in MOSS 2007 from Firefox

One issue that has "bitten" me on more than one occasion is the fact that the SearchBoxEx control in Microsoft Office SharePoint Server (MOSS) 2007 does not work consistently across different browsers. Specifically, I am referring to the issue where pressing the Enter key in Mozilla Firefox does not initiate the search but rather just refreshes the current page. The workaround is to have Firefox users always click the "Go Search" button to submit the search terms and view search results.

I first encountered this issue several years ago on my first MOSS 2007 project, but I was able to convince the customer that we did not need to fix it at the time given the workaround I note above (and also considering the fact that Firefox wasn't nearly as popular back then as it is today).

When this issue came up again for a different customer this past summer, I did some more research into the underlying issue. I found a service request (i.e. support case) for another customer that encountered this problem. According to this SR, the official response from Microsoft Support (i.e. CSS) is that for MOSS 2007, Firefox is a "Level 2" browser (from a support and functionality perspective). In light of this -- combined with the workaround of clicking the Go Search image button (instead of pressing the Enter key) -- the SR stated that there are no plans to address this issue.

I spent a few hours that day investigating the bug myself as well as some various hacks to circumvent the issue that I found when searching the Internet.

I discovered the fundamental problem is due to the way that SharePoint cancels the form submission -- or in the case of Firefox, does not cancel the form submission -- when the Enter key is pressed in the search box.

Specifically, line 608 of %ProgramFiles%\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\1033\Search.js:

try {if(null != event) event.returnValue = false;} catch (err) {}

Instead of returning false -- and subsequently cascading this return value to the OnKeyPress event handler (which would subsequently return false to cancel the form submission) -- SharePoint sets event.returnValue to false in order to cancel the form submission. While this works fine for Internet Explorer -- and apparently Safari as well -- it does not work for Firefox. In fact, I discovered that event is undefined at this point when running under Firefox. Since the form submission is not canceled in Firefox, there is a "race condition" between the form submission caused by the Enter key being pressed and the redirect to the search results page (i.e. line 606 of Search.js):

window.location = Url + sch;

If we had access to the event object in the GoSearch function when browsing with Firefox, we could use the W3C standard preventDefault() method to cancel the default action (i.e. the form submission). Unfortunately, the event is not passed as a parameter to the GoSearch function. We also do not have the ability to customize the JavaScript function generated by the SearchBoxEx control that handles the OnKeyPress event (which should return false if the GoSearch function attempts to redirect to the search results page).

Since fixing the fundamental bug in Search.js did not appear to a viable option, I looked at some other suggested fixes for this bug.

Simply adding two "dummy" input elements (as described in https://stevenng.net/2008/09/09/is-the-enter-key-not-working-for-sharepoint-search) did not work for my customer's solution. I speculated that perhaps the structure of their custom master page was missing other elements necessary to make this work.

I then tried replacing the onKeyPress event as suggested in https://social.msdn.microsoft.com/Forums/en-US/sharepointecm/thread/87574c13-91d6-48fe-8346-01e77e0094b3 and https://blog.marktharris.com/2008/09/searchboxex-firefox-and-enter-key.html.

Here is the script that I found would need to be added to the custom master page:

 <%--
HACK: Bug 126525 - "Search" not working in Mozilla Firefox 3.0

Replace the onKeyPress event for Firefox in order to avoid submitting the form
and subsequently canceling the redirect to the search results page.

(https://social.technet.microsoft.com/Forums/it-IT/sharepointecm/thread/87574c13-91d6-48fe-8346-01e77e0094b3)

Note that the element ID and corresponding JavaScript function contain a
unique identifier (i.e. ""). This unique identifier is set within the
OnInit() method of the SearchBoxEx control:

  this.m_strUniqueNamePrefix =
    "S" + SearchCommon.HashString(this.UniqueID) + "_";

Note that SearchCommon.HashString(string str) returns the following:

  str.GetHashCode().ToString("X", CultureInfo.CurrentCulture);

As long as the structure of the page is not changed (i.e. the name of
the SearchBoxEx control as well as the naming containers that hold
the control) then this unique identifier should not change.
--%>

<script language="javascript">
function replaceOnKeyPress()
{
  var theFunction = "S5F221A6C_Submit();";
  var theInputID = "ctl00_siteSearchBoxEx_S5F221A6C_InputKeywords";
 
  var txt = document.getElementById(theInputID);
  var browser = navigator.appName;
  if (txt && (browser == "Netscape"))
  {
    txt.onkeypress = function(e)
    {
      var key = String.fromCharCode(e.keyCode);
      if (key == "\n" || key == "\r")
      {
        eval(theFunction);
        return false;
      }
    }
  }
}
 
replaceOnKeyPress();
</script>

Important

While this hack was verified to fix the problem in Firefox, it is somewhat brittle due to the need to specify the unique identifier in the script (see my comments in the server-side comment above).

Given that this problem only occurs in Firefox (as noted earlier, I was unable to repro in Safari), we were once again "lucky" enough to convince the customer not to fix this.

As noted in my earlier comments, the "official" response from Microsoft Support for this bug appears to be "won't fix" (at least based on the comments that I read in the aforementioned support case -- specifically that for MOSS 2007, Firefox is considered a "Level 2" browser from a support perspective). However, if you decide you need a workaround for this bug for Firefox users, you might consider this an acceptable solution.

Comments

• Anonymous
  May 16, 2010
  The comment has been removed