Custom Query (24014 matches)


Show under each result:

Results (88 - 90 of 24014)

Ticket Resolution Summary Owner Reporter
#31567 fixed NS_tsnprintf() does not handle %s correctly on Windows gk mcs

While testing the ESR68-based updater on Windows, Kathy and I found a Windows toolchain problem. We tested using our own 64-bit build (rbm nightly build process) on a Windows 10 system.

We discovered that file paths generated using format strings are corrupted. Specifically, calls to NS_tsnprintf() do not work correctly; apparently, because that is a "wide" function a %s when used in the format string is supposed to mean "expect the arg to be of type WCHAR *". Instead, the args are processed as C-style strings which means they get truncated after the first character (at least when using characters that fit within the first 256 Unicode codepoints).

NS_tsnprintf() is a macro that is defined in toolkit/mozapps/update/common/updatedefines.h (all of the code that uses it is related to the updater). We first noticed that problem when we saw a failure inside updater.cpp's WriteToFile() function. The following code from that function fails because it tries to move filename to a bad path.

#if defined(XP_WIN)
  NS_tchar dstfilename[MAXPATHLEN] = {NS_T('\0')};
  NS_tsnprintf(dstfilename, sizeof(dstfilename) / sizeof(dstfilename[0]),
               NS_T("%s\\%s"), gPatchDirPath, aFilename);
  if (MoveFileExW(filename, dstfilename, MOVEFILE_REPLACE_EXISTING) == 0) {
    return false;

The computed path is C\u (the first character from gPatchDirPath followed by the \ and then the first character of aFilename).

On Windows, NS_tsnprintf() is defined as mywcsprintf which is an inline function that uses _vsnwprintf(). We have not traced this bug deeper than that point, but we did verify that the problems disappear if we replace all occurrences of %s with %S in the NS_tsnprintf() format strings. That is a very ugly fix though, and it would be wrong on macOS and Linux.

#31563 fixed Urlbar search icons disappear after browser restart tbb-team acat

Patch for #30845 fixes this issue on a fresh profile, but not on an already existing profile which was already restarted at least once. On top of that, there is a quite surprising behaviour:

  1. Open Tor Browser ESR68 without patch for #30845.
  2. Restart browser.
  3. Check that search icons have disappeared.
  4. Change pref from #30845 and restart.
  5. Urlbar is unusable, and browser console shows:
1567091784597	addons.xpi-utils	WARN	Synchronous load of XPI database due to getAddonsByType([theme]) Stack: getAddonsByType@resource://gre/modules/addons/XPIDatabase.jsm:1997:21

which might be related, but did not investigate yet.

#31562 fixed The circuit display is not visible on error pages in Tor Browser based on ESR68 tbb-team gk
Description shows a circuit display in 9.0a4 but not in recent nightlies.

Note: See TracQuery for help on using queries.