Closed Bug 611250 Opened 9 years ago Closed 9 years ago
.10 release blocker bugs
This bug tracks code blockers for the Add-on SDK 0.10 release. Ping Myk or Dietrich, or comment here in this bug, to nominate a bug to block the release.
The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product. To filter bugmail related to this change, filter on the word "looptid".
Component: Jetpack SDK → General
Product: Mozilla Labs → Add-on SDK
QA Contact: jetpack-sdk → general
Bug 603907 seems to have become consistent again for me on nightly builds, so we might need to block on a fix for it. Is anyone else seeing it consistently?
(In reply to comment #3) > Bug 604499? I think it should block 1.0 for sure. Having existing add-ons move to Jetpack is good for building trust/interest/excitement. However, I don't think it needs to block the first beta.
(In reply to comment #4) > (In reply to comment #3) > > Bug 604499? > > I think it should block 1.0 for sure. Having existing add-ons move to Jetpack > is good for building trust/interest/excitement. However, I don't think it needs > to block the first beta. I agree. However, I'd really like to get this in for beta 1 nevertheless, and since we don't current have a "beta 1 wanted" list, I put this bug on this bug's blocking list as the next best way to track its priority.
bug 614894 is a problem i've seen multiple times over, and was initially confounded by it myself. since fixing it post-beta would require breaking API changes, nominating it to block the beta.
(In reply to comment #6) > bug 614894 is a problem i've seen multiple times over, and was initially > confounded by it myself. > > fixing it post-beta would require breaking API changes Is that really the case? Couldn't we add the ability to specify relative paths in a future version while continuing to accept the absolute paths generated by require("self").data.url()? After all, we should be able to distinguish between them when parsing the values, no? In fact, we might even be able to simply rely on the IO service to do that, since nsIIOService::newURI automagically parses relative URLs into absolute ones while leaving absolute ones alone when you pass it a (possibly relative) URL string along with a base URI.
(In reply to comment #7) > (In reply to comment #6) > > bug 614894 is a problem i've seen multiple times over, and was initially > > confounded by it myself. > > > > fixing it post-beta would require breaking API changes > > Is that really the case? Couldn't we add the ability to specify relative paths > in a future version while continuing to accept the absolute paths generated by > require("self").data.url()? After all, we should be able to distinguish > between them when parsing the values, no? yes, that's additive only, and sounds like a fine approach. is it time to start a tracking bug for blocking-final yet? :)
Ayan noticed bug 606010 and bug 606013 on Windows when testing the 1.0b1rc1 build. I think those are both intermittent failures and thus not blockers, but noting it here so others are aware.
Bug 593921, comment 8 notes a number of inconsistencies between the parameters for various events emitted by addon-kit modules. Fixing these inconsistencies requires breaking APIs. Thus it is unfortunate that I have identified them now rather than a week or so ago. Nevertheless, it will be much harder to fix them after we release the beta. Thus, even though now is not a good time to do so, I think we have to fix them now anyway, or forever hold our peace with inconsistent APIs that will frustrate developers long into the indeterminate future. So regretfully adding to the list of blockers.
Depends on: 593921
Note bug 616753, which is not a beta blocker, but which I'd definitely take a low risk fix for.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.