Tracking a topic using the keyboard shortcut tracks other topics too

When I use the m t, m r shortcuts to track/untrack a topic, this also changes tracking status of other topics I browsed recently in the same window.

This does not seem to happen when using mouse.

Seen using Firefox 68.4.1esr. First noticed on the Rust discourses, now I also checked it here.


Hi, thanks for report!

I think this bug has been here for quite some time, maybe recent changes made this more visible.

Long story short:

  • we are not enforcing topic id when receiving the change event
  • we are not throttling the shortcut, meaning that if you key “m” down it will send the same event indefinitely…

That should fix it:

This should be merged by the end of the week.


How long should it take from the merge of the pull request to the fix being deployed?
At the moment I see no change in behaviour here.

It depends of which forum. The commit is merged in master and backported in stable branch so everyone should be able to get it.


This topic was automatically closed after 3 days. New replies are no longer allowed.

@Falco did this regress?


Hello @david
I can still reproduce the problem on this discourse. I don’t know whether it was unreporoducible in the meantime.


@joffreyjaffeux could you take another look please?

@mpol we haven’t been able to reproduce this. Can you run us through the exact steps you take to repro here on meta?

1 Like

I’m sorry if it turns out to be something wrong at my end, but here we go, on Firefox 68.6.0esr just now.

  1. Using only keyboard navigation, starting from a freshly opened main page in a new tab, I have no tracked topics at the start.
  2. I press ‘j’, ‘Enter’ to enter a topic.
  3. I press ‘j’ enough times to the suggested topics, press ‘Enter’ to enter one of them.
  4. I press ‘j’ ‘m’ ‘t’ - now I am tracking both this topic and the one entered from the main page.

BTW, I just noticed that when in step 3 I pressed ‘m’ ‘t’ immediately, only the correct topic was tracked. But even after that pressing ‘j’ ‘m’ ‘t’ changed the state of the previous topic.

1 Like

So I couldn’t repro this exact bug and neither can @david, but @david had a lot of requests going on in his browser, which I didn’t have, first thought was browser and then multiple browsers opened?

After some search I understood it was coming from browser size (which was narrow for me and large for David) and the topic time line button which kept registering new appEvents handler was shown for David and not for me.

I think this should greatly improve the situation on topic tracking, more details in commit:


Ah, yes, requests. So at the end the procedure above generated two identical POSTs to and then the I guess problematic one, to


Yes that should fix this kind of things. I’m merging it now so you can try on meta soon.


@joffreyjaffeux Thanks. In a couple tries I could no longer reproduce the problem here and indeed I always see only one and correct request to /notifications now - no duplicates and no requests for other topics.