Summary: | www/tor-browser: output in small rectangle only | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Ott Köstner <ottkostner> |
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> |
Status: | Closed FIXED | ||
Severity: | Affects Only Me | CC: | agh, dan.kotowski, freebsd, grahamperrin, jsm, leres, mbeis |
Priority: | --- | Flags: | grahamperrin:
maintainer-feedback?
(freebsd) |
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any | ||
URL: | https://forums.freebsd.org/threads/tor-browser-issue.94854/ | ||
Attachments: |
Description
Ott Köstner
2024-09-14 17:42:44 UTC
Thanks. Importance: affects some people. From Firefox Desktop Community at <https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org/$W8FIzwJt090XSdvk5rJfc_HGccgoNn6QxpnKHMFZO6I?via=mozilla.org&via=matrix.org&via=kde.org>: > That looks way too tiny, but that's the letterboxing thing tor implements > to mitigate fingerprinting > Yes that does look like letterboxing has gone awry From comment #0: > Port version is: tor-browser-13.5.a9_3 > System: 14.1-RELEASE-p3 Not reproducible with 13.5.a9_1 from quarterly on 14.1-RELEASE-p4 with SCFB on an old MacBook Pro. ---- The same old Mac: not reproducible with 13.5.a9_3 from latest in the midst of packages from quarterly. root@fourteen-pkgbase:~ # freebsd-version -kru ; uname -mvKU 14.1-RELEASE-p4 14.1-RELEASE-p4 14.1-RELEASE-p4 FreeBSD 14.1-RELEASE-p4 releng/14.1-n267709-86d01789bf41 GENERIC amd64 1401000 1401000 root@fourteen-pkgbase:~ # pkg -vv | grep -B 1 -e url -e enabled FreeBSD-ports: { url : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/quarterly", enabled : yes, -- FreeBSD-base: { url : "pkg+https://pkg.FreeBSD.org/FreeBSD:14:amd64/base_release_1", enabled : yes, root@fourteen-pkgbase:~ # cd /tmp root@fourteen-pkgbase:/tmp # wcurl https://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/tor-browser-13.5.a9_3.pkg % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 67.9M 100 67.9M 0 0 1059k 0 0:01:05 0:01:05 --:--:-- 1027k root@fourteen-pkgbase:/tmp # pkg delete -y tor-browser Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: tor-browser: 13.5.a9_1 Number of packages to be removed: 1 The operation will free 283 MiB. [1/1] Deinstalling tor-browser-13.5.a9_1... [1/1] Deleting files for tor-browser-13.5.a9_1: 100% ==> Running trigger: desktop-file-utils.ucl Building cache database of MIME types root@fourteen-pkgbase:/tmp # pkg add ./tor-browser-13.5.a9_3.pkg Installing tor-browser-13.5.a9_3... Extracting tor-browser-13.5.a9_3: 100% ==> Running trigger: desktop-file-utils.ucl Building cache database of MIME types root@fourteen-pkgbase:/tmp # ---- Reproducible with 13.5.a9_2 and 13.5.a9_3 on CURRENT with nvidia-modeset (nvidia-driver-470) on an HP ZBook 17 G2. % uname -aKU FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT main-n272228-afd096326aad GENERIC-NODEBUG amd64 1500023 1500023 % Created attachment 253569 [details] Screenshot From comment #2: > Reproducible with 13.5.a9_2 and 13.5.a9_3 on CURRENT with > nvidia-modeset (nvidia-driver-470) on an HP ZBook 17 G2. Worked around with inferior 13.5.a9_1 from quarterly for freebsd:14:amd64 in the midst of latest packages on 15.0-CURRENT. ---- root@mowa219-gjp4-zbook-freebsd:~ # pkg delete -y tor-browser Checking integrity... done (0 conflicting) Deinstallation has been requested for the following 1 packages (of 0 packages in the universe): Installed packages to be REMOVED: tor-browser: 13.5.a9_3 Number of packages to be removed: 1 The operation will free 283 MiB. [1/1] Deinstalling tor-browser-13.5.a9_3... [1/1] Deleting files for tor-browser-13.5.a9_3: 100% ==> Running trigger: desktop-file-utils.ucl Building cache database of MIME types root@mowa219-gjp4-zbook-freebsd:~ # env ABI=freebsd:14:amd64 IGNORE_OSVERSION=yes pkg add https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly/All/tor-browser-13.5.a9_1.pkg pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended Fetching tor-browser-13.5.a9_1.pkg: 100% 68 MiB 4.8MB/s 00:15 Installing tor-browser-13.5.a9_1... Extracting tor-browser-13.5.a9_1: 100% ==> Running trigger: desktop-file-utils.ucl Building cache database of MIME types root@mowa219-gjp4-zbook-freebsd:~ # ---- (The bootstrap recommendation is ignored in this context.) Confirm the bug on another independent FreeBSD machine. # uname -KrUm 14.1-RELEASE-p3 amd64 1401000 1401000 # pkg info -A tor-browser tor-browser-13.5.a9_3: FreeBSD_version: 1401000 cpe : cpe:2.3:a:mozilla:tor-browser:13.5.a9:::::freebsd14:x64:3 no_provide_shlib: yes can we confirm a letterboxing issue by setting privacy.resistFingerprinting.letterboxing to false? Also is this nvidia only? (In reply to Jesper Schmitz Mouridsen from comment #5) 13.5.a9_3 on CURRENT with nvidia-driver-470-470.161.03_1: - privacy.resistFingerprinting.letterboxing is true by default - no difference when false. Reverted to true. (In reply to Graham Perrin from comment #6) What if you exclude NVIDIA from the equation? (In reply to Jesper Schmitz Mouridsen from comment #7) I cannot reproduce on nvs 4200m nvidfs 390.154 From comment #2: > Not reproducible with 13.5.a9_1 from quarterly on 14.1-RELEASE-p4 with > SCFB on an old MacBook Pro. (In reply to Jesper Schmitz Mouridsen from comment #7) Not reproducible with 13.5.a9_1 and other latest packages on 14.1-RELEASE-p5 in VirtualBox. HP ZBook with NVIDIA hardware: - I can't easily de-configure my everyday CURRENT (to use SCFB) - I do have 14.1-RELEASE-p5 on a USB HDD, however I can't easily get the computer to boot from the drive (GELI encryption; when I prioritise the drive in BIOS, the system boots, instead, from an internal drive). ---- Ott Köstner, do both of your machines use nvidia-driver-470? > Not reproducible with 13.5.a9_1 and other latest packages on
> 14.1-RELEASE-p5 in VirtualBox.
Correction (sorry):
Not reproducible with 13.5.a9_3 and other latest packages on 14.1-RELEASE-p5 in VirtualBox.
Created attachment 253881 [details] Screenshot of the bug Shot for use with <https://old.reddit.com/r/torbrowser/comments/1frvwqv/freebsd_bug_281500_wwwtorbrowser_letterboxing/> > FreeBSD bug 281500 – www/tor-browser: letterboxing: tiny, unusable letterbox – > privacy.resistFingerprinting.letterboxing false is not a workaround what is the output of xwininfo -root -children, are some browser windows set to small dimensions? I wonder if the windows sizes are reported wrongly to the letterboxing system. (Even though it should not matter when letterboxing is disabled) What if you run the tor-browser as the root window... (Just to rule out a window manager) Created attachment 253894 [details] xwininfo -root -children – HP ZBook 17 G2, nvidia-driver-470-470.161.03_1 (In reply to Jesper Schmitz Mouridsen from comment #12) > what is the output of xwininfo -root -children, … (In reply to Jesper Schmitz Mouridsen from comment #12) > … to rule out a window manager) SDDM stopped, not using Plasma or KWin, startx, tor-browser: the bug is reproducible for both the originally affected user (grahamperrin) and the root user. (Is it twm by default with the full X.Org package? I can't remember. Late night here.) > … run the tor-browser as the root window … If I still need to do that, I'll need a reminder of how. HTH (In reply to Jesper Schmitz Mouridsen from comment #5) No, I can reproduce on Intel i915 $ xwinfo -root -children xwininfo: Window id: 0x617 (the root window) (has no name) Root window id: 0x617 (the root window) (has no name) Parent window id: 0x0 (none) 16 children: 0x400035 (has no name): () 952x1290+0+0 +0+0 0x400029 (has no name): () 121x22+0+0 +0+0 0xa00044 "Firefox": ("tor-browser" "tor-browser") 200x200+0+0 +0+0 0xa00040 "Firefox": ("tor-browser" "tor-browser") 200x200+0+0 +0+0 0xa0003a "Firefox": () 10x10+-100+-100 +-100+-100 0xa0002b (has no name): ("Firefox" "tor-browser") 100x100+0+0 +0+0 0x400056 (has no name): () 1400x1010+647+135 +647+135 0xa00027 "Firefox": ("tor-browser" "tor-browser") 200x200+0+0 +0+0 0xa00022 "Firefox": ("tor-browser" "tor-browser") 200x200+0+0 +0+0 0xc00001 (has no name): () 10x10+-20+-20 +-20+-20 0xa00001 "Firefox": ("tor-browser" "Tor-browser") 10x10+10+10 +10+10 0x40002a (has no name): () 50x75+2201+1 +2201+1 0x400027 (has no name): () 5x5+0+0 +0+0 0x40001b (has no name): () 150x91+0+0 +0+0 0x400012 (has no name): () 122x418+0+0 +0+0 0x400011 (has no name): () 122x418+0+0 +0+0 $ xrandr Screen 0: minimum 320 x 200, current 2256 x 1504, maximum 16384 x 16384 (more in attachment) Created attachment 253929 [details]
xwinfo -root -children
Created attachment 253930 [details]
xrandr - framework with 915i
(In reply to Dan Kotowski from comment #17) Are everyone experiencing this bug, using higher than 1920x1080 screen resolution? I do not have a high res monitor to test with myself. Yes having the same bug. Using Nvidia and 2560x1440 res. (In reply to Jesper Schmitz Mouridsen from comment #18) In this case, neither display is higher: % xrandr Screen 0: minimum 8 x 8, current 3520 x 1080, maximum 16384 x 16384 VGA-0 disconnected (normal left inverted right x axis y axis) DP-0 disconnected (normal left inverted right x axis y axis) DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) DP-3 connected 1600x900+1920+90 (normal left inverted right x axis y axis) 382mm x 215mm 1600x900 60.00*+ 40.00 DP-4 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 597mm x 336mm 1920x1080 60.00*+ 59.94 50.00 1680x1050 59.95 1440x900 59.89 1280x1024 60.02 1280x720 60.00 59.94 50.00 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 59.94 640x480 59.94 59.93 DP-5 disconnected (normal left inverted right x axis y axis) DP-6 disconnected (normal left inverted right x axis y axis) % uname -aKU FreeBSD mowa219-gjp4-zbook-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT main-n272634-eb8326421e6b GENERIC-NODEBUG amd64 1500024 1500024 % <https://forums.freebsd.org/posts/674535>: > I have installed drm-61-kmod-6.1.92 from ports. The GPU is > AMD Radeon RX 550, and RX 570 in another machine. > Both have the same problem. output from not experiencing the bug (started as below with MOZ_LOG=WidgetScreen:5 set in env: env MOZ_LOG="WidgetScreen:5" tor-browser [Parent 1815: Main Thread]: D/WidgetScreen ScreenGetterGtk created [Parent 1815: Main Thread]: D/WidgetScreen ScreenGetterGtk::RefreshScreens() [Parent 1815: Main Thread]: D/WidgetScreen GDK reports 1 screens [Parent 1815: Main Thread]: D/WidgetScreen New monitor 0 size [0,0 -> 1920 x 1080] depth 24 scale 1.000000 CssScale 1.000000 DPI 175.846161 refresh 60 ] What is the output for the ones experiencing the bug? TIA /jsm $ env MOZ_LOG="WidgetScreen:5" tor-browser [Parent 24568: Main Thread]: D/WidgetScreen ScreenGetterGtk created [Parent 24568: Main Thread]: D/WidgetScreen ScreenGetterGtk::RefreshScreens() [Parent 24568: Main Thread]: D/WidgetScreen GDK reports 1 screens [Parent 24568: Main Thread]: D/WidgetScreen New monitor 0 size [0,0 -> 2256 x 1504] depth 24 scale 1.000000 CssScale 1.000000 DPI 201.061050 refresh 60 ] [Parent 24568: Main Thread]: D/WidgetScreen Refresh screens [Parent 24568: Main Thread]: D/WidgetScreen Refreshing all ContentParents [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24578] [Child 24578: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24591] [Child 24591: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24592] [Child 24592: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24593] [Child 24593: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24600] [Child 24600: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 24568: Main Thread]: D/WidgetScreen Send screens to [Pid 24613] [Child 24613: Main Thread]: D/WidgetScreen Refresh screens from IPC (In reply to Jesper Schmitz Mouridsen from comment #22) % env MOZ_LOG="WidgetScreen:5" tor-browser [Parent 2822: Main Thread]: D/WidgetScreen ScreenGetterGtk created [Parent 2822: Main Thread]: D/WidgetScreen ScreenGetterGtk::RefreshScreens() [Parent 2822: Main Thread]: D/WidgetScreen GDK reports 2 screens [Parent 2822: Main Thread]: D/WidgetScreen New monitor 0 size [0,0 -> 1920 x 1080] depth 24 scale 1.000000 CssScale 1.000000 DPI 81.642853 refresh 60 ] [Parent 2822: Main Thread]: D/WidgetScreen New monitor 1 size [1920,90 -> 1600 x 900] depth 24 scale 1.000000 CssScale 1.000000 DPI 106.325577 refresh 60 ] [Parent 2822: Main Thread]: D/WidgetScreen Refresh screens [Parent 2822: Main Thread]: D/WidgetScreen Refreshing all ContentParents Gtk-Message: 07:44:58.125: Failed to load module "appmenu-gtk-module": 'gtk_module_display_init': Undefined symbol "gtk_module_display_init" [Parent 2822: Main Thread]: D/WidgetScreen Send screens to [Pid 2922] [Child 2922: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 2822: Main Thread]: D/WidgetScreen Send screens to [Pid 2972] [Child 2972: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 2822: Main Thread]: D/WidgetScreen Send screens to [Pid 2973] [Parent 2822: Main Thread]: D/WidgetScreen Send screens to [Pid 2975] [Child 2973: Main Thread]: D/WidgetScreen Refresh screens from IPC [Parent 2822: Main Thread]: D/WidgetScreen Send screens to [Pid 2976] [Child 2975: Main Thread]: D/WidgetScreen Refresh screens from IPC [Child 2976: Main Thread]: D/WidgetScreen Refresh screens from IPC % Hi again, The ones hit by the bug seems to report the screen size correctly to the browser, so next approach.. I read some more code, but still cannot reproduce myself.. If you set privacy.resistFingerprinting.jsmloglevel to String Debug in about:config and open the browser console Menu more tools Browser console: And then resize the window.. A snippet of my output without the is RFPHelper.jsm: _roundContentSize[0.531251312096796] RFPHelper.sys.mjs:38:19 RFPHelper.jsm: _roundContentSize[0.531251312096796] contentWidth=1800 contentHeight=900 parentWidth=1920 parentHeight=944 containerWidth=1920 containerHeight=944. RFPHelper.sys.mjs:38:19 RFPHelper.jsm: _roundContentSize[0.531251312096796] roundDimensions(1920, 944) RFPHelper.sys.mjs:38:19 RFPHelper.jsm: _roundContentSize[0.531251312096796] roundDimensions(1920, 944) = 1800 x 900 RFPHelper.sys.mjs:38:19 RFPHelper.jsm: _roundContentSize[0.531251312096796] setting size to {"roundedDefault":{"--letterboxing-width":"var(--rdm-width, 1800px)","--letterboxing-height":"var(--rdm-height, 900px)"},"roundedInline":{"--letterboxing-width":"","--letterboxing-height":""}} (In reply to Graham Perrin from comment #3) Hi, I can reproduce as well now on an nvidia-470 with or without nvidia configured. So it has apparently nothing to do with video drivers. However I can "solve" it by using latest tor-browser build for 14.0 not the one from quarterly that already worked around the issue for you, but the same package version just build in the 14.0 jails... env ABI=freebsd:14:amd64 IGNORE_OSVERSION=yes pkg add https://pkg.freebsd.org/FreeBSD:14:amd64/latest/All/tor-browser-13.5.a9_3.pkg Also the update in #bug 281551 does not show the issue when build for 14. I have not build it on 15... Which would be the next step to investigate if 15-CURRENT's build environment introduces the problem... Can you confirm that this is a workaround on 15-CURRENT? TIA I made a vm running current, build the 14a7 from #bug 281551, after confirming the issue with the current port. The alpha does not have the issue, so I hope we can soon close this one as overcome by events. (In reply to Jesper Schmitz Mouridsen from comment #26) Both now bugged on 15.0-CURRENT: FreeBSD:14:amd64/quarterly/All/tor-browser-13.5.a9_1.pkg FreeBSD:14:amd64/latest/All/tor-browser-13.5.a9_3.pkg Created attachment 254166 [details] firefox-esr presenting the cause for the error in tor browser https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.15.0esr-13.5-1-build3/toolkit/components/resistfingerprinting/RFPHelper.sys.mjs#L469 rule.selectorText thus(because of the parsing errors in the attachment) never matches the literal at https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/tor-browser-115.15.0esr-13.5-1-build3/toolkit/components/resistfingerprinting/RFPHelper.sys.mjs#L464 Hi. On amd64 with AMDGPU FullHD resolution. This bug has been fixed for me. with bug 281551 comment 13 (update to 14.0) Thanks. (In reply to xkernelpanic from comment #30) Sorry, forgot to specify, FreeBSD 14.1-RELEASE-p5 (In reply to xkernelpanic from comment #31) LLVM 18 AMD RX 580 8 GB if that matter. Re: comment #28 Whilst we await 14.0 in the ports tree (no rush, bug 281551): * if anyone requires a copy of a package that's free from this bug, please contact me privately in Reddit or The FreeBSD Forums (not via email, please) – <https://old.reddit.com/r/freebsd/comments/1frw60m/-/>. Not cached in the usual place, I stumbled across a copy in my ~/Downloads folder … root@mowa219-gjp4-zbook-freebsd:~ # uname -Km amd64 1500026 root@mowa219-gjp4-zbook-freebsd:~ # env ABI=freebsd:14:amd64 IGNORE_OSVERSION=yes pkg add --force /usr/home/grahamperrin/Downloads/tor-browser-13.5.a9_1.pkg pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended Installing tor-browser-13.5.a9_1... package tor-browser is already installed, forced install Extracting tor-browser-13.5.a9_1: 100% ==> Running trigger: desktop-file-utils.ucl Building cache database of MIME types root@mowa219-gjp4-zbook-freebsd:~ # exit logout % mv ~/Downloads/tor-browser-13.5.a9_1.pkg ~/Documents/IT/BSD/FreeBSD/ports/www/tor-browser/281500/ % Yes, after upgrading to FreeBSD 14.1p5 i have small rectangle output. I just built/installed 14.0.1 on my 14.2/amd64 system and the resulting tor-browser works normally for me! (In reply to Craig Leres from comment #35) > my 14.2/amd64 system Make that 14.1-RELEASE. I also tested that works ok on 14.2-BETA2. Upgraded to tor-browser-14.0.1 The issue is solved now. |