The streamlength/height code when true would return just after we had inserted the timeline-controls, resulting, on topic-progress event to display an empty timeline-controls when clicked.
I think this code in unecessary and we should only rely on the code in `hideProgress` which will currenly hide the progress is the stream has only one post displayed on desktop (always shown on mobile).
We have no way of detecting if a browser window is behind another window
or off screen on a virtual desktop.
In some cases we may want events to be delivered quicker to the browser.
Specifically a user may still have a window in view but is not interacting.
This gives users 20 minutes of extra "long polling time" prior to shifting
to short polling.
Even though `type` is an alias for `method`, we have custom logic in `/discourse/lib/ajax` that checks only `type`, and ~200 other ajax calls in the codebase already use `type` param.
* FIX: Perform crop using user-specified image sizes
It used to resize the images to max width and height first and then
perform the crop operation. This is wrong because it ignored the user
specified image sizes from the Markdown.
* DEV: Use real images in test
Previously we would consider a user "present" and "last seen" if the
browser window was visible.
This has many edge cases, you could be considered present and around for
days just by having a window open and no screensaver on.
Instead we now also check that you either clicked, transitioned around app
or scrolled the page in the last minute in combination with window
visibility
This will lead to more reliable notifications via email and reduce load of
message bus for cases where a user walks away from the terminal
Based on issues identified in https://meta.discourse.org/t/improved-bookmarks-with-reminders/144542/20
* Implement the resolvedTimezone() function on the user model where we return the user's timezone if it has been set, or we guess it using moment and save it to the user using an update call if it has not yet been set. This covers the cases of users who do not log out/in often who will not get their timezone set via login. This also makes sure the guess + save is done in a non-obtrusive way not on every page -- only when it is needed.
* Before if a user's timezone was blank when they visited their profile page we were autofilling the dropdown with the guessed timezone from moment. However this was confusing as it would appear you have that timezone saved in the DB when you really didn't. Now we do not autofill the dropdown and added a button to automatically guess the current timezone to make everything more explicit.
