Opened 7 months ago

Last modified 4 months ago

#32308 assigned defect

Stop inner letterbox jiggling as border is dragged

Reported by: cypherpunks Owned by: pospeselr
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-9.0-issues, tbb-fingerprinting-resolution, TorBrowserTeam202006
Cc: tbb-team Actual Points:
Parent ID: Points: 5
Reviewer: Sponsor:

Description (last modified by gk)

TBB 9.0
Linux 64

The inner content area of the letterbox jiggles violently as the Tor Browser window border is dragged to resize. The effect is worse on horizontal (width) than vertical (height). Ideally, the content area would crisply snap as the border shrinks or grows.

Child Tickets

Change History (13)

comment:1 Changed 7 months ago by gk

Description: modified (diff)
Keywords: tbb-9.0-issues tbb-fingerprinting-resolution added

comment:2 Changed 7 months ago by tom

This may be at odds with what letterboxing is aiming for. It sounds like OP is looking for the (gray) border size to stay constant while the window is resized and when the resizing stops, the content window snaps and gets resized to the correct size.

The opposite is actually the ideal solution: as you resize, the gray border will smoothly increase and decrease and the content window will move as it is recentered in the window. This would cause very noticeable jumps in content window size as the browser passes a threshold for the letterboxing.

This is the ideal because we only want to report a letterboxed dimension to web content, never an in-between value.

This is very similar to although 1556014 is a little different because the problem is that as you resize, the website can read some intermediate values. (As I explain there though, I'm not concerned about that.)

Now because I'm not really concerned about those intermediate values, letting the content grow (without growing the grey border) as I explain in the first paragraph is not the worst thing (even though it does go against the goal of letterboxing.)

I suppose, in a perfect world, we could figure out something where we improve this situation in a way that looks smooth but doesn't reveal intermediate values.

Today; however, I do not know how to accomplish any of these goals. We are not handling 'beginresize' and 'endresize' events, we are recalculating things based on a single 'resize' event that occurs and I don't know how to infer a resize that's begin and not completed.

comment:3 Changed 7 months ago by cypherpunks

It sounds like OP is looking for the (gray) border size to stay constant while the window is resized and when the resizing stops, the content window snaps and gets resized to the correct size.

No, I don't care what size is of the letterboxes, aka border, aka outer empty area that some people (not me) hate. Yes, the border should shrink and grow smoothly as you drag the window's edge as tom said. In the act of dragging, the inner content area, aka where webpages are rendered, should remain a constant width x height until border space reaches a new 200x100 threshold at which point the content area should snap to that threshold's new size. I observe the content area's size make a big jump when a threshold is obviously reached, but the area shakes throughout the movement.

As it is now, as I slowly drag the window's edge, the inner content area shakes. If I drag slowly, the content area's width is being minutely resized at 1px thresholds with each movement of my mouse and corrected back to 200x100. I can prove this by opening a Tor Blog post that has many comments that wrap lines all the way from side to side of the content area. As I drag the window width less than the thresholds, the word wrapping unexpectedly changes corresponding to the jiggling of the content area. I'm fearing that what look like below-threshold adjustments are noticeable by the webpage.

But then you mentioned recentering. That's a different issue but may contribute to the jiggling as it recenters the content area at every tiny movement of dragging. The way it all behaves now, it looks scary like the content area isn't snapping to the thresholds properly, and word wrapping observations are supporting evidence.

Comparing to other interfaces, I was expecting the content area to remain somewhat stationary like in a multiple-document interface if the content area was the only child window: Or stationary like generic UI widgets placed relative to the top left corner on a dialog box (or any hard coordinates on a dialog box). As the top or left window border is dragged, the widgets move smoothly on screen relative to the top left corner. As the bottom or right border is dragged, the widgets don't move. In other words, they never jiggle or shake as if something is wrong.

comment:4 Changed 7 months ago by Thorin

Some observations:

  • Just how much time is spent by people manually resizing the browser vs actually using it. 0.001% of the time?
  • If it wasn't centered at all, and you allowed for language direction (RTL vs LTR etc), then it probably wouldn't "jiggle" at all. But that's not very aesthetic.
  • Arthur's demo: - does a "snappening" - i.e there is no need to resize until the space is available/unavailable (I don't think that should be hard to implement or slow the response much, but I don't get paid the big bucks)
  • However, a "snappening" that is centered would probably still jiggle AFAICT. It's the centering that causes it IMO (and that would be CSS, right? use a userChrome.css to force it not centered, and test it)

#TheSnappening .. lol

comment:5 Changed 7 months ago by pospeselr

So I looked into this since I'm currently working on #32220.

Adding an onresize event to the window object seems to indicate that intermediate rescaling (and therefore jiggle) does occur. IE stretching a window whos browser element is set to width 1000, will see something like width 1013 after stretch before the letterboxing logic kicks in resets it back to 1000 (or 1100 if the stretch is large enough).

So there is some aspect of jiggle there in terms of the browse element growing and shrinking (or vice versa) due to users rescaling. Of course there will be the appearance of movement since rescaling implies recentering, but in that case it should be movement in one direction, not jiggle/jitter. It seems to me that whatever CSS rule is applied to the browser element is not setting it to a fixed size, but some sort of scaling that the letterboxing code then snaps back, but I would need to investigate further to be sure on how the implementation actually works.

comment:6 Changed 7 months ago by sysrqb

Keywords: TorBrowserTeam201912 added

Maybe next month.

comment:7 Changed 6 months ago by pili

Owner: changed from tbb-team to pospeselr
Status: newassigned

assigning tickets to pospeselr

comment:8 Changed 6 months ago by brade

Cc: tbb-team added

comment:9 Changed 6 months ago by pospeselr

Points: 5

comment:10 Changed 5 months ago by sysrqb

Keywords: TorBrowserTeam202001 added; TorBrowserTeam201912 removed

comment:11 Changed 4 months ago by pili

Keywords: TorBrowserTeam202002 added; TorBrowserTeam202001 removed

Moving tickets to February

comment:12 Changed 4 months ago by sysrqb

Deferring some more tickets from February 2020 to June 2020. Too many tickets, not enough time.

comment:13 Changed 4 months ago by sysrqb

Keywords: TorBrowserTeam202006 added; TorBrowserTeam202002 removed

Second attempt at deferring tickets until June.

Note: See TracTickets for help on using tickets.