1652505 - Do not initialize SearchService when running dom/indexedDB mochitest

Status: RESOLVED WONTFIX

(Firefox :: Search, task)

Description

[Simon Giesecke [:sg] [he/him]]

When I try to run a dom/indexeDB mochitest with custom preferences, the test case is never executed, because it blocks before that with:

 0:08.16 GECKO(8958) [Parent 8958, IndexedDB #1] WARNING: Preprocessing for indexes not yet implemented!: file /home/simon/work/mozilla-unified/dom/indexedDB/ActorsParent.cpp, line 26036
 0:08.16 GECKO(8958) [Parent 8958, IPDL Background] WARNING: Converting non-IndexedDB error code (0x80004001) to NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR: file /home/simon/work/mozilla-unified/dom/indexedDB/ActorsParent.cpp, line 556
 0:08.20 GECKO(8958) console.error: SearchEngineSelector: (new UnknownError("IndexedDB: main/search-config list() IndexedDB:  execute() The operation failed for reasons unrelated to the database itself and not covered by any other error code.", "resource://services-settings/IDBHelpers.jsm", 24))
 0:08.20 GECKO(8958) console.error: SearchEngineSelector: "Received empty search configuration!"
 0:08.29 GECKO(8958) ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmpf9zEyz.mozrunner/runtests_leaks_tab_pid9159.log
 0:08.29 GECKO(8958) [9159, Main Thread] WARNING: XPCOM_MEM_BLOAT_LOG is set, disabling native allocations.: file /home/simon/work/mozilla-unified/tools/profiler/core/platform.cpp, line 245
 0:08.32 GECKO(8958) [Parent 8958, IndexedDB #1] WARNING: Preprocessing for indexes not yet implemented!: file /home/simon/work/mozilla-unified/dom/indexedDB/ActorsParent.cpp, line 26036
 0:08.32 GECKO(8958) [Parent 8958, IPDL Background] WARNING: Converting non-IndexedDB error code (0x80004001) to NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR: file /home/simon/work/mozilla-unified/dom/indexedDB/ActorsParent.cpp, line 556
 0:08.32 GECKO(8958) console.error: SearchEngineSelector: (new UnknownError("IndexedDB: main/search-config list() IndexedDB:  execute() The operation failed for reasons unrelated to the database itself and not covered by any other error code.", "resource://services-settings/IDBHelpers.jsm", 24))
 0:08.32 GECKO(8958) console.error: SearchEngineSelector: "Received empty search configuration!"
 0:08.33 GECKO(8958) console.error: SearchService: "_init: failure initializing search:" (new TypeError("can't access property \"webExtension\", defaultEngine is undefined", "resource://gre/modules/SearchService.jsm", 1671))
 0:08.33 GECKO(8958) JavaScript error: resource://gre/modules/SearchService.jsm, line 473: NS_ERROR_FAILURE: SearchService previously failed to initialize
 0:08.33 GECKO(8958) JavaScript error: , line 0: uncaught exception: 2147500037
 0:08.33 GECKO(8958) JavaScript error: resource://gre/modules/SearchService.jsm, line 2156: NS_ERROR_FAILURE: SearchService initialization failed

We need a way to disable this use of IndexedDB when running a mochitest, at least optionally. Maybe there already exists one. Is there a pref to disable the SearchService or its use of IndexedDB (when running mochitests)?

Comment 1

[Mark Banner (:standard8)]

Please can you provide a few more details about what you're trying to test for IndexedDB? Also, why do you need a mochitest, could use an xpcshell test instead?

Using an xpcshell test means you wouldn't need to start the search service at all.

The problem I see for mochitests, is that remote settings relies on IndexedDB, there's an increasing amount of items in Firefox that are then relying on remote settings.

The search service is probably the worst of these currently, as breaking it causes a lot of the UI to break. Though that leads me to another issue which relates back to the first question - what are you changing that's breaking something using indexedDB? If that's something that a user could change, that would concern me because of the resulting UI issues, and it would seem like we should be fixing the issue for the test rather than trying to work around it.

Comment 2

[Mark Banner (:standard8)]

Also, can you tell me how I can reproduce those errors from comment 0 at the moment? I'd like to see if I can get the IndexedDB error code propagated up the stack to the search service - I think it gets lost/replaced in remote settings at the moment.

Comment 3

[Simon Giesecke [:sg] [he/him]]

Sorry for the implicit assumptions I didn't make clear: I am referring to the local development process. In the particular case at hand, I didn't change anything, but are just trying to reproduce the intermittent error reported in Bug 1637715, which is a consequence of left-over custom preferences set usually for a different test case. As described in https://bugzilla.mozilla.org/show_bug.cgi?id=1637715#c34, when

user_pref("dom.indexedDB.dataThreshold", 0);
user_pref("dom.indexedDB.preprocessing", true);

the test case dom/indexedDB/test/test_upgrade_add_index.html used to fail deterministically at the time the bug was filed. Now, with these prefs it does no longer seem to be possible to run the test case at all, as laid out in https://bugzilla.mozilla.org/show_bug.cgi?id=1637715#c38

But you're right that this particular test can be run as a xpcshell test as well. I will try that.

However, I ran into situations like this in the past as well, when trying out changes that break some test cases. Obviously, a change that breaks remote settings, the search service or anything else couldn't land, and isn't intended to land. But it is relevant for the local development process. Not everything is or can be covered by xpcshell tests, e.g. private browsing mode tests or anything related to mutable files. Also, the long-term plan is to remove Mozilla-specific tests in favor of wpt tests, which suffer from the same/a similar problem as mochitests.

Comment 5

[Mark Banner (:standard8)]

Simon, with the fixes we're doing in bug 1653988 and others, plus the fact that we should generally use xpcshell where possible, then I think we don't need to do this.

I would certainly be concerned about implementing something, as this would give the possibility of breaking something unintentionally.

Do you agree?

Comment 6

[Mark Banner (:standard8)]

I'm going to mark this as wontfix as per my previous comment - I don't think we need to do this, and we have other things in place to hopefully make things work in this case.