========================================================================
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 10:24 am, nigeltao wrote:
> 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...
OK.
------------------------------------
Line 353: // TODO(nigeltao): cache the filenames (and their MIME types,
extensions,
On 10:14 am, nigeltao wrote:
> On 8:25 pm, 17 May, noel wrote:
> > This comment needs some love, speed < one minute on it.
>
> Comment removed entirely.
OK.
------------------------------------
Line 447: if (NS_FAILED(nr)) { success = false; break; }
On 10:20 am, nigeltao wrote:
> 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).
OK, I see the TODO.
------------------------------------
Line 548: if (type == DRAG_AND_DROP_EVENT_DRAGLEAVE) {
On 10:24 am, nigeltao wrote:
> 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.
OK. Separate CL is fine.
------------------------------------
Line 603: continue;
On 10:26 am, nigeltao wrote:
> On 8:23 pm, 17 May, noel wrote:
> > early out here, "return false;" ?
>
> TODO added. This CL does not aim to change behavior.
OK
------------------------------------
Line 630:
module_environment->drop_target_interceptor_->SetCachedMetaDataIsValid(true);
> 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.
Yes I see this now for FF. THe thing I trying to get to was that IE doesn't
seem to call SetCachedMetaDataIsValid(true). That leads to a problem for IE if
it's call to GetFileDragAndDropMetaData() set the meta data state valid to false
(re-scanning on every event).
========================================================================
--
To respond, reply to this email or visit
http://mondrian.corp.google.com/11167428
