CSS height percentage was not working because parent div has an undefined
height, so instead it is set to 40% of the window height on resize (and initial
load) via JavaScript.
Fixes trac ticket #24.
(imported from commit 2c6a8489585c4bf70c44469ce8628264ec3fbc36)
This was a really cute bug where our layout messes up if you resize
the page while "Subscriptions" (or to a less visible extent,
"Settings") is active.
The problem here is that we compute the size of the top navbar
based on the size of main_div -- but when main_div is hidden,
it has a width of zero!
We need to instead look at the width of the pane that *is* active.
Resolves https://trac.humbughq.com/ticket/216
(imported from commit adbef00d190845f90c5cfdb46df4ec7b703635ef)
feedback-bot and zephyr_mirror will need to be updated and restarted
when this is deployed to prod.
(imported from commit fe2b524424c174bcb1b717a851a5d3815fda3f69)
Ironically, I think this might've bee introduced by
commit ca35321c02d5e79e4f9c439a662805c016a333ed,
'Fix "resizing window breaks in Firefox" issue'.
Basically, when the window is 776px wide according to
window.innerWidth, that's the width not including the
scrollbar. However, in Chrome, the media query seems to ignore the
width of the scrollbar, so from the CSS's perspective, the window is
actually ~766px wide, so it goes into condensed mode.
But the rest of our code doesn't, which causes the break.
A bit more on this browser-specific difference at:
http://www.456bereastreet.com/archive/201101/media_queries_viewport_width_scrollbars_and_webkit_browsers/
So the issue we have is, to match the CSS's behavior:
* In Firefox, we should be listening to window.innerWidth
* In Chrome, we should be listening to window.width
We fix this hopefully once and for all by using window.matchMedia --
aka the exact same query that the CSS itself uses. As discussed in my
last commit, this feature is unavailable in IE<10, so we provide a
potentially more fragile fallback, i.e. what we did before this
commit.
(imported from commit d8e6425b81c90c8e0fdda28e7273988c9bfd67ec)
This restores the time-travel functionality and fixes Waseem's laundry
list of problems with its original UI.
(imported from commit e30e02c25af994435adb815d26284b3669c945a4)
If Javascript breaks or stops working, the previous hack means that
Tab-Enter stops working on Firefox and Chrome (since the tab key now
needs to select two divs before it gets to the Send button.)
By putting the one div *after* the Send button, we ensure that this
keeps working gracefully on Firefox and Chrome (and presumably IE), at
the expense of Safari in this specific case.
(imported from commit 9c9a613b1b1718ff8f0b9ef7497ebb13db0ddc64)
When we switched to delegated event handling, the bound handler for
all of our events was #main_div, but the floating recipient bar lives
outside of #main_div. Additionally, the bar needs to inherit the zid
from the target recipient bar since it is used for the narrow.
(imported from commit 7c18e16f2e98436888a8edb81fbbdd4d17abfe2a)
Personals are now just private messages between two people (which
sometimes manifests as a private message with one recipient). The
new message type on the send path is 'private'. Note that the receive
path still has 'personal' and 'huddle' message types.
(imported from commit 97a438ef5c0b3db4eb3e6db674ea38a081265dd3)
We had this problem where clicking a hyperlink bubbles up and causes a
click on the message, which causes the composebox to open.
We "fixed" this by setting cancelBubble (or, even better, calling
stopPropagation()).
Unfortunately, on Firefox, this fix breaks Ctrl-click and Shift-click,
because those are (apparently) implemented by adding an event listener
on link clicks, and stopPropagation prevents them from being called.
We instead work around this by handling this case in the click handler
of the parent element. (This allows the normal URL click AND Firefox's
bound event handlers for Ctrl and Shift to run.)
This resolves Trac #374.
(imported from commit 16fb3aa6fc582f1fba5009812e0b1178ce7c5bb7)
So, in Firefox, $(window).width() does not include the width of the
scrollbar. However, the CSS media-query max-width DOES include the
width of the scrollbar -- so the Bootstrap change and our change do
not happen at the same time.
window.innerWidth does take into account the width of the scrollbar,
though, and seems to have reasonable cross-browser support, so we use
that instead.
(If we wanted to be slicker, we could use a media query a la
https://developer.mozilla.org/en-US/docs/DOM/window.matchMedia ,
but that's not supported in IE <10.)
This resolves Trac #35.
(imported from commit ca35321c02d5e79e4f9c439a662805c016a333ed)
This clarifies that clicking on any of those three pieces of
information will pop up the user info tooltip.
(imported from commit 1e57550d66acbb2e8d5d244d2997bbd394c334c3)
This reverts commit 429e055d3eca65af8bc0fe58481a7becf9ced66a.
There is some inconsistency between the names 'huddle' and 'personal' that is
breaking things.
(imported from commit 4c81853fca9d88d13ce8f23e2d6884c33cdc57d2)
This also cleans up the autocomplete source specifications,
making the three typeaheads all look fairly consistent.
(imported from commit e72655d715db74cfc9ab45b51e7e2ff9e8ea84c5)
This makes the diff a bit cleaner.
Revert "Interim measure: Escape fullnames as well."
This reverts commit a634e6ac39ea337be499889b3ff64b3c4f4fcccb.
Revert "Interim measure: Escape subject names before they go into the typeahead."
This reverts commit 806bc719ab296ec0fe299b33c7aa6767a0c71b9d.
(imported from commit 5a579e3535846b2bc612cf03e43c562c83119812)
I'm sure this problem exists in a latent way with stream names and
email addresses as well. Once I figure out a general way to fix this,
I'd like to go back and handle these three cases in a cleaner,
symmetric way, but this'll do for now.
(imported from commit a634e6ac39ea337be499889b3ff64b3c4f4fcccb)
It's possible that the three places we can kill a popover
(body click, Esc, clicking on a new one) should be
refactored to use the same code.
(imported from commit ba7eab480fd2258abfb469c8f1155f29bc63f7f6)
Per the docs, these are only meant to be used on arrays of DOM elements.
jQuery might one day assign a different meaning to arrays of strings,
and then we could have some security issues or weird breakage.
(imported from commit 545eee1e9c6955556d5c4bda30cd6db0dce19c60)
Zev Benjamin
Tyler Hallada
Jeff Arnold
Waseem Daher
Keegan McAllister
Jessica McKellar
Tim Abbott