Issue metadata
Sign in to add a comment
|
[OOPIFs] tooltip and cursor pointer don't always update when moving over iframe
Reported by
cool...@gmail.com,
Mar 10 2017
|
||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Steps to reproduce the problem:
1. install the unpacked extension from the attached twitch5.zip
2. navigate to chrome-extension://TWITCH5-EXTENSION-ID/player.html?channel=coolcmd
3. hit INSERT key on the keyboard to open the chat
4. move the mouse fast enough from left to right
What is the expected behavior?
while above the chat (third-party iframe), mouse cursor must have default shape (arrow), and tooltip must be hidden.
you can see expected behavior if run command
chrome --force-fieldtrials=SiteIsolationExtensions/Control
which disables OOPIFs (in my version of Chrome)
What went wrong?
while above the chat (third-party iframe), mouse cursor have incorrect shape (hand) and tooltip. see the attached iframe.mp4.
Did this work before? Yes 55
Does this work in other browsers? Yes Firefox
Chrome version: 57.0.2987.98 Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
part of the <div id="размерчата"> is located ABOVE the <iframe>. specific CSS rule:
#размерчата {margin-right: -8px}
this is cause the issue.
,
Mar 10 2017
Also was this working on Chrome version 56?
,
Mar 10 2017
Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 10 2017
Thanks for the report! wjmaclean@, can you help triage and find an owner for this? (I know paulmeyer@ worked on tooltips in issue 609932 .)
,
Mar 10 2017
Paul, could you triage this? You have (I think) the most experience with OOPIF tool tips.
,
Mar 10 2017
Given the video, I don't think it is tooltip specific bug. Whenever the tooltip is displayed over the chat window, the mouse cursor is also not the expected one. The bug seems to occur when the cursor is moved faster and doesn't occur when moved slower and both cursor type and tooltip are both always in the same state, so I would suspect just a generic bug related to mouse leave/enter state.
,
Mar 10 2017
Actually, I'll take this back for now in case it's mouse-leave/enter related.
,
Mar 10 2017
Comment 8: Thanks! I'm updating the summary accordingly.
,
Mar 10 2017
The cursor problem is likely to be bug 614540 . Race condition between two cursor updates. I don't know about the tooltip text, but it could be similar.
,
Mar 14 2017
In the case of mouse enter/leave, it would seem like there's a semantic ordering that could be introduced ... for example, if we receive the leave after the enter, and the renderer ids (for example) don't match between the two we would not use the leave for setting the current cursor? Or perhaps we would queue the 'enter' until the 'leave' has been received and processed? I'm not quite sure (yet) how the drag-handle regions are defined, but something similar might work there too?
,
Mar 14 2017
BTW, workaround for my case:
#размерчата:hover + #чат {pointer-events: none}
,
Apr 28 2017
Assigning to wjmaclean@, per comment 8. Maybe we can take a look at it for M60?
,
Jul 26 2017
Sounds like the cursor update part was resolved in kenrb@'s r486528 for issue 614540 . wjmaclean@: Should this bug stay open for the tooltip issue?
,
Jul 26 2017
Yes, keeping it open until the tooltips issue is resolved seems reasonable.
,
Sep 19
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Mar 10 2017Labels: Needs-Feedback