#28329: Design TBA+Orbot configuration UI/UX -------------------------------------------------+------------------------- Reporter: sysrqb | Owner: tbb- | team Type: enhancement | Status: closed Priority: Very High | Milestone: Component: Applications/Tor Browser | Version: Severity: Normal | Resolution: fixed Keywords: tbb-mobile, ux-team, TBA-a3, | Actual Points: tbb-8.5-must-alpha, TorBrowserTeam201904 | Parent ID: | Points: Reviewer: | Sponsor: | Sponsor8 -------------------------------------------------+------------------------- Changes (by gk):
* status: needs_review => closed * resolution: => fixed Comment: Replying to [comment:95 sysrqb]: > Replying to [comment:94 gk]: [snip] > > Works for me. In that case please remove > > {{{ > > final double imgDimensionRatioHeightWidth = imgHeight/imgWidth; > > final double imgDimensionRatioWidthHeight = imgWidth/imgHeight; > > }}} > > Those should be deleted in the `fixup!` commit. > > {{{ > - final int expectedHeight = (int) (((double) currentWidth)*imgDimensionRatioHeightWidth); > - final int expectedWidth = (int) (((double) currentHeight)*imgDimensionRatioWidthHeight); > + final int expectedHeight = (int) (currentWidth*imgHeight/imgWidth); > + final int expectedWidth = (int) (currentHeight*imgWidth/imgHeight); > }}} > > In any case, I pushed a new branch with these corrections, and I modified the dense comment above the width/height conditional so it is clearer (I hope). Branch `28329_30`. > > For the onion size, I adding a little more logic for choosing the size. If the image's width is greater than 600dp then set the max width at 600dp and scale the height accordingly. However, if the the current width is already near 600dp (+/- 100dp), then set the width at 400dp and scale the height accordingly. I'm hoping this allows for a better experience on lower-density/lower-resolution screens. Works and looks indeed better on my phone, thanks! > As for the space between the `about:tor` text and the url bar, I don't know what it causing that. I haven't successfully reproduced it. We added some code for preventing this by reloading the page when the chrome (url bar) is rendered after bootstrapping completes. I noticed we reload the page and allow Gecko to use the cache. I wonder if this is the bug, where it is using the cached version instead of re-rendering it, but I don't know why I can't reproduce it. In this new branch I forced bypass-cache with reload, so I'm curious if this solves the problem. It does! > In addition, I now have a spinning onion animation file we may be able to use. I don't know if we'll be can get it into this release. We'll see. Let's do this in a follow-up bug. Anyway, I've closed the child tickets and referenced the respective commits there. Additional bug fixes from `28329_31` made it into commit be91c6f0a5cba14a7ba0e17682b158ada97667be and 7b5f5ee887cd6fd865e86784ad536b4c0136ce83 on `tor-browser-60.6.1esr-8.5-1` I'll file follow-up tickets for the following issues (please double-check that I did not miss any): 1. The spinning onion 1. The custom bridge line solution (we'd like to have a multi-line form here) 1. The "switch-jump-issue" if one enables/disables bridges (see comment:71) 1. The potentially orbot-related null pointer exception (see comment:61) -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28329#comment:97> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs