Firefox, 404, and lunr.js

The search function on this blog is powered by lunr.js. This post was inspired by a search question in the blog comments:

Is it me or does it not work in Firefox?

~Jason (from the blog comments)

Of course lunr.js works with Firefox, right? I tested the search page in Chrome and Safari before launch. But I took Firefox for granted. The US Navy Seals have a saying: Assumption is the mother of all [screw]-ups.

“Haha!” said Firefox when I tried to run search. It threw up the “404” page. This post documents the problem and the solution.

Firefox 404 lunrjs search

Isolating the Problem

Through Google, Stack Overflow, and trial & error I isolated the problem to a single line of JavaScript code in search.js.

  $("#site_search").submit(function(){
      event.preventDefault(); // Problem.
      var query = $("#search_box").val();
      var results = window.idx.search(query);
      display_search_results(results);
  });

Explaining the Problem

When a web browser encounters this function in the script, it will attempt to open a page instead of running the script on that page. The command event.preventDefault(); is supposed to stop the page from opening so the script can run instead. Chrome and Safari handled this fine. But Firefox tried to open a non-existing page, and that led to the 404. What could we do about it?

Getting Help

Fortunately, a ChicagoRuby meeting was only one day away. ChicagoRuby has many members who are passionate polygots, not just Rubyists.

After the meeting, I reproduced the problem for Justin Love and Darren Holland. In addition to being a co-organizer of ChicagoRuby, Justin is a JavaScript enthusiast and a co-organizer of the Chicago JavaScript group. Darren has strong skills in Ruby and JavaScript.

We managed to isolate the problem further by strategically inserting alert statements in search.js. We tested each iteration against Chrome and Firefox. Chrome continued to succeed. Firefox continued to fail. The alert statements helped us to verify the point of failure.

Collaboration and Solution

After several minutes of collaboration, Darren theorized that event.preventDefault(); was choking in Firefox because the event object was not explicitly passed. Chrome and Safari were running the same JavaScript code, and they assumed that event meant event even though no object had been passed. But maybe Firefox wanted to be explicitly told what object was being passed?

One way to find out: We added event to the function definition as follows:

  $("#site_search").submit(function(event){

Next, we re-started the Jekyll server. And it worked! Firefox browsers can use the search page with great results. The problem wasn’t in lunr.js. It was in a single line of search.js, the JavaScript file that communicates with lunr.js.

Lessons Learned

Key takeaways from this experience:

Git Rocks

Once again, Git proves to be awesome. We performed all of our troubleshooting steps in a separate branch called firefox. Advantages of this approach:

Acknowledgements

Special thanks to the following people for turning this into a learning experience:

Comments