Eitan Isaacson [:eeejay] Reporter
	Description • 10 years ago

In iOS, double tapping on an entry will move the caret to the start or end of the field. This is important since we don't have caret control yet, and the user could be stuck if the caret is at the start of a populated field with no way to erase the current value.

Also, we should announce where the caret is when we switch caret positions, and when we first focus on the field.

	Max Li [:maxli]
	Comment 1 • 10 years ago

I've implemented the first part (of allowing the double tap to move the cursor). I've disabled it on Android because it seems like there's some behavior where TalkBack is already moving the cursor when you double tap, though it doesn't seem too consistent and I couldn't figure out where it was stemming from.

It seems to me that the other parts can be addressed in follow up bugs.

	Eitan Isaacson [:eeejay] Reporter
	Comment 2 • 10 years ago

Comment on attachment 8523651 [details] [diff] [review]
patch

Review of attachment 8523651 [details] [diff] [review]:
-----------------------------------------------------------------

This is a good start, but it doesn't actually work yet on a device. Did it work for you?

This has to do with how we have an exclusive position for both the keyboard and the target app, and how we blur when the cursor in the app changes. I think we need to have some fundamental behavior changes to that interaction before this will actually work. Comparing it to how iOS does it would be useful.

Also, I think we will need to have some verbosity around caret position for it to be usable.

	Max Li [:maxli]
	Comment 3 • 10 years ago

(In reply to Eitan Isaacson [:eeejay] from comment #2)
> Comment on attachment 8523651 [details] [diff] [review]
> patch
> 
> Review of attachment 8523651 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This is a good start, but it doesn't actually work yet on a device. Did it
> work for you?
> 
> This has to do with how we have an exclusive position for both the keyboard
> and the target app, and how we blur when the cursor in the app changes. I
> think we need to have some fundamental behavior changes to that interaction
> before this will actually work. Comparing it to how iOS does it would be
> useful.
> 
> Also, I think we will need to have some verbosity around caret position for
> it to be usable.

No, I don't have a device and have been using the simulator; I think it's probably infeasible for me to continue working on this bug without a actual device.

Though I agree it is necessary to indicate the caret position too.

	Eitan Isaacson [:eeejay] Reporter
	Comment 5 • 6 years ago

This was Firefox OS.