1056611 - SearchSuggestionController.jsm's NS_ASSERT(this._searchString !== null, ...) can fail, resulting in "'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions"

Status: RESOLVED WORKSFORME

(Firefox :: Search, defect, P5)

Description

[Jeff Walden [:Waldo]]

From the terminal window that spawned the nightly I'm using:

*************************
A coding exception was thrown in a Promise resolution callback.
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Full message: TypeError: 'caller', 'callee', and 'arguments' properties may not be accessed on strict mode functions or the arguments objects for calls to them
Full stack: NS_ASSERT@resource://gre/modules/debug.js:67:23
this.SearchSuggestionController.prototype._dedupeAndReturnResults@resource://gre/modules/SearchSuggestionController.jsm:319:5
Handler.prototype.process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:866:23
this.PromiseWalker.walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:745:7

*************************

The error is a bit of a red herring.  The means NS_ASSERT uses to compute a stack trace doesn't work if any calling function is strict mode, and the error reported here is due to that.  (Haven't searched for a bug on this yet, if you were wondering.)

But if NS_ASSERT is throwing because of a stack-walk into strict mode code, it's because the asserted condition didn't hold.  Tracing back into the caller, that means this must have failed:

314   /**
315    * @param {Array} suggestResults - an array of result objects from different sources (local or remote)
316    * @return {Object}
317    */
318   _dedupeAndReturnResults: function(suggestResults) {
319     NS_ASSERT(this._searchString !== null, "this._searchString shouldn't be null when returning results");

I don't know how this happened, but fooling around typing in the search bar using prefixes of past searches, with occasional backspacing, seems to trigger it...somehow.  So I don't have exact steps, but this appears reproducible with some manual fiddling.

Looking at the code, I suspect a race condition of some sort between the stop method (calling _reset) and the resolution of the promise created by fetch.  Maybe _reset is aborting the request, but the (presumably?) async callback to notify about that doesn't happen until after the promise has been settled?

Comment 1

[Mark Banner (:standard8)]

This assert was removed in bug 1088660.