Closed Bug 1238079 Opened 8 years ago Closed 8 years ago

disable and remove desktop web runtime (a.k.a. WebRT, webapp runtime)

Categories

(Firefox Graveyard :: Webapp Runtime, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 48

People

(Reporter: myk, Assigned: myk)

References

Details

Attachments

(2 files, 4 obsolete files)

Per the proposal in https://groups.google.com/forum/#!topic/firefox-dev/WV2XkVN3sWQ, we should disable the desktop runtime in Firefox and remove its code from gecko-dev.

This will entrain a variety of dependencies; especially on Marketplace and MDN, which needs to stop offering/documenting desktop as a deployment target for Open Web Apps.

Per the same proposal, we should also disable the Android runtime, which has similar dependencies.  But the work to disable that runtime will be tracked in bug 1235869.
Blocks: 1238129
Depends on: 1238576
Depends on: 1239367
This is quite a shock, since I've been developing Open Web Apps that get deployed using Linxu, Mac, and Windows Firefox for quite a while now. I'm supporting 45 different apps on over 1000 different desktops. But I read that thread, and I can see there's no point crying. Your collective mind seems to be made up, and somebody is going through closing all the bugs I have open about OWA.

What I'm trying to figure out is what to do instead. I've found XULRunner which appears to be a possibility. Using it, I could create a shortcut to firefox with an -app argument, which could open my standalone web app from the cloud (I use appcache to keep things working offline). But before I start digging into that technology, I want to make sure it's not going to be killed, too. Is it? I found an article about you deprecating XUL extensions. Does that mean XULRunner is deprecated too? Or is making apps that are really a very simple browser that opens just one URL a good long-term solution?
(In reply to mrjoshuaesmith from comment #1)
> This is quite a shock, since I've been developing Open Web Apps that get
> deployed using Linxu, Mac, and Windows Firefox for quite a while now. I'm
> supporting 45 different apps on over 1000 different desktops. But I read
> that thread, and I can see there's no point crying. Your collective mind
> seems to be made up, and somebody is going through closing all the bugs I
> have open about OWA.
> 
> What I'm trying to figure out is what to do instead. 

I recommend taking a look at what is now possible with Service Worker. We think most unprivileged packaged Open Web Apps can be statically hosted and then cached using Service Worker, which will work in Firefox and Chrome and Opera. The oghliner project provides one easy way to do this with GitHub pages -- https://github.com/mozilla/oghliner

We're also looking toward how we can implement the various display modes described in the new W3C App Manifest, which includes a "standalone" mode that might give you the experience you're looking for. (see https://w3c.github.io/manifest/#display-modes).
(In reply to Bill Walker [:bwalker] [@wfwalker] from comment #2)
> > What I'm trying to figure out is what to do instead. 
> 
> I recommend taking a look at what is now possible with Service Worker. We
> think most unprivileged packaged Open Web Apps can be statically hosted and
> then cached using Service Worker, which will work in Firefox and Chrome and
> Opera. The oghliner project provides one easy way to do this with GitHub
> pages -- https://github.com/mozilla/oghliner
> 
> We're also looking toward how we can implement the various display modes
> described in the new W3C App Manifest, which includes a "standalone" mode
> that might give you the experience you're looking for. (see
> https://w3c.github.io/manifest/#display-modes).

Well this doesn't answer my question, which is whether XULRunner is going to keep living, or is deprecated.

I need to have an application on the desktop that looks like an application. The user should be able to double-click it and it should run.

I don't have a problem with caching now. I know lots of people think appcache is the devil, but it works perfectly for completely offline apps like mine. So service workers is a lot of change with no benefit. And anyway, they do nothing to help me replace the thing Mozilla is taking away: An easy way to get an app onto the desktop.
mrjoshuaesmith & bwalker: This implementation bug is the wrong forum for a conversation about alternatives to the desktop runtime.  I've emailed both of you with a response, so please follow up in that email thread, or post to webapps, firefox-dev, dev-platform, or another relevant discussion forum <https://www.mozilla.org/en-US/about/forums/>.
Blocks: 1245189
Blocks: 1245199
Summary: disable and remove runtime → disable and remove desktop web runtime (a.k.a. WebRT, webapp runtime)
Attached patch remove the desktop runtime (obsolete) — Splinter Review
Here's a patch to disable and remove the desktop runtime.  I think it's complete, but I'd like to see the result of this try run before I ask someone to review it, since it's hard to test every nook and cranny of the codebase locally:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=15baca8adec7
Assignee: nobody → myk
Status: NEW → ASSIGNED
Here's the Git branch on which I'm doing this work:

https://github.com/mykmelez/gecko-dev/tree/remove-desktop-runtime

And a comparison with the master branch:

https://github.com/mykmelez/gecko-dev/compare/master...remove-desktop-runtime
Blocks: 1246327
This patch will also fix bug 1245199 and part of bug 1246071.
The previous try run failed because it didn't include the changes to disable the mozApps API in bug 1238576.  Here's a try run that incorporates those changes:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e734cda3efd3
Blocks: 1250343
Blocks: 1250347
Blocks: 1250349
Blocks: 1250352
Attached patch remove the desktop runtime (obsolete) — Splinter Review
After a variety of fixes, rebases, and tryserver runs, here's an updated patch that should be complete, along with another tryserver run:

  https://treeherder.mozilla.org/#/jobs?repo=try&revision=9c72d98aa311

I've also filed a variety of followup bugs for various issues that we should address after this work is done.  I'll wait to request review until the results of the tryserver run.
Attachment #8716548 - Attachment is obsolete: true
Why aren't the test that are using http://mxr.mozilla.org/mozilla-central/source/dom/apps/tests/head.js (the ones moved in bug 1242899) failing?

Anyway, we could make them work in b2g by using SpecialPowers.autoConfirmAppInstall instead of confirmNextPopup.
Blocks: 1250603
(In reply to Marco Castelluccio [:marco] from comment #14)
> Why aren't the test that are using
> http://mxr.mozilla.org/mozilla-central/source/dom/apps/tests/head.js (the
> ones moved in bug 1242899) failing?

They'd fail if we still ran them on desktop Firefox, since this patch removes the desktop Firefox webapps-ask-install observers.  But all tests in dom/apps/tests/ are now restricted to Mulet and/or B2G by skip-if instructions in the *.ini files.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #15)
> (In reply to Marco Castelluccio [:marco] from comment #14)
> > Why aren't the test that are using
> > http://mxr.mozilla.org/mozilla-central/source/dom/apps/tests/head.js (the
> > ones moved in bug 1242899) failing?
> 
> They'd fail if we still ran them on desktop Firefox, since this patch
> removes the desktop Firefox webapps-ask-install observers.  But all tests in
> dom/apps/tests/ are now restricted to Mulet and/or B2G by skip-if
> instructions in the *.ini files.

Yes, I remember that we recently disabled them, but I thought we were still running
tests under Mulet on try (but we aren't).
So, what is the policy in these cases? Do we need to fix the tests to make them
pass in Mulet?
(In reply to Marco Castelluccio [:marco] from comment #10)
> Usage of WebappOSUtils should be removed from
> https://github.com/mykmelez/gecko-dev/blob/remove-desktop-runtime/dom/apps/
> AppsUtils.jsm#L19 and
> https://github.com/mykmelez/gecko-dev/blob/remove-desktop-runtime/devtools/
> shared/apps/tests/unit/head_apps.js#L88 as well.

Nice catch, removed from those places (and all others) in https://github.com/mykmelez/gecko-dev/commit/986d93da02bc9c462a5c10c85d1da658458d2a45.

Here's an updated tryserver run.  Because bdahl ran into test failures in unrelated tests in the sibling patch to remove the Android runtime (bug 1235869), this tryserver run triggers all tests:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ddde5a83742
(In reply to Marco Castelluccio [:marco] from comment #16)
> Yes, I remember that we recently disabled them, but I thought we were still
> running
> tests under Mulet on try (but we aren't).

We are, but they're hidden by default.  To show them, check "Show Tier 3" from the "Tiers" dropdown menu in the Treeherder navbar.


> So, what is the policy in these cases? Do we need to fix the tests to make
> them
> pass in Mulet?

We don't need to, but I would like to.  Mulet tests are currently failing for another reason.  But I'll take a look at these tests on Mulet and fix them or file a followup.
Here's the complete patch with minor tweaks from the previous version.  This complete tryserver run shows no regressions:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ddde5a83742

Requesting review from:

fabrice:
  b2g/dev/app.mozbuild

mossop:
  .eslintignore
  browser/*
  toolkit/moz.build
  toolkit/mozapps/installer/windows/nsis/makensis.mk

gps:
  build/*
  config/rules.mk
  configure.in
  python/mozbuild/*

jryans:
  devtools/shared/apps/tests/unit/head_apps.js

jmaher:
  testing/*

marco:
  dom/apps/*
  toolkit/webapps/*
  webapprt/*
Attachment #8722247 - Attachment is obsolete: true
Attachment #8723140 - Flags: review?(mcastelluccio)
Attachment #8723140 - Flags: review?(jryans)
Attachment #8723140 - Flags: review?(jmaher)
Attachment #8723140 - Flags: review?(gps)
Attachment #8723140 - Flags: review?(fabrice)
Attachment #8723140 - Flags: review?(dtownsend)
Comment on attachment 8723140 [details] [diff] [review]
remove the desktop runtime

Review of attachment 8723140 [details] [diff] [review]:
-----------------------------------------------------------------

wow, a lot of changes!
Attachment #8723140 - Flags: review?(jmaher) → review+
Attachment #8723140 - Flags: review?(fabrice) → review+
Attachment #8723140 - Flags: review?(dtownsend) → review+
Attachment #8723140 - Flags: review?(mcastelluccio) → review+
No longer blocks: 1250343
I've been consumed by a week long build system. Probably won't look at this until tomorrow.
Comment on attachment 8723140 [details] [diff] [review]
remove the desktop runtime

Review of attachment 8723140 [details] [diff] [review]:
-----------------------------------------------------------------

I'm requesting an additional review from rstrong to confirm that the deletions from package-manifest.in don't need corresponding additions to removed-files.in. The executable removed from package-manifest.in is the most concerning to me.

::: configure.in
@@ -3607,5 @@
>  ENABLE_SYSTEM_EXTENSION_DIRS=1
>  MOZ_BRANDING_DIRECTORY=
>  MOZ_OFFICIAL_BRANDING=
>  MOZ_FEEDS=1
> -MOZ_WEBAPP_RUNTIME=

This is bit rotted. You'll need to update old-configure.in.

::: testing/mochitest/runtests.py
@@ +367,5 @@
>          self.httpPort = options['httpPort']
>          self.shutdownURL = "http://%(server)s:%(port)s/server/shutdown" % {
>              "server": self.webServer,
>              "port": self.httpPort}
> +        self.testPrefix = "undefined"

It feels like there is a follow-up to remove support for testPrefix?
Attachment #8723140 - Flags: review?(robert.strong.bugs)
Attachment #8723140 - Flags: review?(gps)
Attachment #8723140 - Flags: review+
Attached patch remove the desktop runtime (obsolete) — Splinter Review
(In reply to Gregory Szorc [:gps] from comment #22)
> I'm requesting an additional review from rstrong to confirm that the
> deletions from package-manifest.in don't need corresponding additions to
> removed-files.in. The executable removed from package-manifest.in is the
> most concerning to me.

Ok, makes sense.  I'm looking forward to hearing from Robert!


> ::: configure.in
> @@ -3607,5 @@
> >  ENABLE_SYSTEM_EXTENSION_DIRS=1
> >  MOZ_BRANDING_DIRECTORY=
> >  MOZ_OFFICIAL_BRANDING=
> >  MOZ_FEEDS=1
> > -MOZ_WEBAPP_RUNTIME=
> 
> This is bit rotted. You'll need to update old-configure.in.

Here's the updated patch with that change (and another unbitrotting).


> ::: testing/mochitest/runtests.py
> @@ +367,5 @@
> >          self.httpPort = options['httpPort']
> >          self.shutdownURL = "http://%(server)s:%(port)s/server/shutdown" % {
> >              "server": self.webServer,
> >              "port": self.httpPort}
> > +        self.testPrefix = "undefined"
> 
> It feels like there is a follow-up to remove support for testPrefix?

Good catch!  I filed bug 1252648 to follow that up.
Attachment #8725437 - Flags: review?(robert.strong.bugs)
Attachment #8723140 - Flags: review?(robert.strong.bugs)
Requesting needinfo from rstrong, as his Bugzilla name says to "use needinfo to contact me."

Robert: the patch in this bug removes a set of files from browser/installer/package-manifest.in.  Do those files need to be added to browser/installer/removed-files.in?

The files in question are:

@RESPATH@/webapprt-stub@BIN_SUFFIX@
@RESPATH@/webapprt/webapprt.ini
@RESPATH@/webapprt/chrome.manifest
@RESPATH@/webapprt/chrome/webapprt@JAREXT@
@RESPATH@/webapprt/chrome/webapprt.manifest
@RESPATH@/webapprt/chrome/@AB_CD@@JAREXT@
@RESPATH@/webapprt/chrome/@AB_CD@.manifest
@RESPATH@/webapprt/components/CommandLineHandler.js
@RESPATH@/webapprt/components/ContentPermission.js
@RESPATH@/webapprt/components/DirectoryProvider.js
@RESPATH@/webapprt/components/PaymentUIGlue.js
@RESPATH@/webapprt/components/components.manifest
@RESPATH@/webapprt/defaults/preferences/prefs.js
@RESPATH@/webapprt/modules/DownloadView.jsm
@RESPATH@/webapprt/modules/Startup.jsm
@RESPATH@/webapprt/modules/WebappRT.jsm
@RESPATH@/webapprt/modules/WebappManager.jsm
@RESPATH@/webapprt/modules/WebRTCHandler.jsm

And, for Windows, also:

@BINPATH@/webapp-uninstaller@BIN_SUFFIX@
Flags: needinfo?(robert.strong.bugs)
I pinged rstrong on IRC, and he took a look at the patch, after which he noted that "it should not be necessary to use removed-files.in unless something squirrelly is being done" and the "comments in removed-files.in cover this well," so we should "trust the comments in that file" for these changes.

Thus I'm resolving his needinfo and review requests, and I'll land this after one more rebase to account for the latest changes that have landed on mozilla-central.
Flags: needinfo?(robert.strong.bugs)
Attachment #8725437 - Flags: review?(robert.strong.bugs)
Attached patch remove the desktop runtime (obsolete) — Splinter Review
Here's the patch rebased against mozilla-central. This is the version I'll land.
Attachment #8725437 - Attachment is obsolete: true
Erm, actually *this* is the version I'll land.
Attachment #8727514 - Attachment is obsolete: true
OSX builds started failing when this landed with what looks like bug 1059460, so I landed a CLOBBER touch in 0e4c29a5ea15 to hopefully get it building again.
https://hg.mozilla.org/mozilla-central/rev/b5621f52feab
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.