Page MenuHomePhabricator

elm_scroller: mark the scroller as regular focus element
AbandonedPublic

Authored by bu5hm4n on Jul 12 2018, 7:12 AM.

Details

Summary

this fixes moving away from the scroller if the content is not from elm.

What happens if this is not regular, is that the movement logic picks up
the scroller as the only focused element, which is right, since the
scroller is focused (via some wrapper object). However, the scroller in
the object is only logical (which is used for containers that never get
focus), but this is not right in this regard, as focus moves to the
scroller, in this configuration.

ref T6804

Diff Detail

Repository
rEFL core/efl
Branch
master
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 6859
bu5hm4n created this revision.Jul 12 2018, 7:12 AM
bu5hm4n requested review of this revision.Jul 12 2018, 7:12 AM
YOhoho accepted this revision.Jul 12 2018, 11:20 AM
YOhoho added a subscriber: YOhoho.

This patch can fix a case of scroller with non-focusable content.
We can simply reproduce with long text label in scroller.

This revision is now accepted and ready to land.Jul 12 2018, 11:20 AM
bu5hm4n planned changes to this revision.Jul 12 2018, 12:31 PM
bu5hm4n added a project: DO NOT MERGE.

That broke things.

ping @bu5hm4n
Any other idea?

@bu5hm4n
ping, scroller which have no content still can't get focus

Yes - you said that @eagleeye will handle it and assigned it to him... https://phab.enlightenment.org/D6587#118371

I meant focus move policy when scroller have focusable content.
The interaction problem between scroller and other widget is focus manager side issue.

I guess problem is that scroller have focusable dummy element when it doesn't have focusable content. but it is not included in pd->iterator_list in _efl_ui_focus_manager_root_focus_efl_ui_focus_manager_border_elements_get. so, scroller can't find focusable element.

bu5hm4n abandoned this revision.Nov 28 2018, 1:16 PM