Until now, we've only been explicitly documenting the `_converse.api`
namespace and only considered the methods under it as forming the API
contract (which determines how we do semver releases).
It appears as if we've reached a point where trying to keep everything
under the `_converse.api` namespace no longer makes sense. Certain
methods are applicable to particular models and trying to shoehorn them
into the `_converse.api` namespace seems clunky and non-intuitive.
I've therefore decided to slightly refactor `sendMessage` to let it take
two simple parameters and to document it with JSDoc so that it's
presented as an API method, albeit only available on a chat model.
updates #1496
updates #1504
Eventually we need to add better support for receipts and markers of MAM
messages.
We'll need to do the following:
* First check whether the MAM page already contains the receipts or markers, to avoid duplication
* Only ever in catchup mode
* Only after full catchup to ensure that the receipt is not in a different page than the message
Currently, in order for Converse.js to recognize a pasted URL as an
image, it must be an URL whose protocol is `https:` (`https` in the
URI.js library's notation). This is sensible, but means that any
non-HTTPS image URL is not recognized as a valid URL (and thus will not
be rendered inline, even if `show_images_inline` is set to `true`).
It is important to always check for HTTPS URLs when in a secure context
(i.e., the initial page load was requested via HTTPS) in order to ensure
that non-secured content does not mix with secured content. However, the
inverse is not true: if the original page was loaded over HTTP, then
enforcing HTTPS for images adds arguably no meaningful protection while
also breaking the `show_images_inline` feature for the edge cases where
Converse.js is deployed without HTTPS and a user pastes an HTTP URL.
This patch changes the behavior of the `isImageURL` method such that the
requirement for the pasted URL's protocol to be `https:` is enforced
only when the `window.location.protocol` itself is also `https:`. By
doing this, we ensure that secure origins (i.e., when Converse.js is
loaded over HTTPS initially) are still secured and cannot have non-HTTPS
content introduced to the page via a pasted non-HTTPS URL, however it
also allows non-HTTPS origins to render both HTTP and HTTPS image URLs.
As per XEP-0004, the default "type" of data form fields is
"text-single", so a missing "type" attribute should not be treated
differently.
This fixes handling of CAPTCHAs offered by ejabberd.
