The bug happened because the hashtag link won't get parsed by the
extension. This is desired for mentions because you don't want to
re-notify a user if you haven't updated the text in which you notify
somebody. For hashtags this is undesired and would lead to transforming
the hashtag link into a normal link on the next edit of a post.
This adds consistency: The mention links with `@` was implemented
that way already. Instead of parsing the URL, we add some redundancy and
add another attribute: data-hashtag-id
So, what characters are valid for html attributes?
Read: https://stackoverflow.com/questions/925994/what-characters-are-allowed-in-an-html-attribute-name
Thanks to @Tirokk, who added some validations on the hahstag ids, I
think we are all set. If you try to write a hashtag with a `"` double
quotation mark for example, it gets automatically replaced with a valid
hashtag. If someone wants to send us invalid hashtag ids to the backend
directly, the regex there would filter it out.
I believe this is obsolete code. Could someone double-check?
@mattwr18 I tried to see any difference to `master` and I couldn't. Did
I miss sth.?
For context: During my work on https://github.com/Human-Connection/Human-Connection/pull/1517
the webapp was complaining about missing mutations when I changed the
dropdown.
- set items to the full list of hashtags or users to avoid unnecessarily reassigning the items variable based on suggestionType
- refactor tests to trigger onFilter, which calls filterSuggestionList, then check that it returns a maximum of 15 items both for queries and empty queries
- fix description with incorrect type(users, instead of hashtags)
- return 15 items, not 14
Apparently the default pasteRules of tiptap interfere with the
pasteRules of a Link (in our case an Embed node). Consider this example:
https://de.wikipedia.org/wiki/Yin_und_Yang
Depending on some random conditions, tiptap might parse the `_und_` to be
italic because it's wrapped with underscores (markdown syntax). The
result is:
https://de.wikipedia.org/wiki/Yin # link
_und_ # italic
Yang # plain text
So let's remove the default pasteRules of `Bold`, `Strike` and `Italic`
marks respectively to prefer our Embeds. Who is copy+pasting from one
tiptap editor to another tiptap editor anyways?
* Add target="_blank" (on embeds only!)
* When pasting a link, the cursor position is moved after the paste
* Can't reproduce a link slipping into the embed in front of it
@Tirokk it is an unpleasant side efffect that mentions + hastags appear
differently on Edit+View. That's because they don't get parsed from
HTML, it's a one way, they are write only. So, when viewing content,
hashtags and mentions appear as plain links. I don't think I can do
anything about it.
Regarding some links not being embedded: Only those links that have an
oembed provider in this file:
f44d0f1f96/backend/src/schema/resolvers/embeds/providers.json
...will be embedded. Your example `http://backreaction.blogspot.com` and `https://de.wikipedia.org/wiki/Yin_und_Yang`
have no embed provider and won't be embedded.
We would have to add oembed providers to this list if we wanted to embed those
links, too.
Our build server failed because of frontend tests. However, all our
fullstack tests are passing... So maybe an issue in our test setup, not
reproducible in a real browser?
This commit:
ee4f132b0f (diff-0806c5f3fdae5e139222967601c7faca)
adds MutationObserver to their test setup. Adding it to our test suites
that touch the `editor` directly fixes our tests, too!
From what I can tell is that prosemirror is calling
`this.observer.takeRecords()`. Probably `tiptap` updated its
dependencies at some point and that's where `this.observer` was
introduced? Hard to tell. It really looks just like an issue only
present in test environments, so I think it's safe not to investigate
any further.
