-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving puck causes unresponsiveness #1802
Comments
cc @StarScape I tried reproducing this in Firefox now but haven't succeeded. Have you noticed any particular content where it happens? If I can repro in Firefox I can run the profiler on it. I haven't tried using Safari's performance tools but if we can get a profile of it happening on iPhone then we should be able to see where it is spending time. |
I haven't had a chance to debug this yet but one possibility that comes to mind is we have this special logic for handling covered links: 10ten-ja-reader/src/content/get-cursor-position.ts Lines 95 to 118 in 50fe928
It's possible that by deliberately choosing a covered element we end up running that code in a situation it wasn't intended for. Alternatively, if the NHK site is using shadow DOM we might be getting tripped up in some of our shadow DOM mirroring code. In either case, there's a good chance its something in |
The issue occurs every time you hover with the puck cursor over the 10ten popup window. To reproduce this, you have to move very quickly so the popup does not close when the puck cursor is in the gap between the puck cursor and the popup. This also occurs in Safari on macOS but I could not reproduce it in Chrome. Also, this maybe explains why it's not reproducible in Firefox: 10ten-ja-reader/src/content/get-cursor-position.ts Lines 554 to 557 in 50fe928
It appears that the following code is quite slow. 10ten-ja-reader/src/content/get-cursor-position.ts Lines 755 to 764 in 50fe928
In any case we should consider returning early in |
I came across this exact same bug a few days back but hadn’t filed a bug report yet. Likewise happened to me on iOS Safari on the NHK website. Haven’t noticed it anywhere else. |
Thanks so much for digging into this! I also tried reproducing in Chrome but could not.
Yes, that's right. Blink and Webkit currently only support
The code could certainly be tweaked. We should fetch all the properties first before setting them but I don't think there's any way to avoid setting them all while maintaining exact equivalent layout.
I think that would work but first I want to understand what is happening. I don't think it's a case of it just being slow to look up the popup's shadow DOM. I think there might be a more complicated interaction there like us trying to run the "covering link" logic but getting confused by the popup. For example, perhaps we need to be ignoring the popup window in the call to 10ten-ja-reader/src/content/get-text.ts Line 65 in 6495d2f
I'm just guessing, however, because unfortunately I don't have a Mac at home so I can't currently debug this. I have a Mac in the office but I'm only able to get there a couple of times a week at the moment. |
One thing that would help in understanding this is to know if the call to 10ten-ja-reader/src/content/get-cursor-position.ts Lines 59 to 62 in 6495d2f
Or from this call site:
|
I'm still not sure when I'm going to get to a Mac next but I'd really like to ship a fix for this soon along with the pref to revert the font changes. One suggestion is changing the other call site of Another one that occurred to me, however, is to revert the change in #1773 and change the following code: 10ten-ja-reader/src/content/content.ts Lines 703 to 706 in cc0a4c4
to: // Ignore mouse events on the popup window
if (isPopupWindowHostElem(event.target)) {
// If the puck is over the popup window, hide the popup window
if (isPuckPointerEvent(event)) {
this.clearResult();
}
return;
} That would mean that instead of trying to look up content underneath the puck we'd initially close it and then on the next movement try to look up. I'm not sure if that's more or less useful, however. If anyone has a chance to try out either of those suggestions that would be great! Thank you! |
I logged every call to
|
For a short overview, I quickly tried out all of the current suggestions:
Seems to work.
I tried the following but the issue still persists: // First fetch the hit elements (dropping duplicates)
const elements = [
...new Set(document.elementsFromPoint(point.x, point.y)),
].filter((target) => !target.closest('#tenten-ja-window')); EDIT 1: I didn't really understand this behavior as I expected this to work, so I dug a little bit deeper. As last element // First fetch the hit elements (dropping duplicates)
const elements = [
...new Set(document.elementsFromPoint(point.x, point.y)),
].filter(
(target) =>
target.id !== 'tenten-ja-window' &&
!target.querySelector('#tenten-ja-window')
); but the issue somehow still persists. EDIT 2: 10ten-ja-reader/src/content/get-cursor-position.ts Lines 545 to 557 in cc0a4c4
The popup is closed most of the time even when it shouldn't be. |
Seems like you and @enellis have this in hand already, but on the off chance either of you need help from someone else with a Mac dev environment, just drop me an @, I'll be happy to pitch in a hand. |
@enellis Thanks that was really useful investigation. I managed to get into the office today and could reproduce the issue with results like you reported. I've gone ahead and added a fix along the lines you suggested. This seems to work for me. If either you or @StarScape have a chance to confirm the fix that would be great. |
Thanks! I've just merged a fix for this into |
For what it's worth, it looks like the issue really was just the performance of mirroring the shadow DOM elements. Specifically, it looks like WebKit doesn't optimize style flushes very effectively. Even when settings styles on an orphaned element it appears to invalidate styles. Hopefully this will be ultimately fixed when Safari implements |
I can confirm that it works on both iOS and macOS. Thank you! |
Great, thank you! I've submitted the 1.19.1 release to the different app stores now so hopefully this is fixed before too long. Thanks again for all your help! |
Version: 1.19.0
System: Mobile Safari, iOS 17.4.1, iPhone 13 Pro
Description
After the update to version 1.19.0, when moving the puck on more complex pages (I noticed this while browsing NHKニュース), it frequently becomes unresponsive and takes a few seconds to become responsive again.
Troubleshooting
Initially, I suspected the switch from
elementFromPoint()
toelementsFromPoint()
(#1773):10ten-ja-reader/src/content/puck.ts
Lines 443 to 448 in 04233cf
Sure enough, when reverting the change to
the above-mentioned performance issues indeed do not occur.
Then I attempted to exploit the fact that
elementFromPoint()
ignores all elements with thepointer-events: none
property to investigate whether really the call toelementsFromPoint()
is the cause:This code works as expected in that it scans the elements underneath the popup, but the exact same performance issues as with the original version occur, suggesting there might be another underlying cause for the freezing.
Has anyone experienced similar issues or any ideas as to what is causing this problem?
The text was updated successfully, but these errors were encountered: