GoogleEarthPlugin always on top of widgets in Chrome and IE 9

[jpappalardo]

SmartClient Version: v9.1p_2014-04-28/EVAL Deployment (expires 2014.06.27_11.35.29)

Browsers: FF 28, Chrome, IE 9

Our application embeds the Google Earth Plugin and I have generally been testing in FF without any incident. As I have been working to ensure browser compatability I am finding that in Chrome and IE the Google Earth Plugin exists on top of all other Canvases. Popups end up below the plugin, as well as any windows or dialogs. setUseBackMask(true) does not seem to have any affect, and I am wondering what I can do to remedy this issue?

[Isomorphic]

It seems as if recently browser vendors have been unlearning that it's not OK for content to ignore zIndices and "burn through"..

We would recommend setting hideUsingDisplayNone - see if that corrects it.

[jpappalardo]

This setting has no effect, at least not for the issues of having drop downs render below the plugin along with windows that should be over the plugin, rendering beneath it.

[Isomorphic]

Setting useBackMask to true would be expected to resolve this, at least in Internet Explorer.
The setting would be needed on the thing that is being burned through -- whatever sits above the plugin in the page's z-order.

As a quick test, could you try creating a simple Canvas instance with a background color so it is visible, setting the useBackMask property to true, positioning it so it floats over the plugin and calling "bringToFront" on it.
In Internet explorer, we would expect this to be visible - can you let us know if this works for you?
If so, does the same test succeed or fail in Chrome?

Thanks
Isomorphic Software

[jpappalardo]

I understand now, I had assumed that I would use the back mask on the widget that contained the plugin, not the other way around, is this also true for the drag mask?

[Isomorphic]

Actually no - the setting useDragMask to true basically tells the framework that the thing has the propensity to both burn-through elements being dragged over it, and potentially swallow mouse events, so during dragging we take some precautions against these behaviors (temporarily setting 'useBackMask' to true on the thing being dragged, etc)

So you'd set that flag on the widget containing the plugin itself.

[jpappalardo]

So setUseBackMask on components that render over the plugin does work in IE, however it seems to have no effect in Chrome. We are only required to support IE 9 and FF at this time, but unfortunately the lack of support for dev mode in FF, is making chrome the development browser of choice since break points and exception handling in SuperDevMode is lacking in FF.

[Isomorphic]

Good to hear that it fixes the problem in IE. It makes sense that the useBackMask flag wouldn't fix this in Chrome on reflection - BackMasks are effectively disabled in that browser as we haven't needed them in the past.
We'll take a look at enabling this for Chrome as well and let you know what we find.

Regards
Isomorphic Software

[Isomorphic]

And we've now made the change to ensure the useBackMask flag will actually cause the special backMask logic to be active in Chrome.
Please try the next nightly build - if the problem persists in Chrome we'll take another look

Regards
Isomorphic Software

[Blama]

We are only required to support IE 9 and FF at this time, but unfortunately the lack of support for dev mode in FF, is making chrome the development browser of choice since break points and exception handling in SuperDevMode is lacking in FF.

You could still use FF 24.5 ESR (supported until Oct 2014) or the old FF 26 for development. It might be better than the broken Chrome Dev Mode (see http://forums.smartclient.com/showth...t=8159#aChrome)

Best regards,
Blama

[jpappalardo]

Actually SuperDevMode is preferable given the large quantity of javascript included in our application. It's far easier to debug.

[Blama]

Hi jpappalardo,

sorry, I misinterpreted your post. I though you were using the Dev Mode Plugin in Chrome.

Good to know that Super Dev support in Chrome is better than in FF. Will use that one once I have to stop using FF Dev Mode.

What do you like better? FF Dev Mode or Chrome SuperDev? How do they differ for you regarding speed and ease of use?

Thank you & Best regards,
Blama

[jpappalardo]

With SuperDevMode your code still executes in compiled JavaScript, it just provides Source Maps for debugging. This means that you can break and step through jsni and js code as well as your gwt java sources. Also, SuperDevMode does not compile everytime you reload the page, you have to manually trigger the compile. SuperDevMode does function in FF, however break points tend not to actually halt the application. Hopefully FF dev tools will catch up to chrome in future releases.

The only gotcha is that the SuperDevMode codeserver is http only, so you have to be able to hit your application via http as well, or else the browser will block it due to mixed content.