using vaadin-xs to embed app miscalculates offsets

I’m trying to use Vaadin-XS to embed my vaadin application into a standard web app. I’ve gotten it working, but I noticed for all tooltips and popups the offset is incorrect. When I mouse over a component the tooltip will show up significantly further down the page and to the right than it should be – its so incorrect its usually not even close to the component that it is a tooltip for. Similarly, the drop shadow that is shown behind the tooltip is incorrectly offset from the tooltip by what appears to be the same amount, this results in having a drop shadow that’s not under the tooltip, but is effectively just a semi-translucent black box hovering in the middle of the application which is not acceptable.

I use the context menu addon to add right click menus to other components and it exhibits the same behavior wrt to incorrect placement for both the menu and its drop shadow. But because I have that code in my application, I was able to mess around with it a bit to see if I could come up with a theory.

What I’m seeing is that the positioning on click events its responding to are incorrect. The getClientX and getClientY methods on LayoutEvents.LayoutClickEvent, which are what is used to determine the x,y position to show the context menu, return values for x & y which are not correct so its somewhere below my code that things have gone awry.

I presume that the math for calculating the x,y based on the browser moues events is off; in non-embedded mode, they’re obviously always offset from the origin, but when its embedded, that is no longer the case and it appears this is not handled correctly.

Interestingly, they’re not off by the same absolute amount the application is offset by.

Any thoughts on how this could be resolved?

At a minimum, what controls the drop shadows? I can disable toolips, and I can control the popup menu display locations, but the drop shadow on the menu will be wrong and I can’t see where that is handled.



PS. XS devs, I posted a fix to a bug in the XSApplicationServlet in an earlier thread that you may want to grab.


Tooltips work just fine for me. There is probably something in your host page or environment that makes it bug. What browser are you using? What does the host page html source look like? How is it hosted?


I can reproduce this behavior on FF4, FF 3.5.5, Safari 5.0.4, and Chrome 10 on OSX and with IE8 and FF4 on Win7.

The web app is served by Jetty, the Vaadin application from Resin 3.1.10. I’m using Vaadin 6.5.0 and the Vaadin-XS code was checked out of SVN earlier this week and GWT 2.1.1.

If i remove all the content from the web page hosting the vaadin app, and simply embed the application – so it is placed in the top left corner of the page – I still get the behavior, this is the code in that case.

<div style="height:215px">
<script type="text/javascript" src="http://localhost:8080/pelorus-web2/getEmbedJs"></script>

I’m wrapping in a div because otherwise in embedded mode the application has zero height, which also seems like a bug.

I’m not sure how its hosted or the web page itself could cause the calculation x,y coordinates for mouse events to be incorrect, but I can reliably reproduce this on multiple browsers across different OS’s.




I still couldn’t reproduce the issue. I would have guessed it is the quirks mode (you seem to have no doc type declaration in your host page), but I even worked with in quirksmode for me. I’m afraid you’ll need to provide a full test case for the issue, otherwise I can’t help you much. Maybe there is something in your theme (or in some addon’s stylesheets) that messes things up. You should start with a clean environment (just vaadin, vaadin xs and a simple host page). Then if that works correctly, start removing parts one by one of your problematic application and see what is causing the issue.


What parts of the Vaadin codebase control this?

I think I’ll start fiddling with the core code to see what it thinks the offsets are to try and get a better picture of what is going on.

Also what’s the best way of debugging in this situation?

The debug window doesnt show up in embedded mode, and System.out/err prints or VConsole.log doesn’t send anything to the actual console, which is making this a pain to debug.

I’ll drop down to alert boxes if I have to, but I was hoping there was a better way.



I’ve been digging into this via a flurry of alert dialogs, this is what I have, hopefully one of the vaadin folks can help me understand what this means

I have an empty web page that consists of just the html and body elements, the only thing in the body element is the script tag to embed the vaadin app. the first visible pixels of my app appear at 8,8 for some reason – its not really clear what that’s from, perhaps some combination of margins and borders in the components.

In any case, I have a clear spot on the application at approximately 35,20 from the ORIGIN of the page, ie 0,0.

I mouse to this and pause to trigger the tooltip for the component. An alert tells me that the mouse event was at 32,21 – pretty close to what I was aiming for, and about what i expected.

The next alert is tells me the tooltip will show up at 42,31, which is exactly what I expected given the code in VTooltip offsets the mouse event by 10,10 for the tooltip location. This in turn calls setPopupPosition, which is passed into VOverlay, again the alert shows me 42,31.

At this point, these coordinates go into the gwt PopupPanel. Looking at their code, they just set the attributes on the popup, which seems about right, the tooltip is in the general location i would expect.

Next, updateShadowPositionSizeAndPosition is called. The Document.get().getBodyOffsetLeft/Top are both 0 according to the next alert. The alert following that specifies that the absolute top and left of the overlay are 50,39.

I would have expected this to be 42,31 – but its off by exactly the offset of whatever the 8,8 border/margin/cushion that my app is offset by.

What are those measuring? Why do they seem to be calculated from the app’s 0,0 rather than the window’s 0,0 – everything else along the chain of events is using absolute positioning from the origin of the page. The fact that these coordinates come from getAbsoluteTop/Left I would expect them to also use the page coordinates rather than app coordinates.

Where is that calculated? Is there a place I can find out the app origin and try un-offsetting the drop shadow by that amount in order to correct the offsets?

Any slight you can shed on this is very much appreciated.



A quick smoketest: you do have a doctype specified for your test page? I’m not totally sure if that affects the issue, but at least it won’t hurt to specify <!doctype html> as the first line in your HTML page.

No, that did not seem to affect anything either.

If I go directly to the vaadin app rather than embedding it in the empty page, the offsets are all correctly calculated, so it seems like something is set (or is not set) that is affecting the calculation, I’m just not sure what that could be since I dont know the Vaadin code very well.

I don’t know whether this is the culprit or not, but I think the initialization order for the embedded app must be incorrect, and that’s the root of the issues.

I had noticed that the only way to get the application to display in embedded mode was to wrap the script call to getEmbedJs in a div and style it with a specific height. If I did not do this, every single component in the entire application is set to height zero. I also observed (looking at the live DOM in Chrome’s developer console) that a number of things that are normally set offscreen, usually by setting ‘top’ to a value that is off the visible page – these are probably the tooltip overlays and such – were not correctly positioned, they were always set at the origin of the page.

So I think the scripts are processed in a order which is not the expected ordering for a normal invocation of the application – or the bootstrap creation of the app in the XAApplicationServlet is still incomplete and does not call something such that the app is correct initialized.

This may explain why the sizes and positions are incorrectly calculated and/or not set at all, and that it only happens in embedded mode.

Vaadin devs have any thoughts?



Hi Michael,

I bet it would be most efficient for both you and I if you could provide me a test application that I can deploy locally. I can then reduce the issue quickly and see if there is something we can do about it. I’d really appreciate your test app as we plan to release the first public version of Vaadin XS soon.

So there are two things I’d need (either here on forum or firstname.lastname @ vaadin dot com):

  • war archive of the Vaadin app (preferably with sources)
  • the host page with its resources (css ets). Safari web archive would also work fine here.

Thanks in advance and thanks for your input so far. I don’t know any other remaining issues. Once we get this released I’ll give you one free Vaadin XS license (Apache 2) for free :slight_smile:


The issue was position:relative (on the body) (combined with margins/offsets), which is some problematic css. Not really noticeable until the app is embedded and has non zero margins/offsets from the origin.

Removed postion:relative and the mouse positions are correct.




We had to fix the issue to 6.6 branch. It is not a nice hack at all but for some weird reason also Liferay (our partner) makes body element relative for IE :frowning: