Left arrow key not working when editing post or replys


(Jeff Vienneau) #1

These seems to only occur on my site so I’m hesitant to report it. When I edit a post or reply the left arrow does not allow me to move the caret.

My version is 1.9.7 stable with following plugins:

Name Version Enabled?
discourse-details 0.4 Y Settings
discourse-events 0.1 Y
discourse-locations 0.1 Y
discourse-narrative-bot 0.0.1 Y Settings
discourse-nginx-performance-report 0.1 Y
discourse-presence 1.0 Y Settings
docker_manager 0.1 Y
lazyYT 1.0.1 Y
poll 0.9 Y
strava_onebox 1.0 Y
trailforks_onebox 0.3 Y

As I type this on this instance of discourse left arrow is working.


(Jeff Vienneau) #2

The problem goes away if I reload the site but comes back later.


(Régis Hanol) #3

If you can’t repro on https://try.discourse.org, then it’s either already fixed in test-passed or you have a customization/plugin that is interfering…


(Jeff Vienneau) #4

If I open a new tab it goes away so it may be a funny state it gets in and I am not seeing it here. I’m working to isolate what initiates it.


(Jeff Atwood) #6

Guaranteed to be a rogue plugin. Rebuild with third party plugins disabled.


(Jeff Vienneau) #7

@anon2041049, do we have any plugins in common?


(Jeff Vienneau) #9

Looks like it could be events or locations.


(Angus McLeod) #11

Technically, it’s a bug in core Discourse.

You can reproduce it with no plugins:

  1. Open topic admin controls and click “Change Timestamp”

  2. Click outside the Change Timestamp modal to close it.

  3. Edit a post and press backspace. It will throw an error and default action won’t work.

The same error occurs if you open and close the Add Event modal in the Events Plugin. Both use the date-picker component, which uses the 3rd party Pikaday library.

The reason this component causes an error in these cases and not in other cases (e.g. the Local Dates plugin) is as follows:

  • Like in the Add Event modal, the date-picker in the Change Timestamp modal is passed a value for the property containerId (here).

  • If there a containerId is passed to the the date-component, the Pikaday class is instantiated with bound set to false (here). This is because if bound option in Pikaday is true the calendar will only be shown when its container is focused.

  • If Pikaday is not bound to a particular element it has to be destroyed manually to remove its event bindings.

So a simple fix is to change the destroy method in the date-component to the standard destroy(). Here’s a PR


(Sam Saffron) #12

OK fixed it per: FIX: destroy picker if it was loaded · discourse/discourse@f6c35e5 · GitHub

There are some concurrency issues with your proposed fix cause loadscript can be real slow.


(Jeff Atwood) #13

Excellent :male_detective: sleuthing @angus!

That said it is a bit of a stretch to call that “bug in core Discourse” when the repro is a one in a million UI event (change timestamp, then click outside the modal for… reasons). :wink:

Regardless good to have a fix.


(Régis Hanol) #14

I think @angus just meant that this issue was not related to any of his plugins mentioned on the topic.