Issue 729 was targeted for 1_4_RC but was not fixed will it be fixed in 1_5 ?

[stuckagain]

Sorry to try and grab some attention from the 1.5 commiters but for
me, and I guess I speak for many people just using GWT 1.4,
maintenance is as important if not more than adding new cool features.

This bug was reported on GWT 1.2.22 a long time ago.
http://code.google.com/p/google-web-toolkit/issues/detail?id=729

It was targeted for fixing in 1_4_RC but somehow was not fixed in
1.4.61.

I tried to patch this myself, but I had some trouble setting up
Eclipse on MacOS... and well I don't have much time to contribute
except for reporting bugs and nagging to get them fixed ;-)


Will this be fixed in the upcoming 1.5 release ?


Thanks,
David

[Joel Webber]

This bug is indeed annoying, but in order to get it fixed, someone's going to need to find a good way to deal with the general problem: i.e. event preview over iframes. Popup auto-close depends upon previewing all events, but iframes interfere with this. Does anyone know of a way to capture all events before they go into an iframe? Especially on IE, where I suspect it will be even harder?

joel.

[BobV]

On Mon, Feb 25, 2008 at 7:54 AM, Joel Webber <j...@google.com> wrote:
> This bug is indeed annoying, but in order to get it fixed, someone's going
> to need to find a good way to deal with the general problem: i.e. event
> preview over iframes. Popup auto-close depends upon previewing all events,
> but iframes interfere with this. Does anyone know of a way to capture all
> events before they go into an iframe? Especially on IE, where I suspect it
> will be even harder?

If the iframe were in the same domain as the host page, would it be
feasible to pump the events from the inner iframe into the outer page?
It doesn't solve the problem in the general case, but it seems like
it might solve part of the problem space.

--
Bob Vawter
Google Web Toolkit Team

[stuckagain]

Hi,

I did some experiments, but until now nothing succesful.

1) I tried to make the IFrame generate some events, so that the
Preview mechanism would trigger the menu to close down.
Unfortunately onclick is never called.

2) I've added a Focus Listener and this one gets called when the user
clicks on the IFrame or clicks somewhere else.
But this does not cause the popup menu to go away.

3) I deduced from the previous experiment that the popup menu only
goes away when a onclick is triggered... so I just added an invisble
button to the dom tree and invoked click on it to force a onclick
event. To my regret, it did not do the trick. The ClickListener was
invoked, but somehow it was never handled by the popup menu in the
onEventPreview.

Somebody else posted on the GWT newsgroup about the same issue, a long
time ago. I contacted him and he told me he is no longer using GWT but
is using Javascript and HTML directly. He implemented the menu by
putting an invisible DIV over the IFrame in order to detect the click
outside the menu.
Maybe that this could be helpful ?

David

> > David- Hide quoted text -
>
> - Show quoted text -

[Ray Cromwell]

There is a similar issue with plugins, Flash, Applets, Silverlight, Quicktime, etc. On each browser, you can capture some events, but not others. For example, on some browsers, you can trap the context menu and prevent Flash from getting it, but on others you can't. On IE, Flash always eats mouse click events, but not mouse down/mouse up.  I suspect this problem can't be solved without pumping, and each domain will need a specific solution (embedded iframes, embedded Flash, embedded Quicktime/WMV, embedded PDF, etc)

-Ray

[Joel Webber]

I think Ray's intuition on this one is right. AFAIK, there is just no good way to do this in the general case, at least not using the 'event preview' semantics.

The only alternative I've heard that sounds remotely feasible would be something more like the "GlassPanel" trick, where you cover the whole page in an invisible (or translucent) element that catches the events. It might be possible to change PopupPanel to do something like this. My biggest concern, though, would be that it might perform horribly for things like MenuBar -- if there were a full-page transparent div for every cascaded menu, things could get ugly.

Has anyone ever experimented with this? Is it feasible across browsers (in particular, is it possible to make one *completely* transparent and still catch mouse events on all browsers)?

joel.

[Ray Cromwell]

I tried it awhile ago with Flash and it didn't work (on IE). In Chronoscope, I encountered the problem that I could capture mousedown/mouseup/mousedrag and mousewheel, but unbelievably, can't capture mouseclick (left or right). I'm using flash with wmode=transparent so it avoids the 'always on top' behavior, nevertheless, putting a glass panel  DIV on top of the OBJECT element does not prevent Flash from stealing events.  On Safari and Opera, everything works but contextmenu (Flash built in menu still pops up)

This leads me to believe that there is an implementation specific issue with how the browser integrates these heavyweight UI components into its container and pumps events to them. It may even be influenced by the OS's widget toolkit. It seems that browser plugins have issues akin to the old AWT/Swing Heavyweight/Lightweight problems (hell, Flash is one of the few components to understand the need to obey Z-index, opacity, etc)

I think fixing this bug may be more trouble than it is worth.

-Ray

[stuckagain]

Hi,

I understand the difficulties in finding a general solution.

But lets be a bit more pragmatic:
I do not need a general solution for all browser extensions. I need
one for IFrames.
I can install onblur/onfocus handlers on the IFrame to know when the
user clicked in them.

The only thing that I can not do is somehow make a popup window
disappear. all that would be needed is that I can send an event to the
current EventPreview listeners.

Flash and Applets are not supported by GWT, but IFrames are... and
there some kind of sollution would be nice to have.

David

> > On Tue, Feb 26, 2008 at 11:13 PM, Ray Cromwell <cromwell...@gmail.com>

> > wrote:
>
> > > There is a similar issue with plugins, Flash, Applets, Silverlight,
> > > Quicktime, etc. On each browser, you can capture some events, but not
> > > others. For example, on some browsers, you can trap the context menu and
> > > prevent Flash from getting it, but on others you can't. On IE, Flash always
> > > eats mouse click events, but not mouse down/mouse up.  I suspect this
> > > problem can't be solved without pumping, and each domain will need a
> > > specific solution (embedded iframes, embedded Flash, embedded Quicktime/WMV,
> > > embedded PDF, etc)
>
> > > -Ray
>

> > > On Tue, Feb 26, 2008 at 1:07 AM, stuckagain <david.no...@gmail.com>

> > > > > - Show quoted text -- Hide quoted text -

[Fred Sauer]

Joel,

I needed full screen mouse event (and actually keyboard event) capture when working on Hornet Blast (http://allen-sauer.com/com.allen_sauer.gwt.game.hornetblast.HornetBlast/HornetBlast.html). As I recall a 100% transparent DIV works in all browsers except IE6, in which case you can try to capture events on the body element, or you can make the div have 1% opacity (99% transparency) in the IE6 case. That does effect the color of the page a bit, which might be okay when a popup is being displayed. A single, shared, DIV for all menus and popups might work.

Fred

--
Fred Sauer
fr...@allen-sauer.com

[Joel Webber]

@David: I don't believe we can depend on being able to install event handlers in arbitrary iframes, because of the domain security model (need to confirm this, though). For your particular case, if you were to install handlers yourself, could you simply call PopupPanel.hide()? Or is another widget (e.g. MenuBar) that uses popups keeping you from doing this?

@Fred: I seem to remember people using the transparent div trick (and also IE's recalcitrance in being 'smart' by letting clicks through transparent divs). I'd be a little wary about doing this for all popups though, because it sounds like it could be a speed issue (and unfortunately, IE is the only browser that doesn't implement event capture as well, making it doubly hard). Do you know of *any* way to capture events on IE other than the hack that GWT does (i.e. forwarding all events through a single dispatch() method)?

[stuckagain]

Hi Joel,

In my case the IFrames all originate from the same server, so the
security model should not be in the way. As said before, I installed a
focus listener on the IFrame (the component, not the document inside)
and that one gets fired, sinking onclick does not work in IE6. The
only missing link right now is to get the popup menu/submenus to hide
when I get an onfocus for the IFrame component. Any thoughts on how I
can achieve that ?

I'm having issues with the PopupMenus, as far as I know there is no
public hide() method available ?

David

On Mar 5, 12:14 am, "Joel Webber" <j...@google.com> wrote:
> @David: I don't believe we can depend on being able to install event
> handlers in arbitrary iframes, because of the domain security model (need to
> confirm this, though). For your particular case, if you were to install
> handlers yourself, could you simply call PopupPanel.hide()? Or is another
> widget (e.g. MenuBar) that uses popups keeping you from doing this?
>
> @Fred: I seem to remember people using the transparent div trick (and also
> IE's recalcitrance in being 'smart' by letting clicks through transparent
> divs). I'd be a little wary about doing this for all popups though, because
> it sounds like it could be a speed issue (and unfortunately, IE is the only
> browser that doesn't implement event capture as well, making it doubly
> hard). Do you know of *any* way to capture events on IE other than the hack
> that GWT does (i.e. forwarding all events through a single dispatch()
> method)?
>
>
>
> On Mon, Mar 3, 2008 at 9:58 AM, Fred Sauer <f...@allen-sauer.com> wrote:
> > Joel,
>
> > I needed full screen mouse event (and actually keyboard event) capture
> > when working on Hornet Blast (

> >http://allen-sauer.com/com.allen_sauer.gwt.game.hornetblast.HornetBla...).

> > As I recall a 100% transparent DIV works in all browsers except IE6, in
> > which case you can try to capture events on the body element, or you can
> > make the div have 1% opacity (99% transparency) in the IE6 case. That does
> > effect the color of the page a bit, which might be okay when a popup is
> > being displayed. A single, shared, DIV for all menus and popups might work.
>
> > Fred
>
> > On Thu, Feb 28, 2008 at 9:29 AM, Joel Webber <j...@google.com> wrote:
>
> > > I think Ray's intuition on this one is right. AFAIK, there is just no
> > > good way to do this in the general case, at least not using the 'event
> > > preview' semantics.
> > > The only alternative I've heard that sounds remotely feasible would be
> > > something more like the "GlassPanel" trick, where you cover the whole page
> > > in an invisible (or translucent) element that catches the events. It might
> > > be possible to change PopupPanel to do something like this. My biggest
> > > concern, though, would be that it might perform horribly for things like
> > > MenuBar -- if there were a full-page transparent div for every cascaded
> > > menu, things could get ugly.
>
> > > Has anyone ever experimented with this? Is it feasible across browsers
> > > (in particular, is it possible to make one *completely* transparent and
> > > still catch mouse events on all browsers)?
>
> > > joel.
>

> > > On Tue, Feb 26, 2008 at 11:13 PM, Ray Cromwell <cromwell...@gmail.com>

> > > wrote:
>
> > > > There is a similar issue with plugins, Flash, Applets, Silverlight,
> > > > Quicktime, etc. On each browser, you can capture some events, but not
> > > > others. For example, on some browsers, you can trap the context menu and
> > > > prevent Flash from getting it, but on others you can't. On IE, Flash always
> > > > eats mouse click events, but not mouse down/mouse up.  I suspect this
> > > > problem can't be solved without pumping, and each domain will need a
> > > > specific solution (embedded iframes, embedded Flash, embedded Quicktime/WMV,
> > > > embedded PDF, etc)
>
> > > > -Ray
>

> > > > On Tue, Feb 26, 2008 at 1:07 AM, stuckagain <david.no...@gmail.com>

> > f...@allen-sauer.com- Hide quoted text -

[Joel Webber]

It sounds like what you need is to be able to call MenuBar.close(), which is currently private. If this would do the trick for you, could you enter an issue for it to be made public (we'll probably have to refactor the code a little to make sure all cascaded menus close, but that's not a big deal).

You mention that sinking onclick doesn't work on IE6 (I assume you mean on the IFrame). Can you sink onclick on the IFrame's document body? I assumed you'd have to do something like this, which is why I was concerned about cross-domain issues.

joel.

[Ray Cromwell]

  This is probably viewed as an XSS issue by Microsoft. If you could use glasspanes to intercept events in an IFRAME that spans domains, one could phish alot easier, by loading up the real site, and then capturing keys and mouse clicks, while forwarding them to the underlying IFRAME. Perhaps IE has a bug where even if the IFRAME is same domain, clicks can't get sunk.

-Ray

[Ray Cromwell]

BTW, I have a similar issue with Flash on IE6. I can sink every event except left and right click. Yes, even mousedown/mouseup can be sunk, but not click.

-Ray

[stuckagain]

Hi Joel,

Making the close method public would indeed be a workaround, but I
would have preferred a solution where I can just generate onclick
events on the IFrame (even if it is a simulated click when I detect an
onfocus). My assumption is that whatever widgets is currently on the
top of the event preview stack would act correctly on it (a dialog
using autohide would hide, or a popup menu would close again). That
would be something a bit more generic.

That's why I was trying to simulate this by creating an invisible
Button and calling click on it when I got a focus event from the
IFrame. The onfocus happens, the onclick of the Button is also
executed ... but for some reason this event is not handled by the
onPreviewEvent of the MenuBar/Item.

Adding on onclick on the body of the IFrame might be worth
investigating. In my case the domains are the same so cross-domain
security does not apply here. But this is a bit more complicated since
I have to make sure that I install this listener after the document
has loaded. I'll give it a try.

David

> > > - Show quoted text -- Hide quoted text -