Re: Mouse grabs

[Matthew Flatt <mflatt@cs.utah.edu>]

Quoting "Robby Findler":
> Matthew writes:
> > Perhaps the solution is to be able to queue an event for the window at
> > a particular (global) location. [...]
> 
> This only seems like one of the pieces of drag and drop. I think that you
> would also need some way to take a global x,y coordinate and map that to a
> window (which might not be in the frontmost frame). [...]

That wouldn't be secure. For example, a program running within DrScheme
could get access to the DrScheme frame. (We want drag-and-drop to work
across different programs, presumably.)

I meant literally a function that takes global location and queues an
event for the window at that location:

 (queue-event-at x-pos y-pos v) => void
 ;; queues some sort of event that delivers v to the window
 ;; at the location (x-pos, y-pos)

Technically, there's a timing issue here: the mouse release event could
have happened a long time ago, and the windows might have moved since.
Too bad.

Thinking further ahead, to a world with proper memory accounting, this
is still too insecure. A program could send DrScheme an arbitrarily
large piece of data, and then the DrScheme eventspace would become the
owner.

So I think the right mechanism will not be to queue an event, but to
directly call a method on the window at the given position.

 (send-window-message x-pos y-pos v) => value
 ;; calls the `on-message' method of the window at (x-pos, y-pos)
 ;;  with the argument `v'. The method is called directly in the current
 ;;  thread. The result of calling the method is the return value.

The default `on-message' would call the window's parent's `on-message'.
The default `on-message' for a top-level window would ignore the
argument and return #f.

Programmers who choose to override `on-message' would have to take care
to recognize the threading and security issues. Note that there's no
way for a program to do something bad to another program that doesn't
override `on-message'.

Matthew