Remove the following lines from this file and paste into basilisk-branding.js so official & unofficial builds can have different values:
// base url for web-based feedback pages
pref("app.feedback.baseURL", "https://forum.palemoon.org/viewforum.php?f=61");
Specifically for unofficial (New Moon) builds, we need to change a prefs app.support.baseURL and browser.slowstartup.help.url not to point to palemoon.org.
Really we should have separate versions of this file for official and unofficial builds, but since this repo will only be used for unofficial builds, this will do.
Two changes: First, blank out the pref that causes a palemoon.org page to open after updating the New Moon browser. Second, point release notes to the author's blog (as with Serpent) vs. the Pale Moon release notes.
Same change as for Serpent; point the Help / Submit Feedback menu option to the msfn.org topic for unofficial builds of New Moon, instead of the Pale Moon forum.
Serpent Help / Submit Feedback option currently links to Pale Moon forum. This is fine for official builds, but for unofficial builds, it invites feedback that the forum doesn't want to deal with. This change redirects Submit Feedback to a topic at msfn.org devoted to unofficial builds of Serpent.
Some drivers on Linux are not supportive of very large allocation sizes
(esp. applicable to Linux x86 builds of UXP applications) and could
cause issues. Treat this the same way we already do on Mac/Darwin.
Page thumbnails hiccups seem to have resolved, so it can be landed again.
This reverts commit 51792b31a36b9539fdd1b4b85abe486c1652b6c4.
Conflicts:
application/basilisk/modules/DirectoryLinksProvider.jsm
Normally we wouldn't need to send any notifications if the actor was
already destroyed, but it can be a VersionChangeOp which needs to
notify its parent operation (OpenDatabaseOp) about the failure.
So SendFailureResult needs to be called even when the actor was
destroyed. Normal operations redundantly check if the actor was
destroyed in SendSuccessResult and SendFailureResult, therefore it's
ok to call it in all cases here.
We were missing error checks at two points. In one case an error return
is meaningful; in another case it is not, as the problem should have
been guarded against at a higher level by emitting far jump islands soon
enough during pasteup of compiled code.
