========================================================================
http://mondrian.corp.google.com/file/11167428///depot/googleclient/gears/opensource/gears/desktop/drag_and_drop_utils_ff.cc?a=1
File
//depot/googleclient/gears/opensource/gears/desktop/drag_and_drop_utils_ff.cc
(snapshot 1)
------------------------------------
Line 334: // TODO(nigeltao): Should we early exit for
DRAG_AND_DROP_EVENT_DRAGLEAVE
On 8:19 pm, 17 May, noel wrote:
> This comment can maybe go? Unless we still have concerns about FF on OSX?
aka
> GetDragAndDropEventType() does all the hard work we need now, right?
This comment is not about FF/Mac. This is about what we can do on Safari --
whether we can distinguish between dragenters/dragovers and dragleaves. If not,
then the other browsers might have to match Safari (i.e. lowest common
denominator). More below...
------------------------------------
Line 353: // TODO(nigeltao): cache the filenames (and their MIME types,
extensions,
On 8:25 pm, 17 May, noel wrote:
> This comment needs some love, speed < one minute on it.
Comment removed entirely.
------------------------------------
Line 447: if (NS_FAILED(nr)) { success = false; break; }
On 8:21 pm, 17 May, noel wrote:
> Just noticed, no check for a directory here, no link following, etc ...
TODO added -- actually changing the behavior is out of scope of this CL. Also,
note that symlinks on Linux will Just Work -- they don't need special handling
(as opposed to .lnk files on Windows).
------------------------------------
Line 548: if (type == DRAG_AND_DROP_EVENT_DRAGLEAVE) {
On 8:22 pm, 17 May, noel wrote:
> We can remove this DRAG_AND_DROP_EVENT_DRAGLEAVE check now, and hence be
> consistent with the other drivers?
...continuing from above. I think we can actually take this out (i.e. that
Safari is good wrt this), but I also think that that should be a separate CL.
This CL doesn't affect behavior (from the JavaScript's point of view), it merely
improves performance by caching. Taking out the dragleave check would change
behavior.
------------------------------------
Line 603: continue;
On 8:23 pm, 17 May, noel wrote:
> early out here, "return false;" ?
TODO added. This CL does not aim to change behavior.
------------------------------------
Line 630:
module_environment->drop_target_interceptor_->SetCachedMetaDataIsValid(true);
On 8:24 pm, 17 May, noel wrote:
> The GetFileDragAndDropMetaData() call @628 also sets the meta data state valid
> state internally. SetCachedMetaDataIsValid() subsequently forces the meta
data
> state valid to true. Why?
Not true. GetFileDragAndDropMetaData sets the meta data state valid *only on
IE*, sincce the two-arg version of AddFileDragAndDropData is only implemented on
IE. Look for the #ifdef in DropTargetInterceptor::GetFileDragAndDropMetaData in
d_a_d_u_win32.cc.
========================================================================
--
To respond, reply to this email or visit
http://mondrian.corp.google.com/11167428
