Mac: don't use a custom tracking area in BridgedContentView
Currently, in BridgedContentView we "opt out"[1] of BaseView's tracking area to install a different one which: - Specifies `NSTrackingCursorUpdate` - As a consequence, only tracks while app is active, since the docs say that always tracking is incompatible with cursor updates However: - Empirically, cursor updates work fine without this (some test cases: move mouse between Omnibox and other parts of topchrome, move from webcontent links/inputs to topchrome and vice-versa). - Only tracking while app is active means we don't get entered/exited events from app switching. This means: - Switching away from Chrome while showing a topchrome hover tooltip keeps the hover on and makes the tooltip stuck - Under some circumstances, hover stops working on switching back to Chrome (see bug) - Even though we allow mouse clicks to function when Chrome is inactive (that is, we return `YES` from `acceptsFirstMouse:`, we don't process hovers in this case, contrary to other apps on the system. This change removes BridgedContentView's tracking area in favor of the default one and gives BaseView some explicit enable/disables, mostly to make tests happy. [1] By overriding a private method with a no-op! Bug: 841792 Change-Id: Ifb5d65e22299959b8cac25a9e0a0407650a40746 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2216530Reviewed-by:Elly Fong-Jones <ellyjones@chromium.org> Reviewed-by:
Avi Drissman <avi@chromium.org> Commit-Queue: Leonard Grey <lgrey@chromium.org> Cr-Commit-Position: refs/heads/master@{#773848}
Showing
Please register or sign in to comment