Open Bug 1015877 Opened 11 years ago Updated 7 months ago

Programmatically setting a selection in an editable component doesn't mark selected text for middle-click paste

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Version:
32 Branch
Platform:
x86_64
Linux
Type:
defect

Tracking

()

People

(Reporter: marijnh, Unassigned)

Details

This is related to 953389 . An editor component like CodeMirror, which models input through a hidden textarea, but lets the user interact with the editor through non-editable DOM nodes, does not currently integrate well with X windows middle-click pasting on Linux. Specifically, when the focused textarea has its content selected, a subsequent middle-click will not paste the content of that textarea. On Chrome it does, leading to less surprised for the user -- when they select something in the editor, they can middle-click paste it. I have no strong opinion on *how* this should be supported, but it would be very helpful (also for Firefox's own dev console) if there was some way to get it to work.
Do you have a test case which helps reproduce this issue by any chance?
This file pretty much reproduces it: <!doctype html> <textarea id=foo>hello</textarea> <button onclick="foo.focus(); foo.select();">select</button> Clicking the button will focus and select the word 'hello', but middle-clicking will not paste hello. Only when you select the text with the mouse or keyboard will it be used as middle-click selection.
Hmm, interesting! Karl, do you happen to remember how we hooked into the X selection clipboard? I would have expected through a selection listener, which should mean that this case would be handled fine, but clearly I'm missing something.
Flags: needinfo?(karlt)
(In reply to :Ehsan Akhgari (lagging on bugmail, needinfo? me!) from comment #3) > Hmm, interesting! Karl, do you happen to remember how we hooked into the X > selection clipboard? I guessed from bug 924069 that there was a "select" event handler, but that event is not currently dispatched due to the problems reported there. The difficult thing here, I assume, is determining whether or not to overwrite the primary selection. Sometimes select() is used just to prepare a field with default text or a previously used field for new text entry, so that any existing text is erased when new text is entered. Default text should not overwrite the primary selection just because it is ready for deletion. The primary should only be overwritten if the user has explicitly selected the data. That need not necessarily be through a mouse-down and drag, but I don't how how to clearly distinguish select() calls. FWIW http://www.w3.org/TR/html5/forms.html#dom-textarea/input-select says "The user agent must then queue a task to fire a simple event that bubbles named select at the element, using the user interaction task source as the task source" but I haven't found any recommendations on the default action for the select even.
Flags: needinfo?(karlt)
ping three years later this is still a problem
ping ping This bug bites me on a daily basis due to how a web tool that my employer requires was written. Its really impossible to use this tool in Firefox due to my inability to easily paste content into assorted 'form' fields. I'm going to end up forced to use Chrome as my browser if this can't be fixed soon. If I have to choose between my employment and using Firefox, my employment is going to win every time.
This significantly affects my extension Drag-Select Link Text and other link selection extensions. Before WebExtensions it was possible to use simulated mouse events which worked the same as user selection but now only web APIs are available so this bug becomes apparent and greatly reduces the usefulness of programmatic selections.
Yes, Drag-Select Link Text doesn't work well on Linux because the selected text isn't put into the primary selection, to make the use limited. I think at least Firefox should support this use case of WebExtensions with clipboard permissions.
Priority: -- → P3
Component: DOM → DOM: Core & HTML
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.