Closed
Bug 1071737
Opened 10 years ago
Closed 9 years ago
Tooltip takes over a second to hide with APZ
Categories
(Core :: Panning and Zooming, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: BenWa, Unassigned)
References
Details
Attachments
(1 file)
166.60 KB,
image/gif
|
Details |
STR:
1) Turn on APZ on desktop (Mac)
2) Mouse over an element that will generate a tooltip
3) Start scrolling quickly
Reporter | ||
Updated•10 years ago
|
Blocks: apz-desktop
Comment 1•10 years ago
|
||
We probably want to use the apz state-change notifications to hide the tooltip, similar to how to the text-selection caret now works on b2g.
Comment 2•10 years ago
|
||
Without APZ the tooltip is hidden by the mouseout event on the link that comes from the synthetic mouse move event that's triggered asynchronously from ScrollFrameHelper::ScheduleSyntheticMouseMove() which is called from ScrollFrameHelper::ScrollToImpl.
This should happen just the same with APZ on, but maybe we paint so much after scrolling that the async synthetic mouse move event is delayed for too long.
Comment 3•10 years ago
|
||
This still happens on the latest nightly, but I would consider it a polish item rather than a blocker.
Comment 4•9 years ago
|
||
So with both APZ (nightly) and non-APZ (aurora) on OS X, I see the same behaviour now - the tooltip remains until the user stops scrolling, at which point it disappears. Since this is no longer an APZ regression per se I'm going to close it as WFM. However feel free to reopen if you feel this needs changing.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•