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

RESOLVED FIXED in Firefox 48

Status

Firefox Graveyard
Webapp Runtime
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: myk, Assigned: myk)

Tracking

unspecified
Firefox 48
Dependency tree / graph

Details

Attachments

(2 attachments, 4 obsolete attachments)

(Assignee)

Description

2 years ago
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.

Updated

2 years ago
Blocks: 1238129
Depends on: 1238576
(Assignee)

Updated

2 years ago
Depends on: 1239367

Comment 1

a year ago
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).

Comment 3

a year ago
(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.
(Assignee)

Comment 4

a year ago
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/>.
(Assignee)

Updated

a year ago
Blocks: 1245189
(Assignee)

Updated

a year ago
Blocks: 1245199
(Assignee)

Updated

a year ago
Summary: disable and remove runtime → disable and remove desktop web runtime (a.k.a. WebRT, webapp runtime)
(Assignee)

Comment 5

a year ago
Created attachment 8716548 [details] [diff] [review]
remove the desktop runtime

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
(Assignee)

Comment 6

a year ago
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
(Assignee)

Updated

a year ago
Blocks: 1246327
This patch will also fix bug 1245199 and part of bug 1246071.
(Assignee)

Comment 8

a year ago
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
(Assignee)

Updated

a year ago
Blocks: 1250343
(Assignee)

Updated

a year ago
Blocks: 1250347
(Assignee)

Updated

a year ago
Blocks: 1250349
(Assignee)

Updated

a year ago
Blocks: 1250352
(Assignee)

Comment 9

a year ago
Created attachment 8722247 [details] [diff] [review]
remove the desktop runtime

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
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.
Duplicate of this bug: 1245199
Duplicate of this bug: 1246071
Blocks: 1250453
Duplicate of this bug: 1246072
Blocks: 1250464
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.
(Assignee)

Updated

a year ago
Blocks: 1250603
(Assignee)

Comment 15

a year ago
(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?
(Assignee)

Comment 17

a year ago
(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
(Assignee)

Comment 18

a year ago
(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.
(Assignee)

Comment 19

a year ago
Created attachment 8723140 [details] [diff] [review]
remove the desktop runtime

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?(jryans) → 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+
(Assignee)

Comment 23

a year ago
Created attachment 8725437 [details] [diff] [review]
remove the desktop runtime

(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)
(Assignee)

Updated

a year ago
Attachment #8723140 - Flags: review?(robert.strong.bugs)
Duplicate of this bug: 1245190
(Assignee)

Comment 25

a year ago
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)
(Assignee)

Comment 26

a year ago
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)
(Assignee)

Updated

a year ago
Attachment #8725437 - Flags: review?(robert.strong.bugs)
(Assignee)

Comment 27

a year ago
Created attachment 8727514 [details] [diff] [review]
remove the desktop runtime

Here's the patch rebased against mozilla-central. This is the version I'll land.
Attachment #8725437 - Attachment is obsolete: true
(Assignee)

Comment 28

a year ago
Created attachment 8727536 [details] [diff] [review]
remove the desktop runtime

Erm, actually *this* is the version I'll land.
Attachment #8727514 - Attachment is obsolete: true

Comment 29

a year ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/b5621f52feab
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.
Duplicate of this bug: 1253769

Comment 32

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/b5621f52feab
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Depends on: 1256667
Product: Firefox → Firefox Graveyard

Updated

a year ago
status-firefox48: fixed → ---
You need to log in before you can comment on or make changes to this bug.