softmoonwebware / mastercolorpicker Goto Github PK

The Picker class was originally developed to work with MSIE6, and the fact that, back then, event-handlers would be executed in a random order (when an event occurred) instead of in the order they were registered/attached. Also, the book that taught me JavaScript: "JavaScript - The Definitive Guide" (5th Edition, 1996, by David Flanagan) failed to mention that IE has proprietary "focusin" and "focusout" event types (that bubble, as opposed to "focus" and "blur" events that do not bubble).
In the Picker class, "interface elements" (form elements that are themselves part of the Picker-implementation interface) need to have event-handlers that catch when the user leaves focus of these elements. A complicated "dance" of events happens. The original Picker class used "focus" and "blur" event handlers attached to each and every one of these "interface elements". this worked fine, until the MyPalette interface started building long lists of these "inputs", and that was adding significant overhead behind-the-scenes (which probably would be no problem with today's modern computers), but also was causing a (longer) delay in loading a palette-file into the MyPalette interface.
The new Picker 2.0 class uses "focusin" and "focusout" handlers that are attached to the MyPalette panel and catch all bubbling events from "interface elements" on the panel, instead of multiple individual handlers on each one. No other real changes were made.
Since then, the Picker class randomly (so it seems) fails to work correctly, and without having done extensive testing, I can only assume that event-handlers are not executing in the same order each time. While "tabbing" (using the TAB key) through each interface element on a Picker-panel, occasionally control is passed back to the "color-input" (the Picker data-target that receives the color-text when you choose a color using MasterColorPicker) instead of the next interface element on the panel. A few times, I've seen keyboard focus completely lost, yet the MasterColorPicker fails to "pop-down" (disappear) as it should when not in use.
You will not notice this "pop-down" problem using the desktop-tools (since they never pop-down), but it shows up in the online demo, where the MasterColorPicker project is included in the instructions page. (http://softmoon-webware.com/MasterColorPicker_instructions.php)
Debugging the event-dance requires using the "Log.js" class to auto-group an action's events based on when they happen, or the browser console loads up with a crazy list of event-logs and it became nearly impossible to know when one "action" ends and another starts.
For instance, if you have focus in an "interface element" and press the TAB key (an action), you get the following events (at least) keydown, blur, focus. Clicking anywhere (an action) creates another flurry of events under these circumstances. The keydown handler should recognize a Tab key and inform the following "blur" event that control is being transferred to another interface element, and not to do anything. This is not happening.
At this time, I need to get involved in other projects, and will not be able to address this issue until an unknown future time.