There is still the apparent problem that after reconnecting, event listeners
hvae to bre reregistered (which doesn't happen currently).
So messages can be sent but not received...
When using OTR with prebind, the user password isn't defined.
=============================================================
When not using prebind, the user password is used to encrypt the private key
for the OTR session before it's saved in session storage.
When using prebind, we ideally want to use the same OTR private key across page
loads, so that we don't have to spend the time generating a new one together
with AKE on every page load. To do this, we need to store it somewhere, like
the browser's session storage.
However, I have yet to find a secure way to store the OTR private key that does
not expose it to maliciously injected javascript.
For now, I've updated the code to generate a new private key and do the AKE
with every page reload.
I'm considering adding code to store the private key in Session Storage and
letting the user explicitly enable this (while making them aware of the risks
involved).
- disable drag resizing when chatboxes are minimized.
- refactored chat box and chat room markup so that they are more similar.
- don't make the chat box title clickable if no vcard URL is available
- make only the title text clickable, not the whitespace
- fixed toggling of resized chats
Include the event emitting code in converse.js itself and start emitting events.
Still needs tests and to be thoroughly tested manually.
Still needs docs.
Did more investigation with regards to subscription requests.
As far as I can tell, roster updates will only show ask='request' for 'pending
out' requests.
For 'pending in' requests (what converse.js calls requesting contacts), roster
updates are not used and instead a presence stanza with type 'subscribe' is
used.
This makes sense. When sending a presence with type 'subscribe', we need a way
to keep track of our outgoing subscriptions. The XMPP server helps us do this by
adding a user to our roster with ask='request' and subscription='none'.
When our contact receives our presence with type 'subscribe', they have the
information they need. If they go offline and online again, the XMPP server
will resend the presence with type 'subscribe'. So a roster item is not needed.
In convere.js's internal representation of the roster (via the RosterItems backbone
object) we need to add roster items for 'pending in' contacts so that we can
render them and we need to know whether they are 'pending in' or 'pending out'.
We already know they're 'pending out' when ask='subscribe' and
subscription='none'. For 'pending in', since these roster items are only stored
locally and not on the XMPP server (because 'pending in' requests are handled
via <presence> stanzas and not the roster) we add a special attribute
'requesting'.
* 'pending' state is denoted by subscription='none', ask='subscribe'
* 'requesting' state is denoted by subscription='from', ask='subscribe'
Reference: http://xmpp.org/rfcs/rfc3921.html#int
I'm not yet 100% sure with regards to the 'requesting' state, I can't find
anything about it in the above mentioned reference, but apparantly that's what
prosody's roster response looks like (e.g. <item jid='XYZ' ask='subscribe'
subscription='from'/> ).
With ejabberd I haven't yet received such a roster response and contact
requests are always handled via presence stanzas.
updates #81
Can be used to get the unwrapper 'inner' converse object.
Instead, check that the bosh service value of the connection corresponds to the
mock object used for jasmine tests.
The value tested for is not usable in production, so we're sure we're only
running tests.
Use id 'conversejs' instead of 'chatpanel'.
The controlbox toggle is now generated via a backbone view, you don't need to
manually include it in your markup.
Make sure the last roster item is still added (even if it's a zombie), so that
the roster will be shown (roster is only shown when last_item property is
true).
When using show_only_online_users, roster item DOM elements are removed from
the DOM if their status changed from 'online' to something else.
When their status changed to 'online' again, they were re-added.
Their views (RosterItemView) instances however didn't listen to events anymore.
Calling delegateEvents on the view after calling $.remove() fixed this.
When using show_only_online_users, roster item DOM elements are removed from
the DOM if their status changed from 'online' to something else.
When their status changed to 'online' again, they were re-added.
Their views (RosterItemView) instances however didn't listen to events anymore.
Calling delegateEvents on the view after calling $.remove() fixed this.
Move all module-level functions/variables and Backbone Modules/Views together.
Add headings to indicate logical sections.
Make statuses variable module-level and indicate that it's a constant (all caps)
