This is logic from 10 years ago (dbc4798594)
that is no longer relevant. It seems like we used to show the
search bar open all the time and only showed the buttons when
there was focus in the search bar. Now we close the search bar
when it's not being used, and no longer need to update button
visibility or disable the search close button.
Setting empty hash `#` scrolls user to the top of message feed if
done via `window.location.hash` or using browser back / forward button.
To avoid this, we set don't set `hash` after org URL for default view
when user uses `escape` key or clicks on org logo.
In other situations, we explicitly set the hash of the view.
This avoids a bug where during a browser initiated hashchange
(via back/forward/manually typed URL) browser sets the scroll
position of the current hash based on its memory of the scroll
position of the new hash.
Fixes#24641
When the user clicks on a link which has `stopPropagation`
and doesn't trigger `scroll`, then we don't hide any existing
popovers if the element being clicked doesn't hide popovers
explicitly.
To fix this, we hide all popovers on change in hash which makes sense
on its own given how we use hashes.
There was a direct dependency between `admin.js` and `settings.js` which
was due to the fact that we needed to call `build_page` of both modules
in each other's `launch` function.
This is solved by lifting those `build_page` calls up from both modules to
`hashchange.js` which is the module which calls the `launch` function
of both modules.
Until now, whenever the hash was updated using the `set_hash` function,
the new url was always pushed into the browser history, even if the current
hash was same as the new hash. This lead to multiple duplicate entries in
the browser history, when using the `z` hotkey to zoom to a message
repeatedly, which is very inconvenient when navigating through history.
This is now fixed by simply returning prematurely from `set_hash` if the
new hash is same as the current one. This fix will also prevent any future
features like `z` from causing duplicate browser history entries.
Fixes: #24468.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Lalit
evykassirer
Aman Agrawal
Alex Vandiver
N-Shar-ma
Ganesh Pawar
Anders Kaseorg