750936 - disable webapp support on Aurora for Firefox 14

Status: VERIFIED FIXED

(Firefox Graveyard :: Web Apps, defect, P1)

Description

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

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.

Comment 1

[Jason Smith [:jsmith]]

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

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 3

[Jason Smith [:jsmith]]

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?

Comment 4

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

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

Comment 5

[Ed Lee :Mardak]

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

Comment 6

[:Felipe Gomes (needinfo for replies!)]

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)

Comment 7

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

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.

Comment 8

[Asa Dotzler [:asa]]

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

Comment 9

[Jason Smith [:jsmith]]

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

Comment 10

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

Attachment: disable mozApps API/webapp runtime for Aurora Firefox 14

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 11

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 12

[:Felipe Gomes (needinfo for replies!)]

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)

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

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

Comment 14

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

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.

Comment 15

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

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.

Comment 16

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

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 17

[Alex Keybl [:akeybl]]

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.

Comment 18

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

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

Comment 19

[Jason Smith [:jsmith]]

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

Comment 20

[:Gavin Sharp [email: [e-mail]]]

So this is fixed for Firefox 14 now, right?

Comment 21

[Jason Smith [:jsmith]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #20)
> So this is fixed for Firefox 14 now, right?

Right. And verified per comment 19.