Closed
Bug 1089553
Opened 9 years ago
Closed 9 years ago
Suppress/Unsuppress the SelectionChangeEvents in form.js
Categories
(Core :: DOM: Selection, defect, P4)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: pchang, Unassigned)
References
(Blocks 1 open bug)
Details
This bug is the follw up bug from bug 1065955 comment 18. (In reply to :Ehsan Akhgari (not reading bugmail, needinfo? me!) from comment #18) > (In reply to peter chang[:pchang][:peter] from comment #17) > > With Bug 1066515, it adds the fast path to resolve original problem but it > > is easy to fall back to original path to hit the low performance problem[1]. > > So, I don't think that was the right approach either. As I said, given that > we *know* that this is a performance problem in that code, we should just > suppress sending the selection events in that code in general. We can > surround that loop with a > suppressSendingSelectionChangeEvents/unsuppressSendingSelectionChangeEvents > calls (hopefully you can think of better function names ;) and in > UpdateState, check a boolean condition based on that.
Reporter | ||
Updated•9 years ago
|
Blocks: CopyPasteLegacy
Comment 1•9 years ago
|
||
Note that if we end up tailoring the selectionchange event only for the copy/paste bubble use case, this problem may go away and we may not need to do anything here.
Reporter | ||
Updated•9 years ago
|
Priority: -- → P3
Comment 2•9 years ago
|
||
Do we still need to do this?
Reporter | ||
Updated•9 years ago
|
Priority: P3 → P4
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to [Away: 1/29-2/20] from comment #2) > Do we still need to do this? Consider this in v3 period.
Comment 4•9 years ago
|
||
The new AccessibleCaret does not fire SelectionChangeEvents. (bug 1172382)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•