Text selection usability degradation

[hyzhak]

Bug reports

Version

2.0.2

Steps to reproduce

• To type any text in first input here http://ericgio.github.io/react-bootstrap-typeahead/
• Try to select this text by pressing out inside of typehead component but outside of typed text (inner input) and then dragging across the text.

Expected Behavior

• text in typeahead should be selectable from any part of the component

Actual Behavior

• you won't able to select text this way, only by starting dragging from typed text.

Additional

The previous version (1.3.0) of this component is used here http://web.archive.org/web/*/github. So you could select text by dragging cursor cross the component. but in new version here https://web-beta.archive.org/web/*/github (where is used the last version of the component) it won't able to achieve.

Possible solution: increase side of inner input which was fit to the side of typeahead component in 1.3.0 version, but now just fit a typed text.

[ericgio]

Thanks for the report. This is expected, though I admit it's not ideal. For context, I rewrote the input in v2.0 to render the same way in both the single- and multi-select cases. This was done to simplify the code paths and hopefully reduce bugs in the process. The tradeoff is that it introduces some subtle behaviors like what you're describing. I haven't spent much time trying to solve this particular issue because it feels relatively minor and doesn't prevent any functionality.

Are you reporting the issue mainly just to bring it to my attention or did you feel like it was a significant behavioral problem?

[hyzhak]

Thanks for your response! Yes, it is considered as a major issue.

[ericgio]

This should be mostly fixed as of v2.0.3. For the single-select case, the input is now full-width, allowing users to double-click or drag to select. Please note that because the form-control classname is applied to the containing div and not the input itself, there are still a few pixels of padding around the input. If a user clicks there and tries to drag, it won't quite work the way a true input would.

[alasdairhurst]

@ericgio I still find this is still an issue in 2.2.0.
styling the component with the following CSS allows text to be selectable when a hint is displayed. Since no mouse input is needed for the hint text we can just disable it. The selection text colour/style itself has always been a bit dogy with the hint though.

	.rbt-input-wrapper > div > div {
		pointer-events: none;
	}

[ericgio]

@alasdairhurst: I'm not sure I understand exactly what you're saying here. Can you please clarify?

[alasdairhurst]

The current functionality I see is when then hint text is visible (i.e. when the input has focus + there is a hint available), text highlighting is pretty dodgy and you can't select the full text. This is because the click events are being "stolen" by the hint text. By disabling pointer events on the hint text, the user can now highlight the real text properly.

See the example above: you cannot select $.params.body if there is a hint displayed.

The only two issues I see is that selection is still a little bit difficult on the far left, making it hard when there is only a single character and highlighting the text in a left to right motion, and the styling as seen in the screenshot in my last comment (you would expect white text but it'some odd mix of grey due to a clash with the hint text by the look of things)

[alasdairhurst]

See here:
https://jsfiddle.net/alasdairhurst/mgwLfodx/3/

• start typing $.params.body
• try to select the text
• see that it can be selected
• delete the css that sets pointer-events: none
• try again and see that the text cannot be selected

[ericgio]

I see what you're saying. Yeah, that's weird.

[ericgio]

@alasdairhurst: That issue should be fixed as of v2.3.1