summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Bug 26381: about:tor page does not load on first start inbug_26381Richard Pospesel2018-09-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | localized windows bundle Child content processes require certain directories to be marked as readable or writeable when Sandboxing is enabled. The directories to be whitelisted are saved in static variables in sandboxBroker.cpp and are initialized in SandboxBroker::GeckoDependentInitialize(). Any child content process which is created before these directories are saved will be unable to read or write to them when the sandbox level is greater than 2 on Windows. The tor-launcher extension triggers the creation of various content processes (by creating windows) after the tor daemon is created. If these processes are created before the directories to whitelist are known, then we get various failed states after Tor Browser launches: a broken about:tor tab, or an even more broken white tab. Prior to this patch, tor-launcher would launch tor after receiving the profile-after-change notification, which fires after all of the various components registered with the category manager (including the tor-launcher services) have finished initializing. This enabled a race condition such that if tor.exe launched too quickly, tor-launcher would attempt to create the networks settings window before the SandboxBroker had initialized which triggered the various child content processes to launch. Depending on the timings invoved, the first 1 or 2 child processes would be created without the necessary directories white-listed, resulting in the various bad initial tab states outlined above. This patch changes tor-launcher to wait for the final-ui-startup notification before launching tor. This notification fires after firefox has done all of the required initialization needed to launch content processes.
* Version bump for 0.2.16.4Georg Koppen2018-09-03
|
* Translations updateGeorg Koppen2018-09-03
|
* Bug 25405: cannot use Moat if a meek bridge is configuredKathy Brade2018-09-03
| | | | | | | When doing Moat things, use a separate profile for the secondary browser (instead of trying to use the main meek helper profile). This is accomplished by setting a TOR_BROWSER_MEEK_PROFILE environment variable which meek-client-torbrowser uses to get the profile path if it is set.
* Translations updateGeorg Koppen2018-08-31
|
* Bug 27392: Update Moat URLsGeorg Koppen2018-08-30
|
* Release preparationsGeorg Koppen2018-08-16
| | | | Version bump
* Translations updateGeorg Koppen2018-08-16
|
* Bug 27129: Add locales ca, ga, id, is, nbArthur Edelstein2018-08-13
|
* Bug 26985: Help button icons missingKathy Brade2018-07-31
| | | | | | The image we previously used has been removed from Firefox, so use ESR 60's new help button image instead. Background shading is used for the hover and active states.
* Bug 25509: Improve the proxy help text.Kathy Brade2018-07-31
|
* Version bump and translation updateGeorg Koppen2018-06-23
|
* Bug 26466: Remove sv-SE from tracking for releasesGeorg Koppen2018-06-23
| | | | | sv-SE is essentially not used for Swedish translations. We should fall back to sv.
* Version bumpGeorg Koppen2018-06-22
|
* Translations updateGeorg Koppen2018-06-22
|
* Bug 20628: Add locales bn-BD, da, he, sv, zh-TWArthur Edelstein2018-06-21
|
* Merge remote-tracking branch 'sysrqb/bug25750_6'Georg Koppen2018-05-23
|\
| * Synchronize some prefs.js and get{Bool,Char,Int}Pref() defaultsMatthew Finkel2018-05-22
| |
| * Replace nsIScriptableDateFormat with Services.intl.DateTimeFormatMatthew Finkel2018-05-22
| | | | | | | | | | | | | | In bug 1313625 Mozilla ripped out support for nsIScriptableDateFormat because ECMAScript now has support for this. This change is based on bug 1383463.
| * Load default prefs during initializationMatthew Finkel2018-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In bug 1413413 Mozilla ripped out support for loading default prefs from extensions. Unfortunately, backing out that changeset is non-trivial so it is easier if we set the default prefs manually. Here we define a function named pref() and it sets the preference based on the type of the pref's value. We only support a few types: boolean, number, and string. All other types are handled by the default case where a message is logged and the pref is skipped. The default prefs must be set before Tor Launcher begins making decisions based on them. An exception is thrown with Cr.NS_ERROR_NOT_INITIALIZED when this requirement is violated.
| * Mozilla ripped out nsIPrefBranchInternalMatthew Finkel2018-05-22
| | | | | | | | | | | | | | Apparently nsIPrefBranchInternal was a trivial subclass of nsIPrefBranch, so we simply switch which class we use. https://bugzilla.mozilla.org/show_bug.cgi?id=1374847
| * Fix deprecated octal literalsMatthew Finkel2018-05-22
| | | | | | | | See https://bugzilla.mozilla.org/show_bug.cgi?id=1263074
| * Mozilla dropped support for Ci.nsIProgrammingLanguage.JAVASCRIPTMatthew Finkel2018-05-10
| | | | | | | | See https://bugzilla.mozilla.org/show_bug.cgi?id=1149830#c18
| * Add fennec target applicationMatthew Finkel2018-05-07
| |
* | Bug 20890: Increase control port connection timeoutKathy Brade2018-05-16
| | | | | | | | | | On slow computers, it can take longer than 30 seconds for Tor Launcher to connect to the tor control port. Increase the timeout to 5 minutes.
* | Release preparations for 0.2.15.2Georg Koppen2018-05-03
| |
* | Translations updateGeorg Koppen2018-05-03
|/
* Bug 25807: Change front domain to unbreak MoatGeorg Koppen2018-04-26
| | | | | | | Google forbids to use www.google.com as front domain now, breaking Moat. We change that domain to dontbeevil.appspot.com which seems still to be working. That's only a stopgap solution, though, to get Moat unblocked for now.
* Release preparations for 0.2.15.1Georg Koppen2018-03-08
| | | | Version bump
* Translations updateGeorg Koppen2018-03-08
|
* Bug 23136: Moat integration (fetch bridges for the user)Kathy Brade2018-03-01
| | | | | | | | | | | | | | | | Modify the setup wizard and Network Settings window to allow automated retrieval of bridges using Moat, a BridgeDB service which works over a meek transport and requires the user to solve a CAPTCHA to obtain bridges. The new tl-bridgedb.jsm JavaScript module handles all communication with BridgeDB, and it functions by starting a copy of meek-client-torbrowser and operating as a PT client parent process (see https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt). This feature can be disabled (and the Moat-related Tor Launcher UI hidden) by setting the pref extensions.torlauncher.moat_service to an empty string.
* Version bumpGeorg Koppen2018-02-21
|
* Translations updateGeorg Koppen2018-02-21
|
* Bug 25089: Special characters not escaped in proxy passwordKathy Brade2018-02-02
| | | | | Modify the _strEscape() function to enclose strings in double quotes when they contain a '#' character.
* Release preparations for 0.2.14.3Georg Koppen2018-01-18
| | | | Translations update and version bump
* Update translationsGeorg Koppen2018-01-17
|
* Release preparations for 0.2.14.2Georg Koppen2017-12-18
| | | | Translations update and version bump
* Bug 24428: bootstrap error message sometimes lostKathy Brade2017-12-18
| | | | | Avoid replacing an error message with a generic bootstrap progress message.
* Bug 10573: Replace deprecated nsILocalFile with nsIFileArunaMaurya221B2017-12-18
|
* Bug 24624: tbb-logo.svg may cause network accessKathy Brade2017-12-14
| | | | | Remove www.w3.org DTD, unused xlink namespace declaration, and "Generator" comment.
* Bug 24623: revise "country that censors Tor" textKathy Brade2017-12-14
| | | | | List Egypt, China, Turkey as countries that may block Tor. This list was derived from data provided by OONI.
* Release preparations for 0.2.14.1Georg Koppen2017-11-10
| | | | Version bump
* Translations updateGeorg Koppen2017-11-10
|
* Revert "Translations update"Georg Koppen2017-11-09
| | | | | | | This reverts commit 34eeec4bd5d1f73da11a78b8aa4e9d78211b213b. This did not pick up our news strings as Transifex did not include them yet
* Version bumpGeorg Koppen2017-11-09
|
* Translations updateGeorg Koppen2017-11-09
|
* Bug 23262: implement integrated progress bar (Part 2)Kathy Brade2017-11-09
| | | | | | | | | | | | Improve UX by greatly reducing the use of modal alert dialogs. In most cases errors are now displayed using one of three techniques: 1. Via an overlaid error panel. 2. As a message on the progress panel (with a Reconfigure button). 3. On a standalone error page within the setup wizard. Move "Restart Tor" to a separate panel. Fix a problem where showAlert() would fail to display an alert: do not try to use a hidden window as the parent for the alert. Add a showOrHideElemById() utility function and use it.
* Bug 23262: implement integrated progress bar (Part 1)Kathy Brade2017-11-09
| | | | | | Replace the old progress window with a progress page that is part of the setup wizard and a progress panel that is part of the Network Settings window.
* Bug 23261: implement configuration portion of new Tor Launcher UIKathy Brade2017-11-09
| | | | | | | | | | | | | | | | Eliminate several wizard pages and include all of the bridge and proxy settings on one page. Use the new Tor Browser logo. Reuse Mozilla's help button from the Firefox hamburger menu and add help for the proxy settings.. In the wizard, use a "pageshow" event listener to show page-specific titles and to hide/show the navigation buttons as needed. After the user chooses to restart the tor process, display the "Waiting for Tor to start" panel. When tor is restarted by the user, disable networking so that bootstrapping does not begin right away; this allows the user to make configuration choices first. Do not try to connect to the control port if tor is not running.
* Version bump (0.2.13)Georg Koppen2017-11-09
|
generated by cgit v1.2.1 (git 2.18.0) at 2024-02-02 10:28:01 +0000