Last Comment Bug 783709 - Launching a web application on Nightly shows a window with no title and white content
: Launching a web application on Nightly shows a window with no title and white...
: regression
Product: Firefox Graveyard
Classification: Graveyard
Component: Web Apps (show other bugs)
: 17 Branch
: All All
: -- normal
: Firefox 17
Assigned To: Myk Melez [:myk] [@mykmelez]
: Jason Smith [:jsmith]
: 783911 (view as bug list)
Depends on:
Blocks: 770770
  Show dependency treegraph
Reported: 2012-08-17 16:05 PDT by Jason Smith [:jsmith]
Modified: 2016-02-04 15:00 PST (History)
9 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---

patch v1: obvious, trivial fix (568 bytes, patch)
2012-08-18 11:08 PDT, Myk Melez [:myk] [@mykmelez]
felipc: review+
myk: checkin+
Details | Diff | Splinter Review

Description Jason Smith [:jsmith] 2012-08-17 16:05:33 PDT

1. Go to
2. Install a web application
2. Launch the web application


The application should launch with no errors.


The application window launches, but the title does not appear. A whitebox is seen in the window instead.
Comment 1 Jason Smith [:jsmith] 2012-08-17 16:23:09 PDT
Also reproduce on Ubuntu 12, so this likely OS independent. Getting a regression range now.
Comment 2 Jason Smith [:jsmith] 2012-08-17 16:33:19 PDT
Firefox Web Apps Regression Range

- 8/1/2012 Windows 7 - Working
- 8/10/2012 Windows 7 - Working
- 8/15/2012 Windows 7 - Working
- 8/16/2012 Windows 7 - Busted
- 8/17/2012 Windows 7 - Busted
- 8/17/2012 Ubuntu 12 - Busted

Getting a changelog shortly.
Comment 4 Jason Smith [:jsmith] 2012-08-17 16:46:42 PDT
Broken changeset:

Bug likely to cause this - bug 770770.
Comment 5 Myk Melez [:myk] [@mykmelez] 2012-08-18 11:08:35 PDT
Created attachment 653086 [details] [diff] [review]
patch v1: obvious, trivial fix

Apps still work on my debug build, which explains why I didn't see the problem while testing the fix for bug 770770.

This is a packaging bug: bug 770770 added a module but neglected to add it to the installer manifest, so it doesn't get packaged and isn't found when imported by webapp.js during startup.

Here's the obvious, trivial, one-line fix.

Requesting review from either Drew or Felipe, on the off-chance one of them is watching his bugmail this weekend, so we can land this sooner than later.
Comment 6 Myk Melez [:myk] [@mykmelez] 2012-08-18 14:37:52 PDT
Comment on attachment 653086 [details] [diff] [review]
patch v1: obvious, trivial fix
Comment 7 :Gavin Sharp [email:] 2012-08-18 18:02:55 PDT
Shouldn't we package webapprt/modules/*, like we do for modules/*? would avoid this problem in the future...
Comment 8 Phil Ringnalda (:philor) 2012-08-19 11:25:03 PDT
Comment 9 Myk Melez [:myk] [@mykmelez] 2012-08-19 13:20:51 PDT
(In reply to :Gavin Sharp (use for email) from comment #7)
> Shouldn't we package webapprt/modules/*, like we do for modules/*? would
> avoid this problem in the future...

One version of the patch in bug 725408 used a webapprt/* wildcard to package all files in that directory, but in bug 725408, comment 53, bsmedberg expressed a preference for listing each file.

And doing so turned out to be useful for this patch, which builds mochitest.xul and mochitest.js (for use during testing) but does not package them.

Nevertheless, perhaps the considerations are different for a module-specific wildcard (webapprt/modules/*).  cc:ing bsmedberg for his thoughts.
Comment 10 Ted Mielczarek [:ted.mielczarek] 2012-08-20 04:38:11 PDT
Note that we already package dist/bin/modules/* that way:
Comment 11 :Gavin Sharp [email:] 2012-08-20 16:49:47 PDT
Yeah, dist/bin/webapprt/* is different than dist/bin/webapprt/modules/*. With the latter, it's less likely that you'll accidentally package an unwanted file.
Comment 12 :Gavin Sharp [email:] 2012-08-20 16:53:30 PDT
I filed bug 784209 for that.
Comment 13 Jason Smith [:jsmith] 2012-08-24 17:02:57 PDT
*** Bug 783911 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.