Closed Bug 855417 Opened 12 years ago Closed 12 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+
Status: ASSIGNED → RESOLVED
Closed: 12 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: 12 years ago12 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.

Attachment

General

Created:
Updated:
Size: