Dialer app should follow text selection pattern.

RESOLVED FIXED in 2.2 S3 (9jan)

Status

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: swilkes, Assigned: thills)

Tracking

unspecified
2.2 S3 (9jan)
x86
macOS
Dependency tree / graph
Bug Flags:
in-moztrap +

Firefox Tracking Flags

(feature-b2g:2.2+, ux-b2g:2.2)

Details

(Whiteboard: [planned-sprint c=3])

Attachments

(3 attachments)

Reporter

Description

5 years ago
See Comms pages of attached spec.

User should be able to select phone number/digits typed into dialer input field. 

* Input fields (input areas, input dialogs and search fields) are the only Building Blocks with selectable text. 

* HTML elements like buttons or links, or events like ontouchstart or onclick, should trigger the action when tapped rather than triggering text selection.

Updated

5 years ago
Blocks: gaia-copy-paste
No longer blocks: CopyPasteLegacy

Comment 1

5 years ago
The Gecko work is close to completion, the remaining part is to fix test case failures then pref it on in m-c bug 1092888. After the bug landed, text selection and cut/copy/paste be triggered in apps on both editable and non-editable elements.

Gaia per app work in v2.2 is to follow UX guideline and leverage CSS -moz-user-select https://developer.mozilla.org/en-US/docs/Web/CSS/user-select to make certain elements non-selectable.

Before Gecko is pref on in m-c, Gaia can manually switch it on by the following two pref to test in advance:
pref("selectioncaret.enabled", on);
pref("selectioncaret.noneditable", on);
Duplicate of this bug: 899020
This may turn into a meta bug, depending on how much work there is.
Target Milestone: --- → 2.2 S1 (5dec)

Comment 4

5 years ago
This is a 2.2 feature.
feature-b2g: --- → 2.2+
QA Contact: jlorenzo
Whiteboard: [planned-sprint c=?]
Target Milestone: 2.2 S1 (5dec) → 2.2 S2 (19dec)
QA Whiteboard: [2.2-feature-qa+]
Assignee: nobody → thills
Whiteboard: [planned-sprint c=?] → [planned-sprint c=6]
Assignee

Updated

5 years ago
Status: NEW → ASSIGNED
Assignee

Comment 5

5 years ago
Here's my initial assessment of what needs to be done on dialer.  I would like to get a double check on 4a and 5a below from you team as it's not explicit in the spec.  If I read the spec, it says that it should be non-selectable, but I could see a use case for user to want to select the text in 4a and 5a, so just want to double check this.


1.  Make call log elements user-select none
    a. In the call log info menu (after a long press on a call log) 
    -- make the "call information" and the "Send Message" buttons non-selectable
    -- make the contact or phone number non-selectable (it is currently selectable)
    b. In the Call Log info page (after a long press, then click "call information"_
    -- make the call log entries non-selectable (they are currently selectable).
    -- make the banner at the top (the contact or telephone number) non-selectable -- it's 
       currently selectable
    -- "Add to existing contact" button is currently selectable -- should be non-selectable
    -- "Create new contact" button is currently selectable -- should be non-selectable.
    c. "Call Log" banner at the top of the call log is currently selectable -- should be 
        non-selectable
2.  Make the dialer contact info user-selectable
    a.  the non-editable contact matching bar should be non-selectable.  It's currently 
	    selectable.
3.  Make the keypad buttons non-selectable
4.  In the call screen make all the elements non-selectable	
    a. The contact Name and number should be non-selectable.  It's currently selectable.
    b. The photo should be non-selectable.  It's currently selectable.
    c. On the contact (under the duration), the "via SIM1" is currently selectable -- should 
	   be non-selectable
    d. In the call screen the duration is currently selectable -- should be non-selectable.
    e. The inbound/outbound icon is currently selectable -- should be non-selectable.
5.  In the call screen keypad, make all the elements non-selectable
    a. The contact is selectable.  Should be set to not selectable
    b. Check to make sure that when you try and select the bottom right button to take you 
	   back to the call screen that the 3 button is not selected
    c. The entire keypad is selected when you press near the Contact in this screen.
    d. When you long press the '9' or any other key, it stays selected
    e. When you press in the white space above the keyboard, the key underneath it is selected.  
       Best to see this on flame as there is a large white space between the contact and the 
       start of the keypad numbers.

Thanks,

-tamara
Flags: needinfo?(cawang)
Hi Tamara, 

I'm quite concerned with 5c and 5e. Need Omega, the text selection owner, to double confirm it. Thanks!
Flags: needinfo?(cawang) → needinfo?(ofeng)
After discussion, we think everything in 5. should be non-selectable, including 5c and 5e.
Flags: needinfo?(ofeng)
Duplicate of this bug: 1101997
Target Milestone: 2.2 S2 (19dec) → 2.2 S3 (9jan)
Whiteboard: [planned-sprint c=6] → [planned-sprint c=3]
Assignee

Comment 9

5 years ago
Hi Howie,

I seem to be having problems getting text selection to work for an <input> element that does not use the keyboard (but the dialer keypad) for inputting the data.

I want to make sure I've got the pref set correctly.  In your comment 1 you said that they need to be pref on:

pref("selectioncaret.enabled", on);
pref("selectioncaret.noneditable", on);

are these in the file:  https://hg.mozilla.org/mozilla-central/file/b3e6101aa94b/b2g/app/b2g.js#l1046

I tried setting both these to true (instead of on).  Oddly, everything works for -moz-user-select: text except the one <input> field that has it's input via the dialer keypad.  Is there something else I need to do here?

Thanks,
-tamara
Flags: needinfo?(hochang)

Comment 10

5 years ago
Hi Tamara, 
The text selection is now default on in master, so we don't need to set the pref on manually.
If I'm correct, what you mean is text selection can not be triggered in the input field showing the number when dialing through dialer keypad. In Page 9, the second picture of the spec.

Hi Peter, George,
Can you help to take a look? thank you.
Flags: needinfo?(pchang)
Flags: needinfo?(hochang)
Flags: needinfo?(gduan)
Hi Peter,

I tried to remove "pointer-events: none" attribute from that input field and things went well.
I guess there are some conflict when setting -moz-user-select: none and pointer-events: none ?
Flags: needinfo?(gduan)
Assignee

Comment 12

5 years ago
Attachment #8544696 - Flags: review?(drs.bugzilla)
Comment on attachment 8544696 [details] [review]
PR for text selection

I left some questions on the PR. Please answer them and we'll continue the review.
Flags: needinfo?(thills)
(In reply to George Duan [:gduan] [:喬智] from comment #11)
> Hi Peter,
> 
> I tried to remove "pointer-events: none" attribute from that input field and
> things went well.
> I guess there are some conflict when setting -moz-user-select: none and
> pointer-events: none ?

Morris, any idea about the conflict?
Flags: needinfo?(pchang) → needinfo?(mtseng)
In current master, #phone-number-view has both "pointer-event: none" and "-moz-user-select: none" which means mouse or touch event won't send to #phone-number-view element. That is, if we long press on #phone-number-view, the touch event would send to the element underneath #phone-number-view, which is #phone-number-view-container. Since #phone-number-view-container is selectable in master, you'll find carets appear on this element.

I saw PR already set non-selectable to most elements, so I don't think this problem exists.
Flags: needinfo?(mtseng)
Comment on attachment 8544696 [details] [review]
PR for text selection

See my comments on the PR.
Attachment #8544696 - Flags: review?(drs.bugzilla) → review-
Assignee

Comment 17

5 years ago
Also filed Bug 1118881 as a follow up.
Flags: needinfo?(thills)
Attachment #8545994 - Flags: review?(drs.bugzilla)
Comment on attachment 8545994 [details] [review]
Updated PR after last review

Looks good, thanks!
Attachment #8545994 - Flags: review?(drs.bugzilla) → review+

Updated

5 years ago
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Depends on: 1121586
You need to log in before you can comment on or make changes to this bug.