API change RT-19955: Configuring a PopupWindow so that it consumes the event used for hiding

[Lubomir Nerad]

On 5/10/2012 4:18 PM, Richard Bair wrote:
> (a) Do we add consumeAutoHidingEvents? Yes, +1
> (b) Do we use a different name? I don't mind, but some other ideas:
>          forwardEventsCausingAutoHide
>          consumeEventsCausingAutoHide
>
> They are long though!
>

Unless somebody objects, I'll go with (a) then.

> (c) Do we change the default behavior? I'm not sure. Sometimes apps want one, sometimes the other. I would be tempted to remain compatible and not change the default behavior. What do you think?
>

I still think that consuming auto hiding events is a better default. But 
probably not that better to cause some incompatibility problems. Eric, 
would you mind if we don't change the default?

> Richard
>

Thanks,
Lubo

> On May 10, 2012, at 4:27 AM, Lubomir Nerad<lubomir.nerad at oracle.com>  wrote:
>
>> Yes. It seems that in Safari popups invoked from toolbars have different behavior than popups invoked from dialogs.
>>
>> On 5/10/2012 2:10 AM, Richard Bair wrote:
>>> I tried the download pop up, and then clicking something outside the download popup. Do you see the same?
>>>
>>> On May 9, 2012, at 4:36 AM, Lubomir Nerad<lubomir.nerad at oracle.com>   wrote:
>>>
>>>> On 5/7/2012 10:43 PM, Richard Bair wrote:
>>>>>>> Hi Lubo,
>>>>>>>
>>>>>>> why do you think that the name is ambiguous? Seems clear to me. Some
>>>>>>> other thoughts:
>>>>>> I don't remember how exactly the auto-hide feature for popups is implemented. Is it sometimes triggered from Glass ("ungrab" event)? What event will be consumed in this case?
>>>>>>
>>>>>> Are we confident we'll be able to implement this property? If a popup is auto-hidden from the ungrab event handler, there may be no direct connection between this event and the mouse/key/etc. event to consume.
>>>>> Before approving the API addition I guess we need to know the answer to this. Likewise, the default behavior I think is platform specific. At least in Safari, it seems that it does not consume mouse events by default that cause the popup to be closed. However I know Cocoa has an API for specifying what this behavior should be. If we add such an API, we probably will want to make sure it defaults to some platform specific value rather than always defaulting to "true" or "false"?
>>>>>
>>>> The property only aims at controlling the events between the popup and its parent window. Ungrab events and possible mouse clicks which caused them (outside of the popup window and its parent window) can't be influenced in general (and probably shouldn't be).
>>>>
>>>> In Safari, it seems to me that the events are actually consumed. If you invoke preferences and in one tab page expand a combo box, then click on an another control in the same tab page, the function of that other control is not executed. Only if the interaction involves multiple windows, I can see that the event is not consumed. With the property we will control this behavior among controls / popups of a single window, while leaving the behavior between multiple windows OS dependent.
>>>>
>>>> Thanks,
>>>> Lubo
>>>>
>>>>
>>>>
>>>>