In the post list, when we navigate to the page with ">" button, we
navigate to older posts.
In the post view, when we navigate to the page with ">" button, we
navigate to older posts as well.
However, in the post list, the ">" button is called "next page".
At the same time, in the post view, the ">" button was called "previous
post". Now it's called "next post".
The difference isn't visible to normal users nor even API consumers as
the "get posts around post X" request isn't documented.
The change is motivated not only by consistency, but to also improve
compatibility with Vimperator's `[[` and `]]`. Vimperator assumes the
word "next" refers to ">" and the word "previous" refers to "<".
UglifyJS seems to have troubles using it, I didn't want to investigate
it too much as it's just a syntactic sugar used in about 4 places so I
just removed it altogether
If text area was bigger than the post, switching to preview mode
showed gray space under the text. Now the preview pane's background
should fill the whole edit box size.
API responses are cached internally - if they're modified, they're
modified in cache too. This can lead to certain anomalies, that can be
easily solved by making object copies.
Visiting mass-tag URL directly ignored masstag privileges and showed
tag/untag controls (although didn't show the controls in the header).
After this change, bypassing mass tag privileges got a little bit
harder. (It's still possible for the user to talk directly to the API
after all.)
In other words, verify the privileges client-side before issuing an
request to the server. This commit focuses on routing (e.g. clicking a
link while not logged in), rather than DOM element visibility that
should be already taken care of.
In e464e69 I removed href='#' but I noticed that it broke some things.
Readding href serves two purposes:
- it makes links reachable with Tab key
- it makes links clickable with Enter key
The alternative to this approach was to introduce [tabindex] and [role]
attributes. But not only using tabindex=0 with <a/> is questionable,
it'd require adding a keyboard handler that'd intercept space and return
key presses and simulated link clicks. Since it's best to leave this
kind of thing to the native UI, I went with readding hrefs instead. I
believe that hash hrefs, even though being a common practice, are silly,
so I decided to settle down with empty hrefs.
As a bonus, I added a snippet that prevents middle mouse clicks from
opening such links/buttons in new tabs, which was the motivation for
e464e69.
Every time the password reset form was loaded, the form submit event
listener was attached to a non-disposable DOM node rather than the DOM
node whose life scope was bound to the viewed page. As such, submitting
the form, leaving the page, returning back to it and sending the request
again caused the 'submit' event to fire twice - one time from the
non-disposed event handler and one from the current handler. This
resulted in the request being sent twice, and getting two confirmation
messages on the screen.
Fortunately, since the password reset requests are GET requests, they're
intercepted by the internal cache of the client API facade, so the
client just saw duplicate messages without the requests being actually
sent to the backend - meaning no extra mails were sent.
The lists in the post model (current state and original state) referred
to the same objects, so that making changes to current state was seen as
if no change has been made. This broke mass tag - it always thought
there were no changes to post tags.
The problem was with dangling references - the saved post has been
replacing the note collection with entirely new class instances, whereas
the notes control clung onto old references. Now the control detects
such reloads and acts accordingly.
rr-