> Looking through the release notes, its clear the FF people messed
> around with the drag-drop routines again.
...
> ondragover="event.stopPropagation(); event.preventDefault();"
> ondrop="event.stopPropagation();event.preventDefault();config.macros.fileDrop.dragDropHandler(event);"
>
> That "ondragover" clause appears to be necessary now.
The current plugin code includes event listeners for 'dragdrop' and
'drop':
window.addEventListener('dragdrop', // FireFox3.1-
config.macros.fileDrop.dragDropHandler, true);
window.addEventListener('drop', // FireFox3.5+
config.macros.fileDrop.dragDropHandler, true);
Also, the existing dragDropHandler(...) already invokes
stopPropagation() and preventDefault(). Thus, I'm fairly certain that
the ondrop="..." clause you added to the <body> element is *not*
needed.
However, it would appear that, based on your research, an 'dragover'
event listener is needed:
window.addEventListener('dragover', // FireFox3.6+
function(e){e.stopPropagation();e.preventDefault();}, true);
You should be able to test this yourself, using an *unmodified* TW
core. Just place the above into a new tiddler, tagged with
'systemConfig'. Then save and reload. During startup, the new event
listener will be added, without having to directly edit the <body>
element definition in the source.
> backwards compatibility. This is making me wonder whether its smart to
> be crafting a document management system based on underlying
> technology that is so volatile.
I agree that it seems the FF people are moving forward without
worrying about backward support for existing pages. However, I think
you are overstating the problem with regard to TW: nearly all
functions in TW are cross-platform compatible, or have well defined
platform-specific alternative implementations (when possible).
Regrettably, some browser implementations are non-standard or
incomplete. Nonetheless, TW can operate with a reasonable degree of
success on FF, IE, Opera, Safari, and Chrome, as well as other webkit-
based browsers.
It's very similar to the issues surrounding building applications for
different OS's. Most of the source code in an application is
typically OS-neutral, except for a few isolated modules that have
platform-specific code. Unfortunately, when the code relies on OS-
specific features, it can create extra work when the OS is upgraded,
if those features have changed.
Of course, it would be much better if all browsers followed the same
programming interface and architecture, and it would be nice if OS and
browser developers had a stronger 'backward compatibility' emphasis...
but that's simply not gonna happen any time soon.
-e
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
