Closed Bug 943071 Opened 6 years ago Closed 6 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+
https://hg.mozilla.org/mozilla-central/rev/fc6a9efc7bb7
https://hg.mozilla.org/mozilla-central/rev/a65d449c77f9
Status: ASSIGNED → RESOLVED
Closed: 6 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.