Closed Bug 855417 Opened 11 years ago Closed 11 years ago

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

Categories

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

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 23

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Keywords: regression, Whiteboard: feature=defect u=metro_firefox_user c=content_features p=1)

Attachments

(1 file, 2 obsolete files)

In the console I see:

"no rects in selection range. unexpected."

This should be pretty easy to fix.
Keywords: regression
Blocks: metrov1it5
Priority: -- → P1
Summary: Tap on an empty text input places caret selection monocle at the top of the screen → Defect - Tap on an empty text input places caret selection monocle at the top of the screen
Whiteboard: feature=defect u=metro_firefox_user c=content_features p=tbd
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → jmathies
Attached patch patch (obsolete) — Splinter Review
Attachment #730621 - Attachment is obsolete: true
Attached patch patchSplinter Review
Attachment #730622 - Attachment is obsolete: true
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.
Attachment #730625 - Flags: review?(ally)
Ignore the debug pref, I've removed that from my local patch.
Whiteboard: feature=defect u=metro_firefox_user c=content_features p=tbd → feature=defect u=metro_firefox_user c=content_features p=1
Status: NEW → ASSIGNED
QA Contact: jbecerra
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?
Attachment #730625 - Flags: review?(ally)
Attachment #730625 - Flags: review+
Attachment #730625 - Flags: feedback+
https://hg.mozilla.org/mozilla-central/rev/842c175f344c
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 23
Flags: needinfo?(jbecerra)
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.
Status: RESOLVED → REOPENED
Flags: needinfo?(jbecerra)
Resolution: FIXED → ---
(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?
Flags: needinfo?(mozbugs.retornam)
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.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED

(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
Status: RESOLVED → VERIFIED
Flags: needinfo?(mozbugs.retornam)
verifying for it8. This is also verified regularly through automated tests.
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
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.
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.