Bugzilla

(In reply to Mike Hommey [:glandium] from comment #4)

> Having the file in omni.ja doesn't prevent users from adding the file where it used to be, and that would be picked up by Firefox, and override whatever's set in the omni.ja ; shouldn't it?

So to be clear, I want to stop reading the file, because it adds unnecessary mainthread IO overhead.

To me, the simplest solution seems to be compiling the information that's currently preprocessed into this file into the binary, and continuing to allow the pref (if set) to override it.

If there is some reason that I don't yet see why that can't work, we could perhaps also move the reading of this pref off the main thread and off the startup path, and delay starting the update service until we have read the relevant value... but that seems like more work to me.

(In reply to Mike Hommey [:glandium] from comment #4)

> Having the file in omni.ja doesn't prevent users from adding the file where it used to be, and that would be picked up by Firefox, and override whatever's set in the omni.ja ; shouldn't it?

So to be clear, I want to stop reading the file, because it adds unnecessary mainthread IO overhead.

To me, the simplest solution seems to be compiling the information that's currently preprocessed into this file into the binary, and continuing to allow the pref (if set, like any other pref) to override it.

If there is some reason that I don't yet see why that can't work, we could perhaps also move the reading of this pref off the main thread and off the startup path, and delay starting the update service until we have read the relevant value... but that seems like more work to me.

(In reply to Mike Hommey [:glandium] from comment #4)

> Having the file in omni.ja doesn't prevent users from adding the file where it used to be, and that would be picked up by Firefox, and override whatever's set in the omni.ja ; shouldn't it?

So to be clear, I want to stop reading the file, because it adds unnecessary mainthread IO overhead.

To me, the simplest solution seems to be compiling the information that's currently preprocessed into this file into the binary, and continuing to allow the pref (if set, like any other pref) to override it.

If there is some reason that I don't yet see why that can't work, we could perhaps move the reading of this file off the main thread and off the startup path, and delay starting the update service until we have read the relevant value... but that seems like more work to me.