-
Notifications
You must be signed in to change notification settings - Fork 21
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
AG-13363 Long-Tap iOS Safari #3442
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
7258614
AG-13363 Set -webkit-user-select: none in CSS
olegat c078ca2
AG-13363 Initial PoC longtap implementation for iOS Safari
olegat 6a52dc2
AG-13363 Set clientXY of synthetic contextmenu event
olegat a02e98e
AG-13363 Do not interrupt longtaps for touchmoves < 10px
olegat 1522f62
AG-13363 Enable iOS long-taps on legend items
olegat 68ddfcc
AG-13363 Remove console.log calls
olegat 70b4ba6
AG-13363 CR nit: add _MS suffix
olegat 8ffca07
AG-13363 CR nit: add _PXPX suffix
olegat File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the cases where
longTapInterrupted
is set totrue
, could you cancel thesetTimeout()
viaclearTimeout()
so that we don't have dangling JS variable contexts hanging around?It would also be good if we could clear these up on
chart.destroy()
too, otherwise the callback could happen after chart destruction, with inevitable errors - also references in the callback context can prevent garbage collection?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you clarify how we would end up with a dangling reference? I don't mind using
clearTimeout()
, but I cannot see how that improves memory safety. Without aclearTimeout()
, thesetTimeout()
will eventually call then remove the function, which would in turn make its variable context eligible for garbage collection.The callbacks will not cause errors because we always remove the listeners on
chart.destroy()
(seeWidgetListenerInternal.destroy()
). So these callbacks will, at worst, loop through an undefined or empty array of listeners.Calling
chart.destroy()
whilst a finger is being dragged on that chart can indeed delay garbage collection until after the finger is lifted. Removing the listeners onchart.destroy()
isn't necessary, but it would stop this delay. However, the challenge is that these are global callbacks shared amongst all chart instances, we must be cautious to ensure that destroying one chart doesn't interrupt another chart that's currently being dragged.We could perhaps refactor the
startMouseDrag
andstartOneFingerTouch
to be temporary member objects ofWidgetListenerInternal
to manage the memory better. But the way I see it there's very little gain in doing that: there's only one mouse & touch device in thewindow
and therefore there's only ever one drag motion in progress. So we can safely manage the memory regardless of whether or not the chart gets destroyed.Are you referring to
that.globalTouchDragCallbacks
? If yes, that variable is used correctly AFAIK. It sets toundefined
either in thetouchend
handler (called on 'touchstart', 'touchend' or 'touchcancel') or in theWidgetListenerInternal.destroy()
method (called bychart.destroy()
).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed on slack: I've tested the spark-line use case and didn't notice anything alarming.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See follow-up #3446 (currently untested)