Selection action bar should be disappeared when selection loses focus |
||||||||
Issue descriptionCurrent implementation of Action Bar doesn't observe focus changes, it observes selection change to control show/hide state. This implementation is wrong because action bar should be shown only for active selection == focused selection. [1] attempt to keep selection, aka inactive selection, after focus move for accomplish browser interoperability. We need some plumbing for action bar to tell focus changes like IME. In FocusController::setFocusedController(), we call InputMethodController::willChangeFocus(). Set Pri-1, because this issue blocks fixing browser interoperability issue. [1] http://crrev.com/2616623002: Do not send redundant ViewHostMsg_TextInputStateChanged-message Example of failed test: public void testSelectActionBarClearedOnTappingOutsideInput() throws Exception { commitText("Sample Text", 1); DOMUtils.longPressNode(this, mContentViewCore, "input_text"); assertWaitForKeyboardStatus(true); assertWaitForSelectActionBarStatus(true); DOMUtils.clickNode(this, mContentViewCore, "input_radio"); // Selection is now inactive rather than clear. assertWaitForKeyboardStatus(false); // We've still seen action bar event if focus is moved to radio button. assertWaitForSelectActionBarStatus(false); }
,
Jan 23 2017
>This probably requires change of handle visibility logic in FrameSelection / SelectionEditor / FrameView logic, >which I think amaralp@ is an expert of. Reassigning. Make sense. Action bar and selection handle should be show/hide same timing and same logic. "inactive selection" is defined in [1]. ::selection applies to active selections, wherease ::inactive-selection applies to inactive selections (e.g. when the document window is inactive and therefore not receiving events). When document window loses focus, we paint selection in gray, but we've not yet painted selection gray when selection doesn't have focus but document window has focus, see [2] for demonstration. The spec[3][4] don't mention moving focus clears selection. So, we should not clear selection when moving focus. [1] https://drafts.csswg.org/css-pseudo/#selectordef-inactive-selection CSS Pseudo-Elements Module Level 4 [2] https://jsfiddle.net/pwmn39g3/4/ selection doesn't have focus [3] https://html.spec.whatwg.org/multipage/interaction.html#focus-management-apis [4] https://www.w3.org/TR/uievents/#event-type-focus
,
Jan 23 2017
#c2, supplement; UI Event spec[4] doesn't define "default action" for focus/blur/focusin/focusout. Hence, we should not clear selection.
,
Jan 24 2017
The only goal of this bug is to unblock landing https://codereview.chromium.org/2616623002, is that right? The behavior change seems minor from a user point of view, so I don't think this calls for major changes to add new focus IPCs or anything. I made a suggestion on the bug for a way to just change the test to keep it passing.
,
Feb 15 2017
,
Feb 20 2017
,
Apr 26 2017
In r464698, https://codereview.chromium.org/2616623002 did change the test as suggested in #4. But changing the test only hid the problem? We got a report of regression in a similar use case: http://crbug.com/714525 . As yosin@ pointed out, action bar should disappear when the selection looses focus. The mouse click moves focus away from the selection (here focus happened to move to an <input type="radio">, but that doesn't really matter).
,
Apr 27 2017
Lower to Pri-2, since inactive selection is not popular. Inactive selection is made by JavaScript moves focus to editable area to non-editable area.
,
Oct 4 2017
,
Oct 4
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by changwan@chromium.org
, Jan 23 2017Owner: amaralp@chromium.org
Status: Assigned (was: Untriaged)