855417 - Defect - Tap on an empty text input places caret selection monocle at the top of the screen

Status: VERIFIED FIXED

(Firefox for Metro Graveyard :: Input, defect, P1)

Description

[Jim Mathies [:jimm]]

In the console I see:

"no rects in selection range. unexpected."

This should be pretty easy to fix.

Comment 1

[Jim Mathies [:jimm]]

Attachment: patch

Comment 2

[Jim Mathies [:jimm]]

Attachment: patch

Comment 3

[Jim Mathies [:jimm]]

Attachment: patch

Comment 4

[Jim Mathies [:jimm]]

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

This adds a new data point SelectionHandler hands back to SelectionHelperUI. The pertinent line of code is:

seldata.selectionRangeFound = !!rects.length;

In SelectionHelperUI I check this and if found to be false I don't display the caret monocle.

The rest of the changes are just clarification changes to the utility method _extractUIRectsFromRange.

Comment 5

[Jim Mathies [:jimm]]

Ignore the debug pref, I've removed that from my local patch.

Comment 6

[Allison Naaktgeboren :ally]

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

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

almost there! little bit of refactoring and you should be golden

::: browser/metro/base/content/contenthandlers/SelectionHandler.js
@@ +1138,5 @@
> +   * _extractUIRectsFromRange - Extracts coordinate information from a
> +   * smoothed selection range used by SelectionHelperUI to position
> +   * selection related ui elements. Returns client relative coordinates.
> +   *
> +   * @return table containing various ui rects and information 

nit-training whitespace

@@ +1184,3 @@
>  
> +    // If we don't have a range we can attach to let SelectionHelperUI know.
> +    seldata.selectionRangeFound = !!rects.length;

please wrap the code that relies on range data a bit better. (discussed in irc)

::: browser/metro/profile/metro.js
@@ +18,5 @@
>  pref("metro.debug.treatmouseastouch", false);
>  pref("metro.debug.colorizeInputOverlay", false);
>  pref("metro.debug.selection.displayRanges", false);
>  pref("metro.debug.selection.dumpRanges", false);
> +pref("metro.debug.selection.dumpEvents", true);

Will this be set back to false in the case of release builds of metro?

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/842c175f344c

Comment 8

[raymond [:retornam] (inactive)]

tested on April 8th, 2012  built from http://hg.mozilla.org/mozilla-central/rev/b0d842380959

This works some of  the time depending on the length  of time of your tap. I tested this on www.bing.com and www.google.com

STR:
1) Visit any of the above websites
2) Tab on the text input to  bring up the onscreen keyboard ( This works depending on the how short your tap. The shorter the length of your tap, the onscreen keyboard is shown. However if your tab is too long,  the address bar is shown and the text input is nor the address bar are selected.

Comment 9

[Jim Mathies [:jimm]]

(In reply to raymond [:retornam] from comment #8)
> tested on April 8th, 2012  built from
> http://hg.mozilla.org/mozilla-central/rev/b0d842380959
> 
> This works some of  the time depending on the length  of time of your tap. I
> tested this on www.bing.com and www.google.com
> 
> STR:
> 1) Visit any of the above websites
> 2) Tab on the text input to  bring up the onscreen keyboard ( This works
> depending on the how short your tap. The shorter the length of your tap, the
> onscreen keyboard is shown. However if your tab is too long,  the address
> bar is shown and the text input is nor the address bar are selected.

That's actually defined behavior, by tap-holding (you should see a little focus rect animate under your finger) you are invoking the context menu command, which is just like right-clicking. If you have text on your clipboard you should get a paste menu. If there's no text in the clipboard the event will bubble up and invoke the appbar UI.  

Is this the behavior you're seeing raymond?

Comment 10

[Jim Mathies [:jimm]]

Also note this bug (as described) is about: tap on an empty text input places caret selection monocle at the top of the screen. So we should be confirming this specific bug is fixed. If other issues surface while confirming this bug, we should file a new bug.

Comment 11

[raymond [:retornam] (inactive)]

(In reply to Jim Mathies [:jimm] from comment #9)
> (In reply to raymond [:retornam] from comment #8)
> > tested on April 8th, 2012  built from
> > http://hg.mozilla.org/mozilla-central/rev/b0d842380959
> > 
> > This works some of  the time depending on the length  of time of your tap. I
> > tested this on www.bing.com and www.google.com
> > 
> > STR:
> > 1) Visit any of the above websites
> > 2) Tab on the text input to  bring up the onscreen keyboard ( This works
> > depending on the how short your tap. The shorter the length of your tap, the
> > onscreen keyboard is shown. However if your tab is too long,  the address
> > bar is shown and the text input is nor the address bar are selected.
> 
> That's actually defined behavior, by tap-holding (you should see a little
> focus rect animate under your finger) you are invoking the context menu
> command, which is just like right-clicking. If you have text on your
> clipboard you should get a paste menu. If there's no text in the clipboard
> the event will bubble up and invoke the appbar UI.  
> 
> Is this the behavior you're seeing raymond?

Yes it is. I didn't have any text on my clipboard at first so I thought this was a related bug. 


Tapping on an empty text input no longer places the caret selection monocle at the top of the screen.  Marking this bug as fixed

Thanks Jim



tested on April 8th, 2012  built from http://hg.mozilla.org/mozilla-central/rev/b0d842380959

Comment 12

[Jim Mathies [:jimm]]

verifying for it8. This is also verified regularly through automated tests.

Comment 13

[Samvedana (:Samvedana)]

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130807030216
Built from http://hg.mozilla.org/mozilla-central/rev/1fb5d14e8348

WFM
Tested on windows 8 using latest nightly for iteration-11. Tapping on an empty text input no longer placed the caret selection monocle at the top of the screen

Comment 14

[Samvedana (:Samvedana)]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130825030201
Built from http://hg.mozilla.org/mozilla-central/rev/01576441bdc6

WFM
Tested on windows 8 using latest nightly for iteration-12. Tapping on an empty text input no longer placed the caret selection monocle at the top of the screen.