[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #14429 [Tor Browser]: Automated rounding of content window dimensions
#14429: Automated rounding of content window dimensions
-------------------------+-------------------------------------------------
Reporter: | Owner: tbb-team
arthuredelstein | Status: needs_review
Type: defect | Milestone:
Priority: normal | Version:
Component: Tor | Keywords: tbb-fingerprinting-resolution, tbb-
Browser | torbutton, TorBrowserTeam201502R
Resolution: | Parent ID:
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Comment (by arthuredelstein):
Replying to [comment:16 mikeperry]:
> What made you pick 1000ms? If we set this to 100ms or even 10ms, will
there be issues on some systems? I will play with some timeouts on my
systems and see if I notice anything, but I was curious if you had a
reason for picking such a large delay.
That's a good point. While the user is resizing the window (by dragging an
edge or corner), the chrome window object fires many "resize" events. I
couldn't find any nice way to detect if the user has stopped dragging the
window (mousedown/up events don't fire), so I decided just to wait until
it we feel it is safe to assume that the user has finished dragging before
calling `shrinkwrap()`. I'm not sure what this time is, but 250 ms seemed
too short, at least with myself as the test subject. I think 500 ms seems
OK. (If the user does pause in a drag, then the shrinkwrap occurs anyway,
even though the mouse is still in "dragging" mode.) Let me know what you
think.
I just measured the typical time interval between "resize" events and the
interval is almost always 50 ms or less, except if I leave the mouse down
and stop moving for a while. (This may be unusually easy for me because I
am testing with a touchpad where a double-tap leaves the mouse down.)
> I think there may also be a race/timer resolution issue with the ping()
function. In one instance, my window was not resized. I'm not sure, but I
suspect this may be because the '''if (now - lastPingTime >= timeout)'''
check failed due to the timer actually firing slightly early.
Weird. Seems like the timer firing early should be considered a bug. In
any case, I've written a new version of that patch with a simpler and
hopefully more robust pinger function and I've reduced the timeout to 500
ms.
https://github.com/arthuredelstein/torbutton/commit/bad6f6c7076d41440ebca4421cc88717dbc7f628
> Also as a general matter, I'm not sure we actually need the grey border
and the content window quantization for drag-based resizing, but only for
maximization or other window manager enforced sizing. In other words, it
seems fine to reveal the intermediate sizes to the content window if the
user is simply dragging, but it is not fine to reveal the intermediate
size if the window manager was maximizing or tiling the window. I guess it
may not be possible to tell the difference in practice, though?
Yes, I couldn't find a way to tell immediately that the user has clicked
the maximize button. In my observations, the "sizemodechange" event only
occurs after maximization has completed, and it is preceded by a number of
"resize" events. For window tiling, I'm not sure we would get any special
events.
> My statements about trying to not display the grey border during drag
hinge on how bad we think it is to keep reflowing as if we would allow the
resize, only to snap back to a size the user wasn't expecting. Maybe I'm
wrong, and it is actually better to give the user a hint with the grey
background..
I do like having some sort of hint what the final window size is going to
look like. But I may be the only one...
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/14429#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs