1030384 - startup consolespew: "WARNING: Failed to update pref 'camera.control.test.enabled' (0x8000ffff)" and similar

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Start up a recent m-c build from the terminal, with a fresh profile.
 2. Watch your terminal output.

ACTUAL RESULTS:
This appears, among the first few lines of output:
{
[25696] WARNING: Failed to update pref 'camera.control.test.enabled' (0x8000ffff)
: file $SRCDIR/dom/camera/CameraPreferences.cpp, line 136
[25696] WARNING: Failed to update pref 'camera.control.test.hardware' (0x8000ffff)
: file $SRCDIR/dom/camera/CameraPreferences.cpp, line 136
[25696] WARNING: Failed to update pref 'camera.control.test.method.error' (0x8000ffff)
: file $SRCDIR/dom/camera/CameraPreferences.cpp, line 136
[25696] WARNING: Failed to update pref 'camera.control.test.async.error' (0x8000ffff)
: file $SRCDIR/dom/camera/CameraPreferences.cpp, line 136
}

These lines were added in the past few days, in 990122, here:
  http://hg.mozilla.org/mozilla-central/rev/8b4e8b5ad0c5#l1.138

I trapped it with gdb, and the backtrace shows that this is being called by
 mozilla::Preferences::RegisterCallbackAndCall()
which is called by:
 mozilla::CameraPreferences::Initialize()

I think the pref-read is failing simply because the preference does not exist. (It's not in all.js) 

mikeh, can we just drop these warnings?

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Daniel Holbert [:dholbert] from comment #0)
>
> I think the pref-read is failing simply because the preference does not
> exist. (It's not in all.js) 

Right, they're used for testing the API.

> mikeh, can we just drop these warnings?

These warnings only show up in DEBUG builds, so I'd like to leave them in.

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

No, you don't get to spew whatever you want in the console of a debug build.  The warnings need to go.

Comment 3

[Mike Habicher [:mikeh] (high bugzilla latency)]

Are there any guidelines on the proper usage of NS_WARNING? MDN, at least, is silent on the matter.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

It's supposed to be used for "unexpected" cases.  If the NS_WARNING fires on every startup that's not unexpected.

Comment 5

[Mike Habicher [:mikeh] (high bugzilla latency)]

Attachment: Remove NS_WARNINGs

Comment 6

[Andrew McCreight [:mccr8]]

FWIW, this warning appears 328 times in a Mochitest-2 log I grabbed.

Comment 7

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Andrew McCreight [:mccr8] from comment #6)
>
> FWIW, this warning appears 328 times in a Mochitest-2 log I grabbed.

Apologies. If someone wants to r+ attachment 8446575 [details] [diff] [review], I'll land it ASAP.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c4ee32efd92

Please ensure your patches include commit information per the link below when requesting checkin.
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9c4ee32efd92

Comment 10

[Daniel Holbert [:dholbert]]

just noticed there's still a pending needinfo=me from comment 1; canceling it, since I don't think we're waiting on anything here. [khuey replied to comment 1 before I could]