19414 2012-10-09 21:51:17 +0000 Implement finishPropagation() method 2012-10-11 06:17:21 +0000 1 1 1 Unclassified WebAppsWG DOM unspecified PC Windows XP RESOLVED INVALID P2 major --- 1 jab_creations annevk glenn mike www-dom public-webapps-bugzilla oldest_to_newest 75733 0 jab_creations 2012-10-09 21:51:17 +0000 The DOM lacks the ability to finish executing events leaving authors having to guess if an event has finished executing or not. The need for the finishPropagation method can be summarized by the following Gecko bug here... https://bugzilla.mozilla.org/show_bug.cgi?id=768310 In short while working on a rich text editor I discovered that Gecko browsers copy the (X)HTML code of a page selection. In the absence of the ability to convert the selection to plain/text in older browsers I have the caret focused on an invisible textarea where after the event finishes the selection is automatically converted to plain/text. I then had to have JavaScript copy the text and place it where the user expected the text to be copied to. At best I had to use the setTimeout method under the presumption that x-number of milliseconds should be sufficient. By having the finishPropagation method I would instead be able to not guess if an event has finished firing. This would free authors from having to rely on setTimeout which should NOT have to be used so far out of context as work-arounds. It's very important that finishPropagation be implemented for ALL events both triggered by users and those artificially created through document.createEvent. 75739 1 glenn 2012-10-09 22:40:35 +0000 The term "finishPropagation" doesn't occur on that page, and it looks like it's about another topic entirely (initEvent). Did you link the wrong page? 75755 2 jab_creations 2012-10-10 00:08:43 +0000 @Glenn, no I determined the method name some time afterwards. The Gecko bug I mentioned merely fills a large chunk of the story of how I came to determine the need for the finishPropagation method. 75759 3 glenn 2012-10-10 00:43:35 +0000 (That bug is ten pages of comments on my screen, so I don't think it's really a "summary". :) Note that if you just want to run a function from an event listener after all other event handlers for an event have completed, setTimeout(f, 0) is correct. This is guaranteed, with no guesswork involved, because event dispatch happens synchronously; nothing else (such as timers) can happen in the middle. If that's not what you mean, I'd suggest showing a brief code example. 75788 4 jab_creations 2012-10-10 02:56:38 +0000 Compared to nearly a year's worth of work on just a rich editor alone a hundred pages would still be a summary. I neither have the time nor desire to put a test case together. What I have described should make plenty of logical sense and besides this can be tested out on my blog with public comments at jabcreations.com. My point is simple, I shouldn't have to hack my code by using setTimeout when it's very clear that finishPropagation is what should be used, that's a clear conflict of the context in which it is used for. In fact I'm absolutely astonished and dumbfounded that finishPropagation was not in DOM Level 1 for goodness sakes. The fact that you even THOUGHT to suggest using setTimeout as an acceptable route should stop you immediately in your tracks. I'm not telling the computer to wait, I'm telling the computer to finish executing an event, those are completely different contexts. Even if I was told finishPropagation was slower than setTimeout I would still use finishPropagation instead because it is crystal clear that is what it is intended for. Using setTimeout is a clearly undeniable hack used to get around the limitation of the DOM and when ambiguities start to arise the specification can either clarify by doing what is right or sit back and watch sites begin implementing hacks leaving bad examples of code to live on for years while simultaneously misguiding people who are learning when they come across it. 75792 5 glenn 2012-10-10 04:26:14 +0000 It's not a hack or a workaround at all; it's a common paradigm in every event-based system to queue tasks, and in the Web platform setTimeout is how you do it. If you want it to run as soon as possible when the current task completes, you set the timeout to 0. It's simple and clean, and it doesn't care whether you're running from an event handler, a timer, a generic callback, or anything else: it works everywhere consistently. I'll point out that what you're saying is a moving target: you started by saying that there's "guessing" and "presumption", and after explaining that there's no guesswork and that setTimeout is guaranteed to work, you started saying something else. Beyond that, I'm not spending more time on this ticket; I'll leave it to others. 75810 6 annevk 2012-10-10 10:10:16 +0000 John, I read through that bug and it suggests you were using initEvent() inappropriately and should instead have used stopPropagation() and friends. As Aryeh mentions in this bug setTimeout(0, ...) is indeed the preferred way to queue something you want to have executed. I'm not sure there's anything for me to do here. If you think there is something to be done, maybe an example (in code) of what you are trying to accomplish and how your proposed method would make that easier could help me understand what we are talking about here as the bug did not. 75903 7 jab_creations 2012-10-10 23:37:04 +0000 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. 75929 8 annevk 2012-10-11 03:48:36 +0000 So why not use event.stopPropagation() if you want the event to stop being dispatched? Or event.stopImmediatePropagation() if you want it not to reach any other listeners either? 75932 9 jab_creations 2012-10-11 04:04:11 +0000 The user triggers the event when they paste content, why would I stop the event from pasting the content inside of the textarea? That makes absolutely no sense! I *WANT* the paste event to trigger in the textarea after I have given it focus so that I can take the text (that now no longer is (X)HTML) so I can put it in to the contenteditable element where the user intended. The whole point is to prevent someone from going to a highly inappropriate site, selecting large portion or even the entire page in Firefox and then easily posting it with the rich text editor. Stopping the event and finishing the event are two completely opposite things. 75933 10 annevk 2012-10-11 04:12:14 +0000 It sounds like you do not know what event.stopPropagation() actually does. It is very different from event.preventDefault(). 75937 11 1222 jab_creations 2012-10-11 05:58:48 +0000 Created attachment 1222 Example of how stopPropagation is not what is needed. Again stopPropagation is not the answer. In this very simple test case I alert the value of the textarea. Because there is no correct way to tell the browser to FINISH the event there is nothing I can alert. This means that without the setTimeout *HACK* I can not retrieve the filtered paste value from the textarea properly to put it back in to the editing element. 75939 12 annevk 2012-10-11 06:17:21 +0000 Well yeah, as far as I can tell that's because paste is not synchronous but rather queues a task to insert the data. So either you get the data from the clipboard (if that's supported already, not sure about the details here) and prevent the default action of the user operation, or you queue a task yourself (indeed, using setTimeout()). There is nothing really we could introduce for this kind of thing like you proposed since pasting is apparently asynchronous (afaict). 1222 2012-10-11 05:58:48 +0000 2012-10-11 05:58:48 +0000 Example of how stopPropagation is not what is needed. finishPropagation.xhtml application/xhtml+xml 785 jab_creations 77u/PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhRE9DVFlQRSBodG1s IFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4xLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RS L3hodG1sMTEvRFREL3hodG1sMTEuZHRkIj4NCjxodG1sIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy8xOTk5L3hodG1sIiB4bWw6bGFuZz0iZW4iPg0KPGhlYWQ+DQo8c2NyaXB0IHR5cGU9ImFwcGxp Y2F0aW9uL2phdmFzY3JpcHQiPg0KLy88IVtDREFUQVsNCmZ1bmN0aW9uIHBhc3RlcihlKQ0Kew0K IGRvY3VtZW50LmdldEVsZW1lbnRCeUlkKCdwYXN0ZV9oZXJlJykuZm9jdXMoKTsNCiBlLnN0b3BQ cm9wYWdhdGlvbigpOw0KIGFsZXJ0KCdQYXN0ZWQgY29udGVudCBzaG91bGQgYXBwZWFyIGluIHNl Y29uZCBsaW5lIGlmIHN1Y2Nlc3NmdWwuXG5cbicrZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3Bh c3RlX2hlcmUnKS52YWx1ZSk7DQp9DQoNCndpbmRvdy5vbmxvYWQgPSBmdW5jdGlvbigpDQp7DQog ZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ3Rlc3QxJykuYWRkRXZlbnRMaXN0ZW5lcigncGFzdGUn LCBmdW5jdGlvbihlKSB7cGFzdGVyKGUpfSxmYWxzZSk7DQp9DQovL11dPg0KPC9zY3JpcHQ+DQo8 L2hlYWQ+DQoNCjxib2R5Pg0KDQo8ZGl2IGNvbnRlbnRlZGl0YWJsZT0idHJ1ZSIgaWQ9InRlc3Qx Ij48cD5QYXN0ZSB0ZXh0IG9yIChYKUhUTUwgaGVyZS48L3A+PC9kaXY+DQo8dGV4dGFyZWEgaWQ9 InBhc3RlX2hlcmUiPjwvdGV4dGFyZWE+DQoNCjwvYm9keT4NCjwvaHRtbD4=