942182 - Bogus "Could not localize property" messages for widgets added by extensions

Status: RESOLVED INVALID

(Firefox :: Toolbars and Customization, defect)

Description

[Wladimir Palant]

Using CustomizeUI.createWidget() to create a custom widget for an extension always produces bogus warnings in the Browser Console:

> Could not localize property 'abp-toolbarbutton.label'
> Could not localize property 'abp-toolbarbutton.tooltiptext'

Adblock Plus sets label and tooltip attributes itself, in the widget.onCreated callback. However, there is no way to opt out of CustomizeUI localizing these attributes - neither null nor "" as label/tooltiptext widget parameters will help here. The only way to silence these warnings would be supplying existing string IDs from chrome://browser/locale/customizableui/customizableWidgets.properties for these parameters but I don't think that using strings belonging to some other button is a good solution.

Comment 1

[:Gijs (he/him)]

(In reply to Wladimir Palant from comment #1)
> Using CustomizeUI.createWidget() to create a custom widget for an extension
> always produces bogus warnings in the Browser Console:
> 
> > Could not localize property 'abp-toolbarbutton.label'
> > Could not localize property 'abp-toolbarbutton.tooltiptext'
> 
> Adblock Plus sets label and tooltip attributes itself, in the
> widget.onCreated callback. However, there is no way to opt out of
> CustomizeUI localizing these attributes - neither null nor "" as
> label/tooltiptext widget parameters will help here. The only way to silence
> these warnings would be supplying existing string IDs from
> chrome://browser/locale/customizableui/customizableWidgets.properties for
> these parameters but I don't think that using strings belonging to some
> other button is a good solution.

You should use a type: "custom" widget instead of a "button" or "view" widget if you're building a custom widget that you want complete control over. Your widget spec should have an onBuild method, which will be passed a DOM document where to construct your widget, and are expected to return a toolbaritem/toolbarbutton. I understand that we've not documented this, but if you're building a custom widget you really ought to be using that.

Does this work for your usecase?

Comment 2

[Wladimir Palant]

(In reply to :Gijs Kruitbosch from comment #1)
> You should use a type: "custom" widget instead of a "button" or "view"
> widget if you're building a custom widget that you want complete control
> over.

Yes, this works indeed (using undocumented APIs is fun). However, I don't think that the only type meant to be used by extensions is "custom" - and for any other type CustomizableUI will try to look up strings in a properties files that extension authors have no control over. At the very least it should be possible to specify your own stringbundle. Opting out of localization (meaning that the strings passed in should be taken as are rather than considered to be string IDs) would IMHO be a better option however.

Comment 3

[:Gijs (he/him)]

(In reply to Wladimir Palant from comment #2)
> (In reply to :Gijs Kruitbosch from comment #1)
> > You should use a type: "custom" widget instead of a "button" or "view"
> > widget if you're building a custom widget that you want complete control
> > over.
> 
> Yes, this works indeed (using undocumented APIs is fun). However, I don't
> think that the only type meant to be used by extensions is "custom" - and
> for any other type CustomizableUI will try to look up strings in a
> properties files that extension authors have no control over. At the very
> least it should be possible to specify your own stringbundle. Opting out of
> localization (meaning that the strings passed in should be taken as are
> rather than considered to be string IDs) would IMHO be a better option
> however.

If you specify an actual string for these properties, AFAICT you shouldn't get any messages, either. I just checked, and this seems to be the case, too. E.g. running this in the Browser Console:

CustomizableUI.createWidget({type: "button", label: "Foo", id: "test-me-special-widget-very-special", tooltiptext: "Bar"})

does not complain (and is essentially "opting out of localization")


Can we close this bug as invalid, or is there something that I'm missing here? (apart from the fact that we need to document stuff, which is tracked in bug 942393)

Comment 4

[Wladimir Palant]

My bad. It seems that the error indeed isn't reported if label/tooltiptext are specified explicitly - the code rather falls back to using the strings verbatim instead.