The ASCII DEL (127) character was appended to the end of every title bar.
This patch fixes the issue by properly assigning PRE_RELEASE_SUFFIX
to an empty string rather than a literal "". The literal double-quotes
were getting defined to the preprocessor as -DPRE_RELEASE_SUFFIX=""""
and after preprocessing, browser.xul had ASCII DEL (127) characters
instead of the empty string.
Taken from https://bugzilla.mozilla.org/show_bug.cgi?id=611953
Patches 2-5.
Not all patches have positive review yet; there's a question of
whether to ensure a gsettings key exists, due to picture-filename
changing to picture-uri in the middle of the review process.
This is something we can control in the distribution, though, and
don't need to be dynamic about it.
When setting the default browser, we want to set it to 'firefox %s'
instead of '/usr/lib{,64}/firefox-4/firefox %s'
firefox-default.patch did the job for us for a bit, but upstream now
has a patch to do this which we can now use. The patch will check
to see if MOZ_APP_LAUNCHER is passed, and if so, it will use only
the basename when setting the default browser. We already set
MOZ_APP_LAUNCHER, so just need to switch to using the patch.
From https://bugzilla.mozilla.org/show_bug.cgi?id=611953
Patch 1 - Use MOZ_APP_LAUNCHER for default browser executable (v3, un-bitrotted)
This should have been done as part of 59e26d3 but was erroneously
left out. Not doing this would mean that it would be theoretically
possible to update Firefox without a matching XULRunner.
Signed-off-by: Christopher Aillon <caillon@redhat.com>
Don't bother passing a chrome file format in our mozconfig,
omnijar is the default, but it didn't work before.
Adjust the %files list accordingly.
Move various bits to happen before running make install so they
get automatically added to omni.jar.
Make sure to add our prefs file to the manifest file so it gets
pulled in, too.
See http://blog.mozilla.com/mwu/2010/08/13/omnijar-how-does-it-work/
