611250 - 0.10 release blocker bugs

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect)

Description

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

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".

Comment 2

[Myk Melez [:myk] [@mykmelez]]

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?

Comment 3

[Drew Willcoxon :adw]

Bug 604499?

Comment 4

[Dietrich Ayala (:dietrich)]

(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.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

(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.

Comment 6

[Dietrich Ayala (:dietrich)]

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.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(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.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

Platform bug 614757 breaks the "JavaScript library in content script" use case.

Although that use case is critical to the web-accustomed users of the SDK, and we should not ship SDK 1.0 final without a good example of it (nor should Mozilla ship Firefox 4 without fixing that platform regression), it isn't an absolute beta blocker, as we can ship a beta version of the SDK that doesn't support libraries and then add such support in a subsequent SDK beta (or, more accurately, have libraries start working again in a subsequent Firefox beta).

Thus I am removing bug 614757 from the list of blockers and adding bug 615081, which is about removing the jQuery dependency in the reddit-panel example app until the platform regression is fixed.  I will also do everything in my power to get the regression fixed as soon as possible, ideally in the 4.0b8 release.

Comment 9

[Dietrich Ayala (:dietrich)]

(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? :)

Comment 10

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 11

[Myk Melez [:myk] [@mykmelez]]

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.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Note bug 616753, which is not a beta blocker, but which I'd definitely take a low risk fix for.