[linux] Middle-clicking file to close it adds $ at cursor position

[0b10011]

Steps to reproduce

1. Open two files
2. Middle-click on first file under "Working Files" to close it

Expected results

First file should close.

Actual results

First file closes and $ is added to beginning of second file.

Notes

• System: Ubuntu 13.10, 32-bit
• When text is selected already, the selection is collapsed to the end

[0b10011]

Also, if the first file has unsaved changes, the file will close as expected and $ is not added to the second file.

[RaymondLim]

I can reproduce it in a vanilla CodeMirror demo page in the Chrome browser. So I just filed an issue codemirror/codemirror5#2384.

[marcelgerber]

Interesting - I can't repro it, neither in Brackets nor in the CM demo.
Windows 8.1

[RaymondLim]

This is Linux only issue.

[0b10011]

@RaymondLim CodeMirror shouldn't even receive this event, if I'm not mistaken? Since it's part of the Brackets UI that is being clicked.

As a side note, I couldn't reproduce in the markdown demo.

[RaymondLim]

@bfrohs You need to click into the CM input text field, not in other UI.

[0b10011]

@RaymondLim yes, I'm aware. I couldn't get $ to appear in the CodeMirror demo by middle-clicking in, about, or around the CodeMirror instance. And this issue doesn't require middle-clicking in the CodeMirror instance to get the $ to appear. So maybe this is two issues:

• Middle-clicking in CodeMirror instance inserts $ instead of selected text
• Middle-clicking filename to close it triggers middle click event on CodeMirror instance

[RaymondLim]

Interesting! Marijn cannot reproduce the $ insertion as you. So there must be something different in the Chrome browsers. Regarding the two issues they are essentially the same one. When you middle-click on the filename, you're actually interacting with a DOM node and the mouse event should not be propagated to other nodes. But in this case it is propagated to the DOM node of the editor instance for the other document that becomes active after closing the first file.

[peterflynn]

@RaymondLim I'm a little confused by that statement about the event propagation. The working set list is not in the same DOM subtree as the CM instance, so there's no reason why a mouse event should bubble from one to the other.

[RaymondLim]

@peterflynn I'm just guessing what might happen since both side bar and editor have the common DOM node of "main-view". It seems to me that the event is not cleared by the tree node which closes the second file and then the editor gets the event.

[peterflynn]

There aren't many cases where CM listens to things above its own DOM hierarchy, where the event would bubble up to. And of course the event isn't going to traverse back down another branch to get to CM's own DOM nodes...

@bfrohs It's possible to use dev tools to see who's getting the mouse events when you middle-click. Can you try this?

1. First check to see whether the "$" is inserted on mouse down, or mouse up (exaggerate how slow your click is so it's clear when it happens)
2. Debug > Show Developer Tools
3. Use the magnifying-glass icon to select the item in the working set.
4. Select its <li> and inner <a> tag in turn, and for each one do this...
5. Scroll to the bottom of the CSS inspector panel at right
6. Expand the Event Listeners section, and expand the appropriate mouse event (mousedown or mouseup)
7. Which listeners are shown in the list?

Also, just to make sure: does this also happen if you reload with Debug > Reload Without Extensions?

[0b10011]

$ is inserted on mouse up.

Interestingly enough, there aren't any listeners for mouseup. I've gone all the way up the tree and nothing has one. I'll do some more investigating later and let you know anything I come up with.

And yes, it still happens after reloading without extensions (first thing I tried).

[0b10011]

The $ is inserted when middle-clicking anywhere in the editor (working files, all files, right sidebar, main menu, footer), not just the working files area.

[peterflynn]

@bfrohs What about a click listener then? Click fires immediately after mouseup.

[0b10011]

@peterflynn There are several click listeners, most of which run through the minified jQuery code. I'm going to try to set up a development version of Brackets tomorrow to look into it more (and test out a patch for another bug I reported). Will let you know what I find!

[RaymondLim]

@bfrohs In case you're not aware of, Marijn already fixed it in codemirror/codemirror5@475b2be and we will get the fix with next CM update in Brackets. Regarding middle click it is a feature in Linux to do the pasting.

[0b10011]

@RaymondLim Middle-clicking a filename in the sidebar shouldn't be able to focus the CodeMirror instance in order to paste though.

[RaymondLim]

@bfrohs It depends on how middle-clicking is supported in Brackets. In the working set the focus is set to the next document as part of closing the current one you middle-click on. And for the project tree I'm not aware of any middle-click support, but it can be part of jstree implementation that triggers a node selection on any mouse click.

[0b10011]

@RaymondLim @peterflynn It looks like this is an issue in Chrome where middle-click paste works inside of a timeout (unlike in Firefox). Take this fiddle for a spin:

1. Select "Select this."
2. Middle-click "Middle-click here."

Expected: Textarea should be selected and contents should be the same.

Actual: Textarea is selected and contents are changed.

This could be worked around by moving actions (esp. the "middle-click file close" action) to mouseup or click instead of mousedown, which is the event used now to close files with middle-click.

mouseup doesn't seem to exhibit the behavior as seen here: http://jsfiddle.net/bfrohs/RLXq5/4/

[njx]

@RaymondLim It looks like this might have been fixed in CM: codemirror/codemirror5@357e941

[RaymondLim]

Confirmed that recent update to CM fixes the issue of pasting $ sign. Closing.

[peterflynn]

Re-opening as 'tracking' since we're still not shipping a build that contains this fix -- the fix in CM landed 6/23 and the CM we're shipping in both 0.41 and 0.42 is only updated up to 5/28 or so. (We had to revert our CM update in 0.42 at the last minute due to a rendering bug -- see #8554).

[ingorichter]

Fixed and closed.

[joepie91]

I'm still experiencing the problem where middle-clicking a file in the 'Working files' list will insert the last selection (from any application) into the next open file. As far as I am aware, this is caused by the same issue as the phantom $. Using openSUSE 12.3, running sprint 43 from the home:robert_munteanu OBS repository.

Did this fix not make it into 43?

[0b10011]

@joepie91 I'm coming across the issue still as well. Tried to point out that there were two issues at play in the comments, and then mentioned the CodeMirror fix wouldn't fix this.

This comment should help to fix.

[peterflynn]

@joepie91 If you're running from git, make sure you're doing git submodule update. Otherwise you won't have the fix (or any other CM updates). Make sure this change is in your local source: codemirror/codemirror5@357e941.

[RaymondLim]

@bfrohs and @joepie91 Yes, I can reproduce it with a selection in the clipboard, but no longer with the $ symbol. But I'm not sure that we would like to take action on mouseup or click as @bfrohs suggested.

@dangoor How do you handle middle click events in the sidebar in your pull request #9015? I'm not 100% sure that we handled it onmousedown, but @bfrohs said our old jstree is handling onmousedown. Is it possible for you to use click events instead of mousedown?

[joepie91]

@peterflynn I am currently not running from git, but from the package in the aforementioned repository, which appears to be based on the Debian packages.

@RaymondLim I can't reproduce it with $ either, just with the clipboard, although I have to say that it was never quite clear to me why it was doing either one or the other.

[dangoor]

@RaymondLim I have not touched the working set.