Closed Bug 1215041 Opened 9 years ago Closed 9 years ago

Extension constructor should accept plain strings for resourceURI

Categories

(WebExtensions :: Untriaged, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: jwkbugzilla, Unassigned)

References

Details

This is a minor API simplification. The Extension constructor takes an addonData parameter (http://hg.mozilla.org/mozilla-central/file/0b69d304f861/toolkit/components/extensions/Extension.jsm#l317) which matches the data received by bootstrap.js. This means that the resourceURI property needs to be an nsIURI instance - yet extensions (especially SDK-based extensions) usually deal with strings, and having to create an nsIURI instance complicates things unnecessarily.

The Extension constructor should convert strings to nsIURI automatically, both should be valid for the resourceURI property.
In general I think we should do the conversion in the (SDK-based) extension code instead of adding extra code to the new API to handle the random constraints of older systems.  Phrased another way, if we need to make something more complicated, let's not have it be the new, clean thing.  :)

(Having said that, I could probably be convinced otherwise on a case-by-case basis, and I'm not a peer for this component, so you don't particularly need to convince me anyways…  ;)
There are plenty of extensions out there that aren't based on the SDK. Of course one doesn't have to add this logic to Extension.jsm, there can be some LegacySupport.jsm instead or something like that. But frankly, I don't really see the point of that, both being part of the Firefox codebase.
Flags: blocking-webextensions-
We talked this over in triage a few weeks ago. I thought we'd closed out the bug already.

Designing code in these modules to be accessible by XUL extensions is an explicit non-goal. If anything, we're likely to make changes to discourage it rather than make it easier.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.