Closed Bug 857813 Opened 7 years ago Closed 6 years ago

[MP] Defect - Auto-complete popups should display above the target element if obscured by the skb

Categories

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

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: [preview] [forms] feature=defect c=Content_features u=metro_firefox_user p=3)

Attachments

(1 file)

Currently we always display these below elements. MenuUI's AutofillMenuUI should be smarter about where it displays these based on the current state of the viewable.
Whiteboard: [forms]
Attached image gripper
We also have a problem with the text monocles being obscured by the popup. Seems like our auto-complete popups need some rethinking.
Hey yuan, any ideas on this?

we have two problem - 

1) lower auto-complete menus will often be obscured by the keyboard
2) lower auto-complete menus interfere with text selection.
No longer blocks: skb
Summary: Auto-complete popups should display above the target element if obscured by the skb → Defect - Auto-complete popups should display above the target element if obscured by the skb
Whiteboard: [forms] → [forms] feature=defect c=tbd u=tbd p=0
p=2
Depends on: 861853
No longer depends on: 861853
Blocks: 861853
No longer blocks: metrov1defect&change
Priority: -- → P2
Blocks: metrov1defect&change
No longer blocks: 861853
ask for input is in comment 2 :)
Flags: needinfo?(ywang)
I think when (In reply to Jim Mathies [:jimm] from comment #2)
> Hey yuan, any ideas on this?
> 
> we have two problem - 
> 
> 1) lower auto-complete menus will often be obscured by the keyboard

We briefly discussed this on the work week. Even when the users have hardware keyboard attached, they might also run into the same issue when there is no enough space to display a full menu. 

I think the solution here is to scroll the page up to a position where the auto-complete menu can be completely displayed. And there should be a margin(about 5px I would say) in between the bottom of the menu and the edge of keyboard/bottom of the screen.

Once the users start typing, the auto-complete menu updates the content and its length. Because the page has moved up to adjust for the maximum height, no more scrolling is needed during typing.


> 2) lower auto-complete menus interfere with text selection.

I think we can apply the same solution here. We scroll the page up. Text selection menu still shows above the element whereas auto-complete shows below the element.
Flags: needinfo?(ywang)
(In reply to Yuan Wang(:Yuan) – Firefox UX Team from comment #5)
> I think when (In reply to Jim Mathies [:jimm] from comment #2)
> > Hey yuan, any ideas on this?
> > 
> > we have two problem - 
> > 
> > 1) lower auto-complete menus will often be obscured by the keyboard
> 
> We briefly discussed this on the work week. Even when the users have
> hardware keyboard attached, they might also run into the same issue when
> there is no enough space to display a full menu. 
> 
> I think the solution here is to scroll the page up to a position where the
> auto-complete menu can be completely displayed. And there should be a
> margin(about 5px I would say) in between the bottom of the menu and the edge
> of keyboard/bottom of the screen.

This is going to be complex to pull off. The autocomplete menu is filled dynamically and asynchronously. So you would end up with two movements of the browser, one for the keyboard, and then another for the menu after we've been able to calculate it's height. Plus our browser shifting isn't very performant currently, so this won't look too hot.

Have we considered moving auto-complete down into a fixed rect above the soft keyboard when users interact via touch?
Briefly talked about this bug today on the status meeting. 

We proposed to have a fixed number of results (I would suggest 8 items) shown up in the auto-complete form. The user can scroll the auto-complete form if there is more than 8 results.

If the input field and auto-complete form are covered by the keyboard, initiating OSK should scroll up the page and move the forms up in a fixed height.


The idea Jim proposed in Comment 6 might not work well when the users attach hardware keyboard. The auto-complete results should be close to the input field. Setting them apart can make the scanning and typing process difficult.
Whiteboard: [forms] feature=defect c=tbd u=tbd p=0 → [forms] feature=defect c=firefox_app_bar_and_autocomplete u=tbd p=0
Blocks: 801121
Whiteboard: [forms] feature=defect c=firefox_app_bar_and_autocomplete u=tbd p=0 → [forms] feature=defect c=form_autocomplete u=tbd p=0
Whiteboard: [forms] feature=defect c=form_autocomplete u=tbd p=0 → [forms] feature=defect c=Content_features u=metro_firefox_user p=0
Whiteboard: [forms] feature=defect c=Content_features u=metro_firefox_user p=0 → feature=defect c=Content_features u=metro_firefox_user p=0 [forms]
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=0 [forms] → feature=defect c=Content_features u=metro_firefox_user p=0 [forms][preview-triage]
Whiteboard: feature=defect c=Content_features u=metro_firefox_user p=0 [forms][preview-triage] → [preview-triage] [forms] feature=defect c=Content_features u=metro_firefox_user p=0
Blocks: metrov1backlog
No longer blocks: metrov1defect&change
Blocks: metrov2defect&change
No longer blocks: metrov1backlog
Blocks: metrov1backlog
No longer blocks: metrov2defect&change
Summary: Defect - Auto-complete popups should display above the target element if obscured by the skb → [MP] Defect - Auto-complete popups should display above the target element if obscured by the skb
Whiteboard: [preview-triage] [forms] feature=defect c=Content_features u=metro_firefox_user p=0 → [preview] [forms] feature=defect c=Content_features u=metro_firefox_user p=0
Assignee: nobody → jmathies
Blocks: metrov1it13
Whiteboard: [preview] [forms] feature=defect c=Content_features u=metro_firefox_user p=0 → [preview] [forms] feature=defect c=Content_features u=metro_firefox_user p=3
No longer blocks: metrov1backlog
Status: NEW → ASSIGNED
QA Contact: jbecerra
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.