- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Oct 2012 23:37:04 +0000
- To: public-webapps-bugzilla@w3.org
- Message-ID: <bug-19414-2532-CJx2QIAALX@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19414 --- Comment #7 from John A. Bilicki III <jab_creations@yahoo.com> --- This is a joke right? No spare tire, a doughnut is round so use a doughnut right? The setTimeout method has nothing to do with events. [event] [setTimeout] [setTimeout] -> [something unrelated to event waits for event to expire] [event] [finishPropagation] Anne, why would I want to use stopPropagation to stop an event when I'm trying to have it FINISH firing the event?! [event] [focus() textarea] [finishPropagation] [copy .value from textarea] [update nodes in relevant portion of rich editor] Just use Firefox and then create a contenteditable element... <div contenteditable="true"></div> ...and then either use the onpaste event or capture e.ctrl and the v key's keyCode and then give focus to a textarea. Without using setTimeout fire the event. You CAN'T fire the event, the event is stuck waiting on the code. No, we DON'T want to stop the event because we're under the presumption that we do NOT have access to the clipboard. The event MUST be fired AFTER focus is given to the textarea to convert the pasted content to text/plain. Then AFTER the event has fired thanks to finishPropagation use scripting to move the textarea's .value and determine where the user intended to paste the content in to the contenteditable element. This is not a difficult concept by any means. We should NOT be hacking a language and using things out of far out of their context because over a decade ago people thought of FOUR different ways to stop an event but not a single way to finish it! There is no logical valid reason to argue against doing what should have been done in DOM Level 1. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 10 October 2012 23:37:06 UTC