gfx/cairo/buggy-repeat.patch@97036ab72558
gfx/cairo/buggy-repeat.patch
Tue, 06 Jan 2015 21:39:09 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 06 Jan 2015 21:39:09 +0100
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
- permissions
- -rw-r--r--
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
1 diff --git a/gfx/cairo/cairo/src/cairo-xlib-display.c b/gfx/cairo/cairo/src/cairo-xlib-display.c
2 --- a/gfx/cairo/cairo/src/cairo-xlib-display.c
3 +++ b/gfx/cairo/cairo/src/cairo-xlib-display.c
4 @@ -216,6 +216,8 @@ _cairo_xlib_display_get (Display *dpy)
5 XExtCodes *codes;
6 int major_unused, minor_unused;
8 + static int buggy_repeat_force = -1;
9 +
10 /* There is an apparent deadlock between this mutex and the
11 * mutex for the display, but it's actually safe. For the
12 * app to call XCloseDisplay() while any other thread is
13 @@ -308,6 +310,26 @@ _cairo_xlib_display_get (Display *dpy)
14 if (VendorRelease (dpy) <= 40500000)
15 display->buggy_repeat = TRUE;
16 }
17 +
18 + /* XXX workaround; see https://bugzilla.mozilla.org/show_bug.cgi?id=413583 */
19 + /* If buggy_repeat_force == -1, then initialize.
20 + * - set to -2, meaning "nothing was specified", and we trust the above detection.
21 + * - if MOZ_CAIRO_BUGGY_REPEAT is '0' (exactly), then force buggy repeat off
22 + * - if MOZ_CAIRO_BUGGY_REPEAT is '1' (exactly), then force buggy repeat on
23 + */
24 + if (buggy_repeat_force == -1) {
25 + const char *flag = getenv("MOZ_CAIRO_FORCE_BUGGY_REPEAT");
26 +
27 + buggy_repeat_force = -2;
28 +
29 + if (flag && flag[0] == '0')
30 + buggy_repeat_force = 0;
31 + else if (flag && flag[0] == '1')
32 + buggy_repeat_force = 1;
33 + }
34 +
35 + if (buggy_repeat_force != -2)
36 + display->buggy_repeat = (buggy_repeat_force == 1);
38 display->next = _cairo_xlib_display_list;
39 _cairo_xlib_display_list = display;
