Tor Browser 7.0 Security Settings Window too small on macOS 10.12
When I run Tor Browser 7.0 on macOS 10.12, and open the security settings window, the last line of text is off the page. This is probably because the UI font changed.
Activity
So, you don't get a scrollbar and the text is off the page? Or is the issue that you are already getting a scrollbar on the level with the least amount of text?
Trac:
Status: new to needs_information
Cc: N/A to arthuredelstein
Keywords: N/A deleted, tbb-security-slider, tbb-7.0-issues, tbb-regression addedReplying to gk:
So, you don't get a scrollbar and the text is off the page? Or is the issue that you are already getting a scrollbar on the level with the least amount of text?
What I see:
There is no visual indication that there is any extra text in the window that can be scrolled to.
There is a scrollbar, but on macOS, it is invisible until the user starts scrolling. If a user just happens to start scrolling, then the final line becomes visible, but the first line is hidden.
The scrolling also makes it hard to tell exactly which lines apply to Low, Medium, and High.
What I expect:
All the text is shown on the screen when the user opens the window.
Trac:
Status: needs_information to newReplying to teor:
Replying to gk:
So, you don't get a scrollbar and the text is off the page? Or is the issue that you are already getting a scrollbar on the level with the least amount of text?
This only happens when I am in High Security Mode. The scrollbar appears for a few seconds when I first switch to High Security Mode, then disappears. (I didn't see the scrollbar to start with, because I was in High Security Mode before I upgraded.)
What I see:
There is no visual indication that there is any extra text in the window that can be scrolled to.
There is a scrollbar, but on macOS, it is invisible until the user starts scrolling. If a user just happens to start scrolling, then the final line becomes visible, but the first line is hidden.
The scrolling also makes it hard to tell exactly which lines apply to Low, Medium, and High.
What I expect:
All the text is shown on the screen when the user opens the window.
Here is a simple fix (increase a hard-coded height): https://gitweb.torproject.org/user/brade/torbutton.git/commit/?h=bug22542-01 I assume this won't look too bad on the other platforms.
Trac:
Keywords: N/A deleted, TorBrowserTeam201706R added
Status: new to needs_reviewThis works for me using macOS 10.12.5 outside a VM (retina), but doesn't work inside a VM (non-retina).
I am running macOS 10.12.5 with Tor Browser 7.0.1 and Tor Button 1.9.7.4 in both environments.
I think it's better than it used to be, but there are still 2 lines of text missing at the bottom on non-retina. (And on retina, there are a few pixels still hidden at the bottom, which makes it possible to trigger the scroll bar.)
Trac:
Resolution: fixed to N/A
Status: closed to reopened-
What we really want to do is adjust the height of the window so that no scrollbar is necessary. Here is a patch: https://oniongit.eu/brade/torbutton/merge_requests/1
We tested this on a couple of OSX systems, on a Linux system, and on Windows 10. Here is a pre-built xpi for testing: https://people.torproject.org/~brade/builds/bug22542/torbutton@torproject.org.xpi teor: if you have time please test this on your OSX systems.
As an aside, Kathy and I don't know what the best approach is for using oniongit; maybe we should create a torbutton project under the tor-browser group and submit merge requests against it?
Trac:
Status: reopened to needs_review
Keywords: TorBrowserTeam201707 deleted, TorBrowserTeam201707R added Replying to mcs:
... We tested this on a couple of OSX systems, on a Linux system, and on Windows 10. Here is a pre-built xpi for testing: https://people.torproject.org/~brade/builds/bug22542/torbutton@torproject.org.xpi teor: if you have time please test this on your OSX systems.
I'm sorry, I am not sure I will have time to do this, I have some tight deadlines at the moment.
-
Replying to mcs:
What we really want to do is adjust the height of the window so that no scrollbar is necessary. Here is a patch: https://oniongit.eu/brade/torbutton/merge_requests/1
Okay, I commented.
We tested this on a couple of OSX systems, on a Linux system, and on Windows 10. Here is a pre-built xpi for testing: https://people.torproject.org/~brade/builds/bug22542/torbutton@torproject.org.xpi teor: if you have time please test this on your OSX systems.
As an aside, Kathy and I don't know what the best approach is for using oniongit; maybe we should create a torbutton project under the tor-browser group and submit merge requests against it?
Dunno. I think for now just having a user repo there with an up-to-date master branch for merge requests and using the code review features Gitlab provides is the way to go. At least that's what I am currently doing. If there is something else/better I should set up and test I am all ears.
Replying to gk:
Okay, I commented. Replying to brade: I replied to the comment in oniongit. Of course, it's good to know that you commented. But don't you think that openness and clearness of the project suffer? Especially, because oniongit without JS does nothing, except loading CPU. What was the reason to move the discussion to oniongit?
Trac:
Status: merge_ready to needs_review-
Replying to cypherpunks:
Replying to gk:
Okay, I commented. Replying to brade: I replied to the comment in oniongit. Of course, it's good to know that you commented. But don't you think that openness and clearness of the project suffer? Especially, because oniongit without JS does nothing, except loading CPU. What was the reason to move the discussion to oniongit?
The reason is our testing of oniongit as a trac replacement (at least regarding code review). Thanks for raising the JS issue. teor went already ahead and pointed it out to a wider audience (https://lists.torproject.org/pipermail/tor-project/2017-July/001328.html). We'll see where the discussion goes.
