Closed Bug 611250 Opened 9 years ago Closed 9 years ago

0.10 release blocker bugs

Categories

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

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: myk, Assigned: myk)

References

Details

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.
Blocks: 611252
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
Depends on: 612664
Depends on: 612676
Depends on: 612678
Depends on: 612681
Depends on: 612685
Depends on: 612716
Depends on: 612719
Depends on: 612733
Depends on: 612735
Depends on: 612757
Depends on: 612758
Depends on: 612761
Depends on: 612770
Depends on: 613071
Depends on: 613082
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?
Depends on: 612179
(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.
Depends on: 613200
Depends on: 613327
Depends on: 613328
Depends on: 613330
Depends on: 613335
Depends on: 613336
Depends on: 613339
Depends on: 613340
Depends on: 613341
Depends on: 613348
Depends on: 604499
Depends on: 610507
(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.
Depends on: 613553
Depends on: 613627
Depends on: 613653
Depends on: 613691
Depends on: 610310
Depends on: 614128
Depends on: 614129
Depends on: 614130
Depends on: 614259
Depends on: 614339
Depends on: 614340
Depends on: 614341
Depends on: 614343
Depends on: 614344
Depends on: 614613
Depends on: 614699
Depends on: 614753
Depends on: 614757
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.
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.
Assignee: nobody → myk
Depends on: 615081
No longer depends on: 614757
Target Milestone: -- → 0.10
Depends on: 596053
Depends on: 615164
(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? :)
Depends on: 615573
Depends on: 610624
No longer depends on: 610624
Depends on: 616166
Depends on: 616140
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.
Depends on: 616541
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.
Depends on: 616736
Depends on: 616754
Depends on: 616755
Depends on: 616741
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: 0.10 → 1.0b1
You need to log in before you can comment on or make changes to this bug.