960896 - OSK in the way when selecting text via emails (Gmail, Hotmail)

Status: RESOLVED INCOMPLETE

(Firefox for Metro Graveyard :: Input, defect)

Description

[Kamil Jozwiak [:kjozwiak]]

Attachment: OSK in the way of text

When you tap on the body of an email, the OSK will slide into view and make it difficult to select text that's being hidden under the OSK. When that happens, the only way to select the hidden text would be to dismiss the OSK by taping anywhere on the site and than scroll the email so the next time the OSK slides into view it won't block the desired text. I reproduce this on both Gmail and Hotmail using both Nightly/Aurora (see below for specific builds)

- Attached two screenshots to illustrate the issue

Steps to reproduce the issue:

1) Open Firefox Metro
2) Log into Gmail/Hotmail (doesn't really matter which one)
3) Once logged in, start a new email and paste a few paragraphs into it
4) Tap in the body and you'll receive the selection monocle + OSK will appear
5) Try selecting some text that's right near the edge of the OSK and some that is being hidden underneath the OSK

Current Behavior:

- If a user wants to select some text that's near the edge of the OSK + some that's being hidden, the user will have to dismiss the OSK and slide the hidden text higher so next time the OSK doesn't overlap it.

Expected Behavior:

- Honestly not really sure, but currently its really unintuitive and difficult to use. Maybe if the OSK slides in we can move the webpage above the OSK?? This way the user can scroll and move the monocles without the OSK being in the way and hiding text.

Issue found using the following builds:
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-16-00-40-03-mozilla-aurora/
- http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-01-16-03-02-50-mozilla-central/

Comment 1

[Kamil Jozwiak [:kjozwiak]]

Attachment: OSK hidding text #2

Comment 2

[Jim Mathies [:jimm]]

(In reply to Kamil Jozwiak [:kjozwiak] from comment #1)
> Created attachment 8361526 [details]
> OSK hidding text #2

Can't you scroll the compose view up to get at the lower selection grabber?

Comment 3

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #2)
> (In reply to Kamil Jozwiak [:kjozwiak] from comment #1)
> > Created attachment 8361526 [details]
> > OSK hidding text #2
> 
> Can't you scroll the compose view up to get at the lower selection grabber?

You can in outlook.com. Although there's a bug with content editable where the browser doesn't shift on the initial tap. Another problem is that the browser offset doesn't update after the scroll, so if you scroll selection below the skb, the browser doesn't shift. Plus, if the selection area is large, browser shift won't solve the problem, since we don't know which end of the selection the user wants to get to.

This is really really tricky when dealing with tall compose views, I'm not convinced simple browser shifting can solve this. 

Suggest we kick this to v2 so we have some time to think about how to solve complex document editing.

Comment 4

[Jim Mathies [:jimm]]

IE does a great job with this. What they do is allow the user's scrolling of the scrollable view to feed up into the parent browser position. So for example, while scrolling a compose view up to get to the bottom of the view, if the user reaches the the lower bounds of the scrollable view, and the lower bounds of the scrollable view are below the skb, continuing to scroll scrolls the browser up to the point where the lower bounds of the browser match the upper bound of the skb. :) Really smart. We can support this, but not in v1.

Comment 5

[Jim Mathies [:jimm]]

I wonder if we could put the browser deck in a scrollbox and add padding above/below the deck equal to the height of the skb? Then we could get rid of the programatic offsetting we do, and rely on apzc scroll to handle positioning of the browser / scrollable sub docs.

Comment 6

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #5)
> I wonder if we could put the browser deck in a scrollbox and add padding
> above/below the deck equal to the height of the skb? Then we could get rid
> of the programatic offsetting we do, and rely on apzc scroll to handle
> positioning of the browser / scrollable sub docs.

actually, add padding just below. No need for it on top of the deck.

Comment 7

[Firefox Bug Husbandry Bot]

Mass close of bugs in obsolete product https://bugzilla.mozilla.org/show_bug.cgi?id=1350354