Closed Bug 943071 Opened 11 years ago Closed 11 years ago

Selection monocles aren't positioned correctly after the browser shifts due to skb display

Categories

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

x86_64
Windows 8.1
defect

Tracking

(firefox28 verified, firefox29 verified)

VERIFIED FIXED
Firefox 29
Tracking Status
firefox28 --- verified
firefox29 --- verified

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Keywords: regression, Whiteboard: [beta28] [defect] p=2)

Attachments

(2 files)

str: 1) compose a new message in gmail 2) tap the text body and enter some text 3) tap the entered text to invoke selection monocles result: spotty support for selection, and dragging monocles sometimes doesn't work.
Whiteboard: [triage] → [release28]
Whiteboard: [release28] → [beta28] p=0
Depends on: 950832
Assignee: nobody → jmathies
Whiteboard: [beta28] p=0 → [beta28] p=2
Blocks: metrov1it21
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Summary: Gmail composition text body doesn't work with text selection → Selection monocles aren't positioned correctly after the browser shifts due to skb display
Keywords: regression
Blocks: metrov1it22
No longer blocks: metrov1it21
Blocks: 932783
Attached patch regression fixSplinter Review
Attachment #8355222 - Attachment description: fix → regression fix
Comment on attachment 8355222 [details] [diff] [review] regression fix The result of a copy paste error in bug 932783.
Attachment #8355222 - Flags: review?(mbrubeck)
Comment on attachment 8355239 [details] [diff] [review] google compose fix This one is odd. We have a content editable test that applies to the body of a page. This test is currently succeeding. However in this gmail case caretPositionFromPoint fails in similar markup. The one difference is that the body is in a sub document of an iframe, which might be causing problems. I'm going to try and work up a test case for caretPositionFromPoint and file it as a new bug in layout. In the mean time, in cases where cpfp fails for unknown reasons, we should fall back on the selectAtPoint apis.
Attachment #8355239 - Flags: review?(mbrubeck)
Attachment #8355222 - Flags: review?(mbrubeck) → review+
Attachment #8355239 - Flags: review?(mbrubeck) → review+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Comment on attachment 8355222 [details] [diff] [review] regression fix [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 950832 User impact if declined: buggy selection control Testing completed (on m-c, etc.): yes Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #8355222 - Flags: approval-mozilla-aurora?
Comment on attachment 8355239 [details] [diff] [review] google compose fix [Approval Request Comment] Bug caused by (feature/regressing bug #): none User impact if declined: gmail selection issues Testing completed (on m-c, etc.): yes Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #8355239 - Flags: approval-mozilla-aurora?
Attachment #8355222 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #8355239 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [beta28] p=2 → [beta28] [defect] p=2
Kamil, can you please verify this is fixed in the latest Nightly and Aurora builds?
Flags: needinfo?(kamiljoz)
Depends on: 960886
Depends on: 960889
No longer depends on: 960886
No longer depends on: 960889
Went through the following issue during iteration #21 testing. Used 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/ Before testing the issue, I reproduced the original issue mentioned in comment #0 using the following build: - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/11/2013-11-26-03-02-01-mozilla-central/ For the following test cases, I copied several different paragraphs of text and pasted them into a draft email. From there, used the selection monocles. - Went through the original issue outlined in comment #0 - Ensured that taping inside the body created a selection monocle that is usable - Ensured that taping on "Email Address" and "Subject" placed the monocle in those area's when selected - Ensured that when the text is selected, two monocles appear at the ends of the selected text - Ensured that both of the monocles can be used to either select or deselect more text - Ensured that the monocles can be used while the email draft is using both "full" and "snapped" views - Ensured that the selection animation isn't janky nor has any artifacts when highlighting text - Went through all of the above test cases using a real mouse and ensured that a user can still select text without any issues - Went through the following test cases in full and filled view using several variations of filled view Found a few issues relating to monocles/touch selection that affects this and everything else, created the following bugs: - Bug # 960886 - Bug # 960889 - Bug # 960896
Flags: needinfo?(kamiljoz)
Verified as fixed for iteration #22, with both latest Nightly and Aurora on Surface pro 2 with Windows 8.1 64-bit.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: