An item's lockedness/hiddenness should be defined by a list supplied by the browser for its own internal items, rather than allowing items to specify it, since even system level extensions may abuse locked/hidden. e.g. I may always want to disable the Java integration items, even though it is a system-level extension. However, a browser redistributor that makes customizations in the form of an extension, e.g. Netscape 9.0 may want to make their customizations be hidden from the user... this second type is something that can easily be defined by the distribution. We should have a list of IDs of items that are "locked"/"hidden" and have the RDF datasource say "true" for the em:locked/hidden property only when asked for these IDs.
14 years ago
Status: NEW → ASSIGNED
not making the boat, obviously.
Assignee: bugs → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
QA Contact: bugs → extension.manager
We no longer support the locked and hidden properties.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Dave, for what we have used the locked properties?
(In reply to comment #3) > Dave, for what we have used the locked properties? It meant the extension could not be uninstalled or disabled.
Ok, so on bug 333012 comment 23 you have mentioned distribution bundles. How does it correlate with the proposal from this bug to implement it as a distribution defined list? This bug is not about the properties in the install.rdf file.
This bug is about implementing another way to lock / hide extensions in the same way as the locked / hidden attributes in the install.rdf file and the functionality to lock / hide extension manager extensions has been removed in part due to malicious / ill mannered extensions from doing this to users. Distribution bundles was implemented as part of the distribution system for custom browser distributions. I haven't personally tried them out so perhaps Dave or someone else can comment further about distribution bundles.
You can include many extensions as distribution bundles which has the same effect of including the extension in the application with the old locked and hidden properties. So yes that is the alternative way to package these things now. It is something that is intended for system administrators wanting to packaged functionality with the browser.
Dave, do you have an URL for me which points to the documentation of those distribution bundles? It's not BYOB, right?
Thanks Benjamin! Using such a distribution bundle works perfect. The add-on is hidden and cannot be disabled or removed by the user. I will call that verified invalid.
Status: RESOLVED → VERIFIED
Henrik: Can you update that page with more info since you tested it? In particular, do you put XPIs in that directory or do you put them unzipped with addon IDs as the directory names?
I have simply copied the unzipped content under a subfolder with the extension id. That's all. For updating the docs I would propose someone who knows all the underlying code. Let's put it a request in the keyword field.
Revised the text here: https://developer.mozilla.org/en/extension_packaging#Including_add-ons_in_a_customized_application
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.