Firefox 63.0 release information – ghacks tech news

Firefox users can select Menu > Help > Check for Updates to run a manual check for update on October 23, 2018 or later. Firefox should pick up the new version and either install it directly or prompt the user for installation depending on the browser’s update settings.

The move to the Clang toolchain should improve the performance of Firefox Windows builds. Mac OS X users should notice improved reactions and faster tab switching, and performance improvements on multi-GPU systems. Top Sites Search Shortcuts

Mozilla added search shortcuts to the list of Top Sites in the United States in Firefox 63. A click on the Google or Amazon search shortcut focuses the address bar of the browser and displays one of the new search keywords that Firefox supports.


Keywords associated to search providers give Firefox users options to run searches directly from the browser’s address bar. If you, for example, map sp to Startpage Search you may search from the address bar using "sp keyword", e.g. sp ghacks.

The Quick Heal software program may crash tabs in 32-bit versions of Firefox running on Windows. Quick Heal users may resolve the issue temporarily by disabling the Browser Sandbox feature under Internet & Network until the developer of the program releases an update that fixes the issue. Developer Changes

*The organization added a policy to Firefox that administrators may enable to prevent Firefox from updating.* However, the release notes page as I type this says, “We’re still preparing the notes for this release, and will post them here when they are ready. Please check back later.” Probably the closest thing to what they’ll say is at the release notes page for Nightly 63.0a1. That page says, “The option to Never check for updates was removed from about:preferences. You can use the DisableAppUpdate enterprise policy as a substitute.” Mozilla is using social engineering to eeeease end users into accepting automatic updating in the background, but that won’t work on me at least. Mozilla will be hosing the program with bad updates the same way that Microsoft is messing up systems with it’s frequently bad updates.

*Firefox throws a warning when a user attempts to quit the browser if multiple windows and tabs are open.* They’ve always done this AFAIK. And I always turned the warnings off because I don’t CARE if multiple tabs are open since they reopen with a new instance of FF on my machine. Not clear is disabling the warnings is still an option or not though.

Personally, I agree with this on a number of levels: as a default (i.e checks and updates happened automatically in a new profile) this was good and responsible. Now, as an enforced CHECK at a minimum, it is even better for end-users from a security standpoint (keeping software up to date). The vast bulk of users are not likely to be tech savvy – they’re just end users who browse the web. And those who want to sit back and evaluate changes or any other reason, can choose to stop the auto-updating (it’s so easy, it’s an option in settings). And those who get really annoyed, or the more FF tech savvy crowd, can still disable the checking. No-one is forcing updates.

When the ghacks user.js moved to github, I made the template more “responsible” in some settings so as to not put anyone at risk, but still included the info for those who wanted it – such as not blocking update CHECKing (but I did block actual auto-updates), and not blocking most of safebrowsing (there are no privacy risks in the user.js template (Safe Browsing v4 doesn’t even require a cookie anymore), and not disabling pdfjs (because no-one knows what every end-user has as a pdf reader, e.g. Acrobat).

I had forgotten that, which confirms my “As I understood it ‘firefox.cfg’ can have whatever name, even extension (.cfg or .js) given it’ll always be treated as a script file.” : it’s been some time, I totally forgot the source’s fundamentals :=) (“culture is what remains when you’ve all forgotten”!)

Treated as a javascript file indeed though most of us won’t use it as such. I remember an article digging into the script functionality of the Autoconfig.js (let’s keep it named that way) at https://mike.kaply.com/2016/09/08/debugging-firefox-autoconfig-problems/ which might interest you. I don’t go that far and use Autoconfig only as an enhanced substitute for per-profile’s user.js file : the settings remain active for any new Firefox profile I should open and any profile-specific setting can be added to the profile’s user.js file. But I’m no techie and undoubtedly Autoconfig, by it’s ability to handle javascript, may be brought to a higher potential.

Autoconfig and Policy Templates : I use the latter to handle settings which cannot be found in about:config hence usable in Autoconfig, such as the “DisableAppUpdate” you mention, such as “DisableFirefoxAccounts” (I don’t use FF’s Sync). I guess you know the excellent dedicated FF Webextension named ‘Enterprise Policy Generator – Add-ons for Firefox’ : it makes configuring Policy Templates a breeze.

From there on, assuming Autoconfig runs flawlessly on Linux, all should be fine (be it with Mozilla’s original file naming or mine!). I’m no techie as I said, only aware of what i’m concerned with (which is not an optimal attitude!) but if I can provide any further info (happily located within the inner limits of my home-made knowledge sphere!) don’t hesitate to bring any other question on the table (virtual as all around here!).

@Klaas Vaak & @Tom Hawack: Klaas’ first response indicating success did not show on this web page at “my end” until after I had posted my previous response to this one, even though Klaas had already posted prior. Also I suspect that I’m in an earlier time zone than both of you, so please accept my apologies if my posts arrive at odd times.

* defaultPref(“network.cookie.cookieBehavior”, 1); \* Set “network.cookie.cookieBehavior” as the default value “1”. The default value remains the default value unless set to a user set value – in which case it will persist as the user set value across browser sessions, UNLESS; The user “reset”s the value in about:config, in which case the value will revert back to “1” in this example.

* pref(“network.cookie.cookieBehavior”, 1); \* Set “network.cookie.cookieBehavior” as the value “1” as the active setting; unless, the user changes it during a browser session – if that is the case, the new user set value will take effect ONLY for the duration of the browser session that the change was made in. Termination of the current session browser process and a subsequent browser re-start will see the value revert back to the original value, “1” in this example. *\

* IF however; in the specific example as you have outlined above, where the same preference is listed as 2 different functions in the AutoConfig file (firefox.cfg) in the same order as your example, THEN; The browser will set the active value to “1” on starting a browsing session (the “pref” function). It will stay at that value unless set to a different value during the same browser session by the user, only to revert to the original “pref” function setting after the current session (and any concurrent sessions) is/are terminated, and then a new session is started.

The “defaultPref” function only takes visible effect if and when a user decides to “reset” the value from a user set value or from a “pref” function set value via about:config during the course of a browser session – in your example the “reset” will default to “1”. It is the “pref” function value that will persist when a session (or concurrent sessions) is/are terminated and then re-started. So if for example; the “defaultPref” function value was instead, “2”, and the “pref” function value remained as “1”; then the “reset” will default to “2” only for the course of the current browser session. Terminating that browser session and starting a new session will see the “pref” function value “1” persist as the starting value for the new session.