Closed
Bug 1928758
Opened 1 year ago
Closed 1 year ago
Event retargeting should not reposition the event if the target frame has not changed
Categories
(Core :: Panning and Zooming, defect, P3)
Core
Panning and Zooming
Tracking
()
RESOLVED
FIXED
135 Branch
| Tracking | Status | |
|---|---|---|
| firefox135 | --- | fixed |
People
(Reporter: botond, Assigned: botond)
References
Details
Attachments
(1 file)
Noticed this while helping Alex investigate bug 1914368.
Our event retargeting code can potentially change the target frame of an event from an initial target computed here to a final target computed here.
Since the target frame may have chaged, the event's position (mRefPoint) is also recomputed, which happens here.
(Bug 1914368 seems to be caused by a bug in this recomputation.)
If the target frame did not actually change, the work done to recompute the event position is unnecessary, and could be skipped.
| Assignee | ||
Comment 1•1 year ago
|
||
The repositioning should be a no-op in such cases.
Updated•1 year ago
|
Assignee: nobody → botond
Status: NEW → ASSIGNED
Pushed by bballo@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a44e14892924
Avoid repositioning event if its target has not changed. r=ajakobi
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
status-firefox135:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 135 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•