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)
Firefox Graveyard
Webapp Runtime
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.
Comment 1•8 years 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?
Comment 2•8 years ago
|
||
(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•8 years 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•8 years 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•8 years ago
|
Summary: disable and remove runtime → disable and remove desktop web runtime (a.k.a. WebRT, webapp runtime)
Assignee | ||
Comment 5•8 years ago
|
||
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•8 years 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
Comment 7•8 years ago
|
||
This patch will also fix bug 1245199 and part of bug 1246071.
Assignee | ||
Comment 8•8 years 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 | ||
Comment 9•8 years ago
|
||
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
Comment 10•8 years ago
|
||
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.
Comment 14•8 years ago
|
||
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 | ||
Comment 15•8 years 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.
Comment 16•8 years ago
|
||
(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•8 years 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•8 years 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•8 years ago
|
||
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 20•8 years ago
|
||
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+
Updated•8 years ago
|
Attachment #8723140 -
Flags: review?(fabrice) → review+
Attachment #8723140 -
Flags: review?(jryans) → review+
Updated•8 years ago
|
Attachment #8723140 -
Flags: review?(dtownsend) → review+
Updated•8 years ago
|
Attachment #8723140 -
Flags: review?(mcastelluccio) → review+
Comment 21•8 years ago
|
||
I've been consumed by a week long build system. Probably won't look at this until tomorrow.
Comment 22•8 years ago
|
||
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•8 years ago
|
||
(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•8 years ago
|
Attachment #8723140 -
Flags: review?(robert.strong.bugs)
Assignee | ||
Comment 25•8 years 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•8 years 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•8 years ago
|
Attachment #8725437 -
Flags: review?(robert.strong.bugs)
Assignee | ||
Comment 27•8 years ago
|
||
Here's the patch rebased against mozilla-central. This is the version I'll land.
Attachment #8725437 -
Attachment is obsolete: true
Assignee | ||
Comment 28•8 years ago
|
||
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.
Comment 32•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b5621f52feab
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
Updated•8 years ago
|
status-firefox48:
fixed → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•