Since landing support for webapp installation and execution via the installers (bug 731541, bug 739636) and runtime (bug 725408), among other changes, we've fixed a number of bugs in the implementation and implemented some valuable enhancements, most of which landed after the merge to Aurora for Firefox 14. Although the initial implementation was sufficiently functional and complete to have landed on central, it didn't meet quality/completeness standards for release to hundreds of millions of existing Firefox users, with major bugs like a failure to execute webapps on Windows XP/Vista (bug 747470) and important enhancements like the ability to open windows (bug 746217), which many webapps need to integrate with third-party identity providers (including Mozilla Persona). The current implementation is much better, but there are still a number of bugs and functionality gaps that feel important to address before we ship this major new feature, like a failure to display WebGL 3D graphics (bug 749459) and support for executing while offline (bug 749029). And the necessary changes (including those that have already landed) would be difficult to uplift to Aurora, which has relatively little tolerance for bug fixes (and none for enhancements). So we should disable webapp support on Aurora for Firefox 14 while we continue to fix and enhance the feature across the entire stack of components that implement it (mozApps API, installers, launcher, runtime) for release in Firefox 15.

As an extension to the description above, reasons for moving to FF 15 include: - Outstanding significant UX issues with FF profile vs. native apps and what happens after I install an app - Manifest sanitization problems - Too strict, causing localization issues - How to support loading resources on allowed origins for pop-ups and windows - Plugin Management - Disabling globally installed add-ons - Geolocation support - Breakpad Integration - Need for unit tests

Assigning this to Jason, if someone else is going to be on the hook for the backout please reassign accordingly.

Hmm, I'm the QA lead for the task, probably better as QA contact. We need a developer assigned to this. Myk - Who would be appropriate for this? You? Felipe?

Felipe and I are both appropriate. I'll take it and ask Felipe for review of the patch.

(I wonder if that's even "right"! Myk, wouldn't you just take Felipe's patch from bug 741415 and apply it to aurora? ;) )

Is the goal here to remove the .mozApps api from 14, similarly to bug 741415? If so the patch will be the same, and I can take it. (ops mid-air, posting comment anyway)

The goal is to both remove the .mozApps API and disable the runtime via its configure flag. So the patch won't be exactly the same as the one in bug 741415. Felipe, you are nevertheless welcome to take the bug if you'd like to do so.

not a k9o blocker but this already has the tracking 14 flag.

We should probably take care of this before June 5th - Let's not let code for web apps get active on beta again (like what happened in FF 13).

This should do the job, although it only disables the API in a packaged instance of a build. But that's what we did for Firefox 13, so it should be sufficient. Ideally we'd disable the API in an unpackaged instance too, to make the change easier to test. Presumably that would require disabling the processing of Webapps.manifest (and perhaps also Webapps.js and Webapps.jsm) in dom/base/Makefile.in. But perhaps B2G/Fennec also use the Aurora branch, so we'd need to disable it conditionally (f.e. if MOZ_PHOENIX is set)? Requesting feedback from bsmedberg for his thoughts on the value of doing extra work to disable the API in an unpackaged instance (and, if it's worth it, how best to do it). Note: I've tested that the files don't get packaged, but I haven't tested that the API doesn't show up in content, because my Aurora builds keep crashing on startup. They do that both with and without this patch, so it doesn't seem to be the patch. Not sure what it is, though; perhaps my recent Xcode upgrade?

Comment on attachment 628088 [details] [diff] [review] disable mozApps API/webapp runtime for Aurora Firefox 14 Looks fine to me. Probably a good idea to run this by tryserver to see if nothing else was depending on that.

p.s. I realized that pushing this to try from m-c might show that the mochitests that landed for FF15 will fail, so to get an accurate result we really need to push to try from aurora. (let's see if I can remove the tag before the bot notices)

[Triage Comment] We're going to be merging FF14 to the Beta channel tomorrow, will this be ready and/or disabled before then?

Comment on attachment 628088 [details] [diff] [review] disable mozApps API/webapp runtime for Aurora Firefox 14 [Approval Request Comment] Bug caused by (feature/regressing bug #): This is actually about disabling a feature, not backing out a fix that caused a regression. The feature in question is webapps, and it should be disabled because there are still a number of bugs and functionality gaps that feel important to address before we ship it. User impact if declined: exposure to feature that is not ready. Testing completed (on m-c, etc.): It hasn't been tested on mozilla-central because we aren't disabling the feature there. But I tested it on my local aurora clone, and I just pushed it to tryserver per felipe's suggestion (although I don't quite understand the mechanism by which one can push a patch from aurora to tryserver): https://tbpl.mozilla.org/?tree=Try&rev=b1b72ca9144d Risk to taking this patch (and alternatives if risky): The patch is straightforward, and the risk is low. String or UUID changes made by this patch: none. Cancelling feedback request, as felipe's review is good enough, and requesting approval to land this on aurora, which I can do later tonight or early tomorrow morning in time for the merge.

The tryserver run failed with bizarre logs. I'm not sure what's going on there, but perhaps it's because tryserver doesn't support trying a change to aurora? (The tryserver docs don't explicitly say that won't work, but they certainly suggest that tryserver is for testing changes to central.) In any case, I just pushed the central equivalent to tryserver: https://tbpl.mozilla.org/?tree=Try&rev=34c50e829a0a Note: it isn't the identical patch, since conflicting (and redundant) changes have landed on central in the meantime. But it is the equivalent patch.

The central equivalent try succeeded, modulo the usual intermittent failures, plus a consistent failure of the mochitests for webapps, which I neglected to disable in the patch for central. But those tests aren't on aurora, so they won't fail there.

Comment on attachment 628088 [details] [diff] [review] disable mozApps API/webapp runtime for Aurora Firefox 14 [Triage Comment] Please land on mozilla-aurora asap - the merge is happening this afternoon PT. Please also make sure to update the status flags on the original webapp bug to make sure it's marked as "disabled" for FF14.

(In reply to Alex Keybl [:akeybl] from comment #17) > Please land on mozilla-aurora asap - the merge is happening this afternoon PT. https://hg.mozilla.org/releases/mozilla-aurora/rev/6ad83fbedd69 > Please also make sure to update the status flags on the original webapp > bug to make sure it's marked as "disabled" for FF14. There are multiple such bugs, but bug 725408 is the main one, and I marked it as disabled for Firefox 14.

Verified on FF 14 Beta 1. Note that there is a problem right now where the HTML implementation does not work at all, but that's a separate issue (the HTML implementation does not even come up).

So this is fixed for Firefox 14 now, right?

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #20) > So this is fixed for Firefox 14 now, right? Right. And verified per comment 19.