Fixed Tag editor may show tag multiple times

PaulB

PaulB

Well-known member
Affected version
2.2.4
Steps to reproduce:
  1. Create a new thread with a unique tag. That tag must not be used anywhere else.
  2. Click the tag edit link in the thread to edit its tags.
  3. Click the "x" next to the tag to remove it.
  4. Submit the form by clicking "Save", but do not refresh or navigate away from the page.
  5. The tag should now be deleted from the database, since its last xf_tag_content entry has been removed.
  6. Click the tag edit link in the thread to edit its tags again.
  7. Type the name of the tag.
  8. Press Enter.
  9. The tag will appear twice:
1619624497670.webp

Some preliminary debugging indicates this likely happens due to select2's "tags" feature. The first copy of the tag corresponds to the <option> that was created from the dataset. As the tag has been deleted, it's no longer in the dataset, but the <option> (or some other reference to it) still exists in the select2 instance. The second copy of the tag corresponds to a new <option> that's created by select2 as a placeholder for values that aren't in the dataset when the config contains tags: true.
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.2.5).

Change log:
Do not cache the edit tags overlay to workaround an issue with tags duplicating in the tags editor.
Click to expand...
There may be a delay before changes are rolled out to the XenForo Community.
 
Even with that fix, it's still possible to reproduce the bug in more obscure scenarios, such as the following:
  1. In Tab 1, add a new tag to a thread that doesn't exist yet. We'll call it "foobar"
  2. In Tab 1, open the "Edit tags" dialog, but don't do anything yet. You should see "foobar" as one of the tags.
  3. Open a new tab, Tab 2, and navigate to the same thread.
  4. In Tab 2, remove the "foobar" tag from the thread.
  5. In Tab 1, click the "x" to remove the "foobar" tag, but don't save the form yet.
  6. In Tab 1, type "foobar" to add the tag back.
  7. When you press Enter in Tab 1, you'll get two instances of "foobar".
 
That's slightly on the obscure side that I'm not sure we'd particularly be worried about that but we will take another look. If we can do it without turning off caching on the overlay (which might cause changes to be lost unintentionally if accidentally closed) then that would be better.
 
I believe it's mostly just cosmetic anyway. The second repro I posted here is actually the first repro we were able to come up with, so I figured I'd mention it. The simpler repro we initially posted was an evolution of the more contrived repro after further debugging.
 
For anyone encountering this issue with their add-ons:

To disable modal caching, add the data-cache="off" attribute to whichever <a> is triggering the overlay via data-xf-click="overlay". For example, 2.2.5 changed this:
HTML: 
<a href="{$editLink}" data-xf-click="overlay" data-xf-init="tooltip">
...to this:
HTML: 
<a href="{$editLink}" data-xf-click="overlay" data-xf-init="tooltip" data-cache="off">
I've removed some code that isn't necessary for this example, but that's the general idea.
 
Thank you for reporting this issue, it has now been resolved. We are aiming to include any changes that have been made in a future XF release (2.3.3).

Change log:
Re-enable caching for tag edit overlay
Click to expand...
There may be a delay before changes are rolled out to the XenForo Community.
 
I wasn't able to reproduce these in XF 2.3, which does not use Select2, so I have re-enabled overlay caching.
 
Back
Top Bottom