Hopefully this will make things slightly more discoverable;
the previous solution (putting a prompt in the initial text)
was not that discoverable.
(imported from commit f6a7fce1bfd27bda412522768e981b2ffc39f474)
This fixes https://trac.humbughq.com/ticket/546.
It's a little unpleasant that this special-casing lives in hotkey.js
-- instead you could imagine doing something where there was a whole
special set of hotkeys when a search is active, like we do with the
composebox, but this gets the job and is probably simplest.
I would have written this as a case that just falls through in the
else condition, but jslint doesn't like that.
(imported from commit 65a1b8aa1efc356b6690dc177058a4fb9e12745a)
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)
Make it so the image is not squished, change some paragraphs into
headers, and wordsmith a bit.
(imported from commit 81295e1a8ddd4f1ecd4532c4dfb8a38467bb530e)
in the narrowed view, not messages older than the oldest message in
the home view
Tim provided most of the code for this patch
(imported from commit ec0bbfd344cac351f56a456fc560848603721135)
The tabindex on this link doesn't actually do anything, because of the Safari
tab workaround. I added it anyway in case we remove that workaround later.
(imported from commit 11f31f2561907300b350c11732be88589d736f94)
This fixes a bug where you could click on the already-selected mode button, and
it would switch modes without changing which button is selected.
(imported from commit 263ee0b52ba844c52a3a60968bb1bbff73482412)
With the removal of process_compose_hotkey, the state machine now has only one
state. Everything else is based on things like "is a text box focused right
now", which is probably a better approach.
(imported from commit 0e39c03956d28e30d2bdbf3b285410ad0cacca3e)
load_old_messages cares whether it is acting on behalf of a narrow
(for_narrow) not whether it is acting on behalf of a button push.
(imported from commit 16c00e015478f94f0631e211a92a7066a38135a8)
Zev Benjamin
Waseem Daher
Jeff Arnold
Tim Abbott
Keegan McAllister
Luke Faraone
Jessica McKellar