Stop inner letterbox jiggling as border is dragged
TBB 9.0 Linux 64 Cinnamon
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.
Activity
Trac:
Description: TBB 9.0 Linux 64 CinnamonThe 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.
SEO: shakes, vibrates, spazm
to
TBB 9.0 Linux 64 Cinnamon
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.
Keywords: N/A deleted, tbb-9.0-issues, tbb-fingerprinting-resolution added
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 https://bugzilla.mozilla.org/show_bug.cgi?id=1556014 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.
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 re_centering_. 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: https://i.stack.imgur.com/CPJUa.jpg 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.
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: https://www.youtube.com/watch?v=TQxuuFTgz7M - 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
So I looked into this since I'm currently working on #32220 (moved).
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.
