Decide on what behavior should exist with regard to unsupported keys in manifest.json. In MV2 we warn on the them and continue loading. Currently in MV3 we will fail to load if it is an MV2-only key, but will(?) continue to load if undefined keys.

We can move to a strict mode, but that may make some things a touch more complicated for developers.
The more flexible approach for developers is to just warn on them and continue to load.

We could expose the fail on warning pref in devtools, allowing developers to test against a strict mode, but otherwise ignore those keys.

I hit this bug in bug 1723156 when I wrote a unit test.

When browser_action is set in manifest.json of MV3, the current in-tree behavior is to throw an error and refuse to load the manifest file.
This behavior is inconsistent with how truly unrecognized/unsupported properties are treated; they are ignored and a warning is printed.

We should also print a warning and ignore the property. By ignoring I really mean not including the value in the normalized manifest; the current behavior of additionalProperties with UnrecognizedProperty is to blindly forward the value: https://searchfox.org/mozilla-central/rev/d34f9713ae128a3138c2b70d8041a535f1049d19/toolkit/components/extensions/Schemas.jsm#2135-2136,2138,2143.

I'll put up a patch that ensures that undefined is used. We should probably change the behavior of UnrecognizedProperty to default to undefined to avoid issues.
(in case it isn't clear: an example of potential issues when the normalized manifest contains the original instead of undefined is that if a manifest contains both browser_action and action, that browser_action would always be used at https://searchfox.org/mozilla-central/rev/d34f9713ae128a3138c2b70d8041a535f1049d19/browser/components/extensions/parent/ext-browserAction.js#123).

https://hg.mozilla.org/mozilla-central/rev/49f93756f94b