Search the Community
Showing results for 'id-less'.
The search index is currently processing. Current results may not be complete.
Found 12 results
-
My Browser Builds (Part 3)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
Well, for future reference: 1. Mozilla do not currently check whether a WebExtension (WE) hosted on AMO works as expected with older Firefox versions ; https://addons.mozilla.org/en-US/firefox/addon/vandal-navigator/versions/ reports that "Works with firefox 48.0 and later", but this is an automated setting generated by AMO infra based on the sheer fact it's a WE add-on... Considering this is a very recent extension, I seriously doubt its author has checked its proper functioning outside of latest release Firefox (88.0.1) and, possibly, latest FirefoxESR (78.x.x)... 2. If you plan to install a WE add-on on Serpent, first make sure it properly works in FxESR 52; if it does, then proceed to install on St52 (with "workarounds" if it's of the id-less type), but even then it's not a given it'll properly work under St52, because of a crippled set of WE-APIs there... This is something I highlighted already in my previous post Well, it isn't like you committed a major mischief , I simply wanted (again) to spare members here of undesired consequences should they follow the much easier (but perilous) route of profile transplantation between different browser applications... I was very active in these threads [now renamed "My Browser Builds (Part 1)"] at an era I witnessed the mass exodus (of XP/Vista users) from the deprecated FxESR 52.9.0 to the then current versions of Serpent 52/55, and, against my own due warnings, people chose easiness over was what the "proper" thing to do: they simply migrated their FxESR52 profiles to St... - and then I would be "summoned upon" to troubleshoot very "weird" issues that, in the end, were due to this improper profile migration; that at a time when there was even closer proximity between FxESR52 and St52 of 2018... Both are forks of the same upstream application, MCP's Pale Moon, but differ as to what development channel they fork; Mypal uses the release (stable) PM channel and NM uses the unstable (dev) PM one... But one should make no mistake: the apps, especially in recent versions, are different enough under the hood that I'd never suggest myself they share the same profile; as you say, it might be much safer to share profiles between Mypal 27 and NM27 but as you move towards more recent codebases, it ceases to be so (e.g., I wouldn't move a Mypal 29.2.0 profile over to NM 28.10.3a1 and vice-versa) ... Of course, it is a trait of the human nature to prefer the easiest/shortest path, so I might sound like "preaching" here ... But, once you've made your own choice, whatever that is, be prepared to suffer any eventual consequences... Best regards -
My Browser Builds (Part 3)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
Dear @IXOYE vandal-1.1.0-fx.xpi is yet another Firefox-targeting Web Extension that will not install on Serpent, because it's a type of WE called an "id-less" one... I have in the past, over many occasions, explained ad nauseam the "why" and "how-to" install such WEs on Serpent... https://msfn.org/board/search/?&q=id-less&search_and_or=or&sortby=relevancy For a more technical analysis on the "why", https://msfn.org/board/topic/177125-my-browser-builds-part-1/page/147/?tab=comments#comment-1164701 For a more "practical" read, https://msfn.org/board/topic/177125-my-browser-builds-part-1/page/100/?tab=comments#comment-1159013 https://msfn.org/board/topic/180462-my-browser-builds-part-2/page/133/?tab=comments#comment-1189182 perhaps could be of help... Bottom line is, you have to edit the extension's manifest.json file so as to add a gecko-id block; repackage and then it'll install in St52... St52 != FxESR 52.9.0, especially with regards to WE APIs, so installing in St52 won't guarantee perfect functioning... And, please, DO NOT follow the advice given by my friend @ArcticFoxie ; transplanting a Fx profile onto St52 (or, worse, to St55) is a sure recipe for profile corruption, often times beyond repair! People, for the millionth time since I've been a member of this community, FIREFOX 52.9.x and SERPENT 52.9.0 are two different applications that have diverged so much over time, that their profiles are NOT INTERCHANGEABLE anymore (without risk of data corruption); just don't do it! Always start with a fresh St52 profile and only transfer vital parts such as bookmarks and, where applicable, passwords... Re-install crucial extensions as needed... -
My Browser Builds (Part 2)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
The original Basilisk 52 project from "upstream" did have WE support, be it somewhat inferior to the one present in the Mozilla 52.6.0 platform they forked off as UXP; the MCP devs disabled/removed some WE features/APIs initially, e.g. id-less WEs were not supported, because Basilisk 52 does not observe extension-signing... Having partial WE support in their test UXP browser application (Basilisk) was something the MCP people felt quite uneasy about, given their lack of any will to further maintain that part of the platform code; coupled with their general disdain/aversion for WE (a Google Chrome spawned and Firefox-aped technology), they finally removed completely all traces of WE support in Basilisk 52 in February 2019 (Basilisk-52.9.2018.12.18 the last with WE support, Basilisk-52.9.2019.02.11 the first with no WE support). After consultation with members here (where are you @Mathwiz ? ) it was decided that Serpent 52 will continue to contain that (partial) WE support in an "unmaintained/use at your own risk" state ; WE related security issues are not being patched by upstream/our current maintainer; if you install from AMO, be warned that many (WE) addons there are marked in a blanket fashion as "working in Fx 48.0 and higher", but often times this is simply not true, because WEs of today are NOT being tested on Fx 48-52 ; additionally, Serpent 52 does not check AMO for WE updates, so that is left upon you (i.e. bookmark a WE addon's page on AMO and visit occasionally for eventual updates); be weary of WE updates, in many cases the updated addon uses WE APIs not present in St52... I personally use several WEs in St52, e.g. the userscript manager Violentmonkey 2.12.9 and userstyle manager Stylus 1.4.23 -
My Browser Builds (Part 2)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
That's because Serpent 52 by default doesn't check AMO (addons.mozilla.org) for installed WEs updates (and if one searches this long thread, will, hopefully, locate related posts of mine... ) If you go to about:config => extensions.update.url, you'll see default URI being https://addons.basilisk-browser.org/?component=aus&reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=%APP_VERSION%&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%¤tAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% i.e. only ABBO is being queried for legacy/XUL extension updates... Should you wish to be notified about WE-updates from AMO, you should point that pref to it via: https://versioncheck.addons.mozilla.org/update/VersionCheck.php?reqVersion=%REQ_VERSION%&id=%ITEM_ID%&version=%ITEM_VERSION%&maxAppVersion=%ITEM_MAXAPPVERSION%&status=%ITEM_STATUS%&appID=%APP_ID%&appVersion=52.9&appOS=%APP_OS%&appABI=%APP_ABI%&locale=%APP_LOCALE%¤tAppVersion=%CURRENT_APP_VERSION%&updateType=%UPDATE_TYPE%&compatMode=%COMPATIBILITY_MODE% NB: 1. You won't be notified about updates from ABBO henceforth... 2. In the case of id-less WEs like GOYT, you'll only be notified about un update being available, but the addons manager (AOM) won't be able to install said update; you'll have to, as you already know already, download manually/patch install.rdf/install from file (or drag-n-drop)... I hope it's clear now,,, -
My Browser Builds (Part 2)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
Good Old Youtube also does a brilliant job of re-instating the non-polymer youtube interface (which is more lenient towards computer resources, especially applicable on older hardware/OSes), but, as it is an id-less Web Extension not supported on Serpent 55/52, it doesn't install out-of-the-box ; but if you modify its manifest.json file to include a gecko-id, then it will install (and work) OK! { "name": "Good Old YouTube", "manifest_version": 2, "version": "1.15.0.1-unsigned", "description": "Switch back to classic YouTube interface!", "icons": { "96": "images/logo.svg" }, "background": { "scripts": [ "shared.js", "options/default-options.js", "logger.js", "reconstruct.js", "background.js" ] }, "content_scripts": [ { "matches": [ "https://www.youtube.com/*" ], "css": [ "styles/hide-alert.css" ], "js": [ "shared.js", "content-script.js" ], "run_at": "document_start" } ], "options_ui": { "page": "options/options.html" }, "permissions": [ "https://www.youtube.com/*", "storage", "webRequest", "webRequestBlocking" ], "applications": { "gecko": { "id": "{482060de-6804-4020-a1b9-16dc012a3c93}" } } } (The id string is identical to the one generated when the extension is installed in FirefoxESR 52.9.x) -
My Browser Builds (Part 2)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
I have a patched (unsigned) Tab Tally v1.2.0 installed (in St52) and AFAICS it doesn't come with a "drop-down menu"; it does come with a toolbar button which, admittedly, doesn't stand out well inside FTDD's dark tab-toolbar (where I put it myself), but the number of open tabs is clearly shown in white - plus, when you hover over its button, a tooltip with dark background but light blue characters is shown: Which version of TT do you have installed? First, there's a legacy version (tab_tally-0.1.1-fx-windows.xpi) to be found inside CAA, the versions currently hosted on AMO are, ofc, all of the WE format; versions 1.0.0 to 1.3.0 are id-less, so, as per recent discussion, won't normally install in St52; version 1.4.0 (latest) is not id-less and does install, but it doesn't display the number of tabs in real time unless clicked (so that's why I avoid it!) ... ... OK, I see now you have probably installed v1.4.0, which does spawn a pop-up menu when left-clicked: It's probably possible via CSS to fix the fonts' colour so it would stand out behind the dark background, but am no CSS wizard ; instead, it should be more straightforward to patch the extension itself, should you wish to stick with v1.4.0 that is: Hint: Patch internal extension file popup.html as below: Line 10: - color: #444; + color: #00ADEE; Regards -
My Browser Builds (Part 2)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
Hello and welcome to the MSFN forums May I ask where did you retrieve an UNSIGNED version of the Kill Sticky firefox extension? This is of the Web Extension (WE) format and, as such, it can't be found inside the CAA addon, while ALL versions of it currently hosted on AMO are SIGNED BTW, the latest version there is 1.6, not 1.4; both claim to be Fx 52 compatible (but we've known from past examples that this is not written in stone, Mozilla may be - and have been - wrong, I'm convinced no-one of their staff manually tests released WEs with older - unsupported - Firefox versions ). Now, although Serpent 52.9.0 has retained whatever limited WE support was originally present in the UXP platform (contrary to official Basilisk 52 which has ditched WE support altogether ), Serpent 52 is NOT ON PAR with Firefox ESR 52.9.0 when it comes to WE support; several WE APIs were removed upstream (by MCP) from Serpent, so telling us that a certain WE addon works in Fx52 but doesn't in St52 isn't something conclusive... I decided to investigate myself, and Kill Sticky v1.4 is an id-less extension, a type of WEs that is not supported in Serpent 52.9.0/UXP out-of-the-box; if you've made the common mistake of transplanting an existing dirty Firefox 52 profile onto Serpent 52/UXP, then it's no surprise the extension got disabled... When changing browsers, always start with a new, clean profile! Trying to install Kill Sticky v1.4 in a Serpent 52 new profile, you'll be met by failure: As already mentioned, this is because it's an id-less WE; but you can patch the XPI file yourself to add the missing id, e.g. edit its manifest.json file like below: { "manifest_version": 2, "name": "Kill Sticky", "version": "1.4", "description": "Kill off the annoying floating things blocking the website you're trying to see", "icons": { "32": "icons/32t.png", "48": "icons/48t.png" }, "background": { "scripts": [ "background.js" ] }, "permissions": [ "activeTab" ], "optional_permissions": ["tabs"], "browser_action": { "default_icon": "icons/32t.png", "default_title": "Kill Sticky" }, "applications": { "gecko": { "id": "kill_sticky@mozilla.org" } } } Of course, that way you'll invalidate the extension's signature, so you can also remove directory META-INF! Have you reached so far yourself? Is this what you mean by an "unsigned" version of KS 1.4? I have no trouble installing my patched version of kill_sticky-1.4-an+fx.xpi in a clean profile of latest Serpent 52.9.0 (2019-12-06); its button shows up in the address bar, the addon is listed as ENABLED in the AOM, and it doesn't get disabled after several browser restarts : Slightly OT, but if you want an extension that can remove "web page overlays", then the legacy extension Behind The Overlay v0.1.6 (via CAA) works nicely in my St52 profile... I personally believe this is not "extension blocklist" related, but deleting a blocklist would only offer a temporary remedy, as the browser will automatically re-download it and place it within its profile... Best regards EDIT: Apparently, boolean user pref extensions.blocklist.enabled (defaults to true) controls the blocklist implementation; there exist several other extensions.blocklist.* prefs, one of which is extensions.blocklist.url; I guess by modifying its current value (string) to an invalid URI, you can stop the browser from fetching it... But I stress I don't believe myself the OP's issue is blocklist related... (but I could be wrong, once more... ) -
My Browser Builds (Part 1)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
... Let us just revisit Tab Tally, shall we? https://addons.mozilla.org/en-US/firefox/addon/tab-tally/versions/ All versions currently listed on AMO are, of course, of the WE format; version 1.0.0 is advertised as being compatible with Firefox 49.0+, versions 1.1.0 through to 1.3.0 advertised as being compatible with Firefox 48.0+; I was particularly interested in one of those older WE versions, because they duplicate the functionality of the XUL ("legacy") version 0.1.1, now removed from AMO (but is recoverable via the CAA extension). All (WE) Tab Tally versions 1.0.0 to 1.3.0 install and function properly in Firefox ESR 52.9.0[1] ; "properly" is actually the "desired-by-me" way (constant visual display of the number of tabs, updated in real time when that changes...); of course, the latest version 1.4.0 also installs there, but with a slightly degraded (IMHO) functionality... But trying to install any one of Tab Tally versions 1.0.0 to 1.3.0 in Serpent 52.9.0, you'll be met by a failure to install in the form of message: That's because v1.0.0 to 1.3.0 are id-less WEs (one only has to inspect their manifest.json files) and Serpent 52 lacks the API to allow installation of id-less WEs (but FxESR 52 does support that API). In version 1.4.0 of Tab Tally, the author re-introduced the "WE-id" feature inside the manifest.json file: "applications": { "gecko": { "id": "@tab-tally" } } and made it compatible with even older Firefox versions (min version lowered from 48.0 to 42.0) and, probably unbeknownst to him, also restored St52 compatibility; 1.4.0, as discussed previously in this thread, would install fine in St52 (but not v1.0.0-1.3.0, which do install and work fine under Firefox ESR 52.9.0... ) -
When Mozilla nuked all "legacy" add-ons from AMO, it appears they also nuked all the "legacy" themes for the older browsers too. At least, the only the ones I could find at AMO were for Firefox 53 and up. But while developers have created several repositories of legacy add-ons, I'm not aware of any repository for legacy themes. This has left users of Firefox 52.9 (and @roytam1's Serpent) without a lot of options to change the look and feel of these browsers. For Serpent 52, about the only theme I found besides the default is a "Photon" theme, available at addons.basilisk-browser.com. It does a good job of making Serpent 52 look like the newer Firefox browsers, but "Photon" isn't everyone's cup of tea. Serpent 55 does have a couple of built-in themes besides the default: a "dark" and a "light" theme. The "Photon" theme doesn't work with Serpent 55, but even if it did, that's still not a huge selection of themes. And while Serpent 55 was forked from Firefox 53, none of the Firefox 53 themes I tried would work with it; it just kept saying the downloaded theme "appears to be corrupt." (Digression: I remember having that problem with an "ID-less" add-on not that long ago, and the Firefox 53 themes indeed seem to be "ID-less." But going through the rigamarole of inserting an ID into manifest.json and removing the META-INF digital signature folder still doesn't allow these themes to install. It would be nice if these browsers could provide error messages more meaningful than "appears to be corrupt.") And of course Firefox 52.9 doesn't even have those limited options! So the purpose of this topic is twofold: One, to solicit knowledge about legacy themes that can be downloaded and installed on these browsers; two; to share tricks that might allow more "modern" themes to work. With that in mind, I'll share my first trick. Firefox and Serpent also have a few hidden "developer" themes built in. Unfortunately, to enable them you have to run some Javascript: LightweightThemeManager.addBuiltInTheme({ id: "firefox-devedition@mozilla.org", name: "Developer Edition", headerURL: "resource:///chrome/browser/content/browser/defaultthemes/devedition.header.png", iconURL: "resource:///chrome/browser/content/browser/defaultthemes/devedition.icon.png", author: "Mozilla" }); Ideally, we'd like to run that when the browser starts; but none of the normal tricks for running JavaScript at browser startup (such as an Autoconfig script) seem to work! So I had to resort to an add-on: http://userchromejs.mozdev.org. Click on v2.0 and tell the browser to allow the add-on to be installed. You'll need to restart the browser when prompted to finish the installation. The add-on creates a file named userchrome.js in the "chrome" subfolder of your profile folder and runs any JavaScript you put in there when the browser starts, so you can just paste the above code at the top (or bottom) of your new userchrome.js file, and restart your browser again. Now type about:addons, press Enter, and click on "Themes" or "Appearance" (whichever one your browser uses) and you'll see a new "Developer Edition" theme listed that you can enable. Even better, the "Developer Edition" theme is actually three themes in one! To see them all, press F12, then click the "Gear" icon near the top right of the developer window that comes up. This will bring up a bunch of options; the one you care about is the "Themes" set of radio buttons near the top middle of the developer window. You can select any of the three "sub-themes" listed, then close the developer window with the X at the top right. OK, now it's your turn. Anyone know of any good themes for these browsers that can be downloaded and installed (ideally for free)? What are your favorites? Any tricks for using, say, Firefox 53 themes on these other browsers?
-
My Browser Builds (Part 1)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
"but Basilisk reports that they all appear to be corrupt. Must be a bad hash somewhere" : This is a generic message given out by Basilisk/Serpent when the WebExtension addon one attempts to install is somehow unsupported/incompatible; only rarely does it actually indicate a corrupt file (due to, e.g., erratic connection during download, etc.). In the case of the referenced extension, the error is caused by a limitation in the set of WebExtension APIs present in Basilisk/Serpent (which, as you know, is only a subset of the WE APIs present in the MozillaESR 52 platform, that UXP forked) ... In fact, Basilisk/Serpent have no support for id-less WE addons, hence the generic error message produced... Easy workaround: Once you download to disk file webrtc_control-0.2.3-an+fx.xpi, open it with 7-zip archiver; first, you can optionally delete the whole META-INF directory, to reduce addon size, since Basilisk doesn't check for extension signing; then, open file manifest.json in an editor and, towards the end, add an arbitrary extension-id, e.g. I added: (modified file, shown here is excerpt starting at line 31) "128": "data/icons/128.png" }, "applications": { "gecko": { "id": "webrtc-control@basilisk.org" } } } Save your patched .xpi file (for me, once I exit my text editor, 7-zip auto-prompts to save the committed changes) and then install to Basilisk via drag-n-drop; it should install now without errors: As discussed previously, the WE version of an addon is preferred over its legacy version when the browser is to be (force-)run in multiprocess (e10s) mode ... -
My Browser Builds (Part 1)
VistaLover replied to roytam1's topic in Browsers working on Older NT-Family OSes
... I spent the better part of last hour researching and reading on this ; the ability to install id-less extensions from AMO into Basilisk was lost (what is called a regression) when the MCP devs decided to remove the internal platform mechanism that effectuated extension signature verification; this happened early on during Basilisk's development, when the (experimental at the time) application was "baking" on top of the (now deprecated) Moebius platform... Put very simply, id-less extensions acquire first a temporary (internal) id and then a permanent one, whose strings are derived from their verified signature hash; you need to have a working internal mechanism to process the add-on's signature and then generate valid id strings for the installation to succeed; but the devs in Moebius wanted to remove that mechanism altogether and not just allow the installation of unsigned extensions, because then unsigned installed extensions would produce warnings inside about:addons (Add-ons Manager, AOM); this is indeed what happens when you install unsigned extensions in FxESR 52 with the pref xpinstall.signatures.required set to false (NB that, as I have posted in another thread, extension signature verification - in FxESR 52 - is still performed in the background for already installed signed extensions and will also be triggered when a new signed extension is about to be installed!). There wasn't uniform agreement between the dev team which features inherited from Mozilla should be kept and what regressed functionality should be restored; Moonchild himself wanted to cut-off reliance on Mozilla-issued certificates (in hindsight, he was probably right, given the recent - May 3rd - armagaddon-2.0 Mozilla debacle), that meant removing the signature verification code; an "incomplete" workaround was implemented in PR #279 (see below); in any case, the focus of the team was always on Pale Moon (which, by design and choice, doesn't support WEs at all), as for Basilisk's inherited WE support, it wasn't very high on their agenda at the time (and we all know how that ended! ). If you've got spare time to spend, some Moebius era GitHub issues and pull requests are linked below: Addons - Can't install some addons: https://github.com/MoonchildProductions/moebius/issues/238 Add ID from a signature if it isn't included in manifest.json: https://github.com/MoonchildProductions/moebius/pull/251 Fix signed extension checks: https://github.com/MoonchildProductions/moebius/issues/277 (emphasis should be put on Moonchild's comment below: https://github.com/MoonchildProductions/moebius/issues/277#issuecomment-356231470 ) Get IDs for ID-less WebExtensions without breaking normal libJAR signature checking: https://github.com/MoonchildProductions/moebius/pull/279 Then the Moebius platform was left to rot... When Basilisk was later ported to UXP Take 2 (now just UXP), the issue of id-less WEs resurfaced: https://github.com/MoonchildProductions/UXP/issues/373 but Moonchild decreed: and he "WON'TFIX"-ed that issue... ; moot point now in the case of official Basilisk, still an issue with the Serpent 52 fork... =============================================== Disclaimer: Had a rough day today , so I might have not grasped 100% correctly what was contained inside the devs' exchanges in the linked issues/PRs; I have the sense the "general idea" is there, but anyone is free to correct any misunderstandings on my part... -
My Browser Builds (Part 1)
roytam1 replied to roytam1's topic in Browsers working on Older NT-Family OSes
basilisk/moebius new build for XP! Test binary: Win32 http://o.rthost.cf/gpc/files1.rt/basilisk-55.0.0a1.win32-git-20180113-0257d770e-xpmod.7z Win64 http://o.rthost.cf/gpc/files1.rt/basilisk-55.0.0a1.win64-git-20180113-0257d770e-xpmod.7z diff: http://o.rthost.cf/gpc/files1.rt/moebius_restoreXP_20171113.7z source patch of ffvpx H264/HEVC/AAC/MP3 Addition: http://o.rthost.cf/gpc/files1.rt/moebius-ffvpx-h264-aac-hevc-mp3-addition.7z Official repo changes since my last build: - Remove warning for "unsigned" extensions. (25384fde4) - Merge branch 'master' into b2g-cleanup (c079d0c2c) - Issue #8 - Remove b2g - Part 3: Freshen up the branch (3eac4125a) - Merge pull request #278 from binoc-central/b2g-cleanup (e76242083) - Disable shared JS memory. (c2650cbe2) - Split border and caret width rounding. (da1aa7c26) - Merge branch 'master' of https://github.com/MoonchildProductions/moebius (89f725fc7) - Revert "WebExtensions - adding ID from an sign, if it isn't in manifest.json" (e71b6d68c) - Revert "Remove warning for "unsigned" extensions." (7ca5a9b10) - Get IDs for ID-less WebExtensions when verification against Mozilla's hard-coded CA is disabled (5d1a090c2) - Issue #280 - Undeprecate viewSource.xul's original/legacy API (85901f8cf) - Merge pull request #281 from binoc-central/viewsource-work (137651aa3) - Merge pull request #279 from JustOff/PR_id_less_we (49ffbebc6) - Remove warning for "unsigned" extensions. (d885a5fe7) - Issue #19 - Do not use generic directory names for platform applications - Part 1: Move browser/ to application/basilisk (68bcc9ca8) - Move --disable-fmp4 to old-configure. (dddc75855) - Move --disable-ffmpeg to old-configure. (38307200e) - Move --disable-wmf to old-configure. (965f95708) - Move MOZ_APPLEMEDIA to old-configure. (b8e1910fa) - Issue #19 - Do not use generic directory names for platform applications - Part 2: Fix hardcoded test paths (8ce9de257) - Issue #19 - Do not use generic directory names for platform applications - Part 3: moz.configure, old-configure, and client.mk (9a3db85d5) - Issue #19 - Do not use generic directory names for platform applications - Part 4: Use MOZ_PHOENIX as the conditional instead of MOZ_BUILD_APP = 'browser' (8ec985ddf) - Issue #19 - Do not use generic directory names for platform applications - Part 5: Make Basilisk build again (a04ac47e2) - Issue #283 - Remove all tests from Basilisk - Part 1: The Tests (0dafff58b) - Issue #283 - Remove all tests from Basilisk - Part 2: moz.build Files (694e38e7c) - Issue #283 - Remove all tests from Basilisk - Part 3: Remove devtools references to Basilisk tests (12f054de9) - Issue #284 - Remove some unused extensions/components from Basilisk - Part 1: Everything except pdf.js from application/basilisk/extensions (8f50bec05) - Issue #284 - Remove some unused extensions/components from Basilisk - Part 2: Remove nightly/aurora branding (3579be37a) - Issue #284 - Remove some unused extensions/components from Basilisk - Part 3: docs directory (4aeb2883c) - Issue #284 - Remove some unused extensions/components from Basilisk - Part 4: tools directory (317a7b872) - Merge pull request #285 from binoc-central/app-work (ad9c76d02) - Merge pull request #286 from binoc-central/tests-work (1e3c67f62) - Merge pull request #287 from binoc-central/cc-basilisk-work (b99c66dc7) - Restore source-editor commands controller for scratchpad & styleeditor menus (d634844e4) - Flatten Basilisk Preferences - Part 1: Rename and Move (ef364db9d) - Flatten Basilisk Preferences - Part 2: Fix Chrome URIs (afdc95771) - Flatten Basilisk Preferences - Part 3: Build System, Jar Manifests, and Cleanup (5e514ea4f) - Merge pull request #292 from binoc-central/pref-work (75358949b) - Merge pull request #290 from janekptacijarabaci/devtools_scratchpad_styleEditor_menu_1 (ff782891b) - Move --enable-replace-malloc out of pyconfigure. (75c7cbf56) - Move MOZ_MEMORY_* defines out of pyconfigure. (951263d5b) - Move --enable-jemalloc and MOZ_JEMALLOC4 out of pyconfigure. (31b8283d1) - Correct line endings (57e405b0a) - Remove independent rust tests (0257d770e)
