Closed Bug 604641 Opened 9 years ago Closed 9 years ago
Jetpack SDK isn't compatible with Firefox nightlies, Firefox 4 Beta 7 relbranch
+++ This bug was initially created as a clone of Bug #604362 +++ cfx testpkgs -F anymodulethatusesxpcom results in: error: An exception occurred. Traceback (most recent call last): File "resource://testpkgs-jetpack-core-lib/xpcom.js", line 41, in TypeError: Cu.import is not a function and no tests are run. ++++ This blocks our ability to ship beta 7. We should resolve bug 604362, thus resolving this one. Seems to be related to evaluateInSandbox being busted after GC Compartments, but keeping this as a tracking bug in Firefox::General for now.
Summary: JetPack SDK isn't compatible with Firefox nightlies, Firefox 4 Beta 7 relbranch → Jetpack SDK isn't compatible with Firefox nightlies, Firefox 4 Beta 7 relbranch
This looks like a dupe of bug 604363.
Bug 604362 was initially marked as a dupe of bug 604363, but then re-opened as not resolved by that bug. Let's deal with it over there, and close this one out when bug 604362 is closed out.
Will existing Jetpacks start working again with the fixes for bug 604362, bug 604363, or do they have to be rebuilt with a fixed Jetpack SDK?
This will be resolved when the fix for bug 604362 lands on GECKO20b7pre_20101006_RELBRANCH
Once more with more details: I'm on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101018 Firefox/4.0b8pre, which should have the fix for bug 604362. My sample Jetpack is "Bugzilla Tweaks 1.4", which stopped working last week. The question rephrased: do we need a Bugzilla Tweaks 1.5, or should 1.4 actually start working again?
As the developer of the mentioned Jetpack, I'm interested in the answer to comment 7 as well!
There's a chance my nightly didn't have the fix for bug 604362 after all, because peterv's patch was only now included in the big tracemonkey merge http://hg.mozilla.org/mozilla-central/rev/eae6bdacf6d2 Referenced revision in bug 604362 comment 21 was: http://hg.mozilla.org/mozilla-central/rev/f9f10c04dceb
(In reply to comment #8) > There's a chance my nightly didn't have the fix for bug 604362 after all, > because peterv's patch was only now included in the big tracemonkey merge > http://hg.mozilla.org/mozilla-central/rev/eae6bdacf6d2 That's incorrect, it was landed in f9f10c04dceb. Atul, could you respond to comment 4?
Thomas, regarding your question in comment 4, we don't actually have enough information to figure that out yet, unfortunately--peterv's and mrbkap's patches now have us out of the "Cu.import is not a function" error, but we're still running into some weird errors that don't show up in 4.0b6, and I can't yet tell whether this is a problem on our side or SpiderMonkey's side. Will try to find this out asap, but for now we're trying to just get the SDK working with 4.0b6 so we can ship v0.9. Once that's done, we'll come back to this bug.
Whiteboard: [needs bug 604362 to land on GECKO20b7pre_20101006_RELBRANCH]
Today's nightly which includes f9f10c04dceb doesn't seem to have fixed the problem. None of my two installed Jetpack-based addons work in this nightly either.
no, nor has this fixed problems with other page-mod required jetpacks. It does seem to work on some chrome-required jetpacks, or at least the one I tested.
So should bug 604362 be re-opened, or should a new bug be filed?
(In reply to comment #13) > So should bug 604362 be re-opened, or should a new bug be filed? I think bug 604362 is fixed and should stay that way. I believe the page-mod jetpacks are breaking for a different reason, possibly related to the new wrappers, but I'd have to spend some time debugging to be sure. Probably a new bug. Or this one!
Assigning to myk; there may be other bugs on which this can depend, but we can't ship Beta 7 without it being compatible with JetPack.
Assignee: nobody → myk
Whiteboard: [needs bug 604362 to land on GECKO20b7pre_20101006_RELBRANCH]
Myk: do we know what's causing the residual bustage here? How can we help you?
Mike: I don't think we know yet; I certainly don't. Since there aren't nightly builds for the b7 branch, I'm rolling my own, but I'm having some trouble compiling. Do you know if anyone has made a custom b7 build available that I can use to investigate the test failures in the meantime?
(In reply to comment #17) > Mike: I don't think we know yet; I certainly don't. Since there aren't nightly > builds for the b7 branch, I'm rolling my own, but I'm having some trouble > compiling. Do you know if anyone has made a custom b7 build available that I > can use to investigate the test failures in the meantime? Why not just use m-c trunk then? It's busted there as well...
Yes, mozilla-central can act as a proxy. Fix the issue there, and then we can figure out what's needed for the relbranch.
(In reply to comment #19) > Yes, mozilla-central can act as a proxy. Fix the issue there, and then we can > figure out what's needed for the relbranch. Or, you could merge the relbranch onto the default branch, throw everything from default away, commit and push to the try server to get builds form the b7 branch. (Make sure to tag them with "try: -b do -m none -u none -t none" to make sure that you only get builds.)
Ignore Ehsan. He's delightful, but quirky. Get JetPack working with mozilla-central nightlies, then we'll figure out what to do with the relbranch.
Ok, I've been testing with mozilla-central nightlies, isolating tests by module to figure out which modules' tests are failing, and so far the answer is that virtually all modules' tests are failing, and they're failing in a variety of unique and interesting ways (with some overlap). Some (most?) of the failures appear to be the result of compartments regressions that have already been fixed on the tracemonkey branch. When is the next merge of that branch to trunk scheduled? It may make more sense for me to delay further testing until after that merge, to isolate remaining problems from those that have already been found and fixed.
(In reply to comment #22) > Some (most?) of the failures appear to be the result of compartments > regressions that have already been fixed on the tracemonkey branch. When is > the next merge of that branch to trunk scheduled? It may make more sense for > me to delay further testing until after that merge, to isolate remaining > problems from those that have already been found and fixed. Can't you try a tracemonkey nightly?
(In reply to comment #23) > Can't you try a tracemonkey nightly? Yes, I can and have been doing so. And indeed, a number of the problems are resolved. So then the question becomes: how often is the tracemonkey branch synced with the trunk?
(In reply to comment #24) > Yes, I can and have been doing so. And indeed, a number of the problems are > resolved. So then the question becomes: how often is the tracemonkey branch > synced with the trunk? That's good news; can we figure out what changes on the tracemonkey branch have fixed things for you? Those issues need to also be b7 blockers, basically. The JS team can speak better to merge tactics.
(In reply to comment #25) > can we figure out what changes on the tracemonkey branch have > fixed things for you? Those issues need to also be b7 blockers, basically. Bug 606573 and bug 604523 seem likely to have fixed things for the SDK, and, as peterv mentioned, the tracemonkey team is going to pull those into trunk. peterv is also going to spin a try server build with those fixes that I can use to test in the meantime. > The JS team can speak better to merge tactics. I've been chatting with them on IRC, and merges from trunk to branch are not on a set schedule, but the last one happened on October 22 <https://hg.mozilla.org/tracemonkey/rev/cbd5ee95f720>, so the branch is reasonably up-to-date.
(In reply to comment #27) > Bug 606573 and bug 604523 seem likely to have fixed things for the SDK, and, as > peterv mentioned, the tracemonkey team is going to pull those into trunk. > peterv is also going to spin a try server build with those fixes that I can use > to test in the meantime. Actually, we landed them on trunk yesterday so you should be able to use today's nightlies to test. Please let us know what issues remain.
We might also need to fix bug 607284, looking into that.
(In reply to comment #7) > As the developer of the mentioned Jetpack, I'm interested in the answer to > comment 7 as well! OMG, using the tinderbox build from revision c133d3c084c0 Bugzilla Tweaks is working again! There's hope the latest tracemonkey merge did the trick!
indeed. page-mod jetpacks appear to be working again in today's build. (20101027) huzzah!
So this mean this bug is fixed?
(In reply to comment #32) > So this mean this bug is fixed? No, there are still many other test failures. See the bugs blocking this bug for the details. Until all those failures are resolved, the SDK will not be fully compatible with the latest trunk nightly builds of Firefox, and this bug will remain open. Once all the failures are resolved, however, we'll resolve this bug as well.
Can we get all those bugs diagnosed and filed? I am happy to fix.
(In reply to comment #34) > Can we get all those bugs diagnosed and filed? I am happy to fix. I think the filing is just about done (modulo failures that fixes for the current round of failures will reveal), although the diagnosing is still in process. We're working on it!
Moving remaining issues (and this tracking bug) to beta8
blocking2.0: beta7+ → beta8+
I just did a round of testing, and it looks like the landings last night fixed the issues they were intended to fix. The remaining issues are: * bug 608959, Object.create misbehaves across JS sandboxes, for which I have identified a workaround in bug 608866, so this won't prevent us from getting the SDK working on b7; * bug 603906, "have to add the panel" exception in "test-panel.test:destruct before removed", which is a bug in the SDK for which we have a patch in hand; * bug 609066, nsIJetpack.registerReceiver throws NS_ERROR_ILLEGAL_VALUE in e10s tests on trunk nightly, which I just discovered while running the tests, and which is generated by code that just recently landed in the SDK. Of these, bug 609066 is the only worrisome one, because I don't understand it yet, but I think we're going to be ok with it as well, since the tests are testing some new infrastructure that we aren't actually using yet (and thus whose functionality we aren't exposing to users), so worst case scenario we can disable those tests. So I think we're in good shape to ship a next version of the SDK that is compatible with Firefox 4.0b7 (even though we are no longer blocking 4.0b7 on SDK compatibility). I am adding bug 603906 back into the list of dependencies, so we can track the complete set of bugs that need to be fixed to actually make that happen, whether they are in Firefox/platform or the SDK.
The unit test infrastructure is up and running for Mac and Linux (and soon Windows), but not visible by default on tinderbox. You can see the test results here: http://tbpl.mozilla.org/?noignore=1. This allows everyone following along here to see if trunk changes had any effect on the tests, without having to build it yourself. Suite is currently failing on bug 608866.
A checkin today for bug 609066 fixed one set of test failures when testing against the tip, but today's tracemonkey merge caused another (bug 613082), although fortunately it seems pretty trivial to resolve. When testing against 4.0b7, there is still one set of test failures to resolve on the SDK side of things (bug 612179).
Adding output of cfx testall, per Dietrich's suggestion. There are three tests that do not pass for me on OS X using Firefox 4 beta 7 using: f70023e9445892a496ff2d581b03537e2ed949e3 Date: Fri Nov 19 04:19:26 2010 +0100 http://pastebin.mozilla.org/858424
(In reply to comment #40) > Adding output of cfx testall, per Dietrich's suggestion. There are three tests > that do not pass for me on OS X using Firefox 4 beta 7 using: > f70023e9445892a496ff2d581b03537e2ed949e3 > Date: Fri Nov 19 04:19:26 2010 +0100 > > http://pastebin.mozilla.org/858424 This is a regression from the landing of the fix for bug 598981. I have filed bug 613553 on the regression.
There are two open bugs left on the list here, bug 607352 and bug 614757. Bug 607352 is probably not a blocker, since the Add-on SDK is going to work around issues between JS libraries like jQuery and wrapped DOM objects by exposing unwrapped objects to those libraries, and the larger question of JS library compatibility with Mozilla's various wrapping schemes is out of scope for that bug. Thus I am removing it from the list. Bug 614757 remains a blocker, since it prevents developers from using JS libraries like jQuery even with unwrapped DOM objects.
No longer depends on: 607352
614757 is fixed on TM. Give it a spin if you can.
(In reply to comment #43) > 614757 is fixed on TM. Give it a spin if you can. I applied the patch to the tip of mozilla-central, built with it, and tested jQuery in an SDK-based addon (the reddit-panel example addon in the SDK's examples/ directory). It worked! So this patch fixes the problem. Any chance it can get landed on trunk in time to make 4.0b8?
Yeah, its blocking b8.
page-mod (using 0.9 of the SDK) has breakage: ----- error: An exception occurred. Traceback (most recent call last): File "resource://jid0-nrwp7vvcqzcsrtppwwz2npqgekw-jetpack-core-lib/observer-service.js", line 174, in this.callback(subject, data); File "resource://jid0-nrwp7vvcqzcsrtppwwz2npqgekw-addon-kit-lib/page-mod.js", line 180, in _onContentWindow if (RULES[rule].test(window.document.URL)) TypeError: window is null ----- Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101206 Firefox/4.0b8pre I could not find a related bug, but thought I'd post here first in case it is a known issue. Let me know if I need to file a new bug.
Can this bug be marked as fixed now that all of its dependencies are fixed?
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.