Browsing the web results in a tiny rectangular area just in the middle of the window. Browser is unusable. The port builds and installs without error. Tried to recompile the browser and all its dependencies. The issue persists. Other users in the FreeBSD forums are reporting the same behavior. Port version is: tor-browser-13.5.a9_3 System: 14.1-RELEASE-p3
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.