Closed
Bug 962829
Opened 11 years ago
Closed 7 years ago
Serve gaia through xpcshell/httpd
Categories
(Firefox OS Graveyard :: Gaia, defect)
Firefox OS Graveyard
Gaia
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: Pike, Unassigned)
References
Details
One of the nice things about hacking on gaia is that you can test it in the browser.
Now, for a setup like an l10n sprint, it'd be awesome if everyone could see the shared status quo on a local service.
With all the logic we have in build/*.js, serving it through httpd.js sounds like a good idea.
Sadly, it doesn't work as of now.
I have a WIP branch at https://github.com/Pike/gaia/tree/bug-962540-update-httpd, also including the work for bug 962540.
The big blocker right now is that for some weird reason, httpd.js doesn't open on the specified 8080 port, but on some random internal port.
Which breaks the request validation logic, as handler._locations is set to listen to 8080.
Waldo, if you'd be willing to take a look, that'd be great.
Also, Yuren, I understand that the work in bug 962540 conflicts heavily with what you're doing in bug 900182.
FWIW, my local.mk is
GAIA_DOMAIN=gaia.l10n
DEBUG?=1
GAIA_INLINE_LOCALES?=0
GAIA_CONCAT_LOCALES?=0
GAIA_APP_TARGET=production
The GAIA_DOMAIN is really just me testing things, it works inside Firefox allright.
I've also tested server(), and the code snippet path around server.start().
No idea what's going on.
PS: I might be working off a point on master that doesn't run desktop too well, but I'm confident that my inability to run desktop twice without clobber or unlocking the homescreen have nothing to do with the httpd.js changes.
Comment 1•7 years ago
|
||
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•