We are trying to develop a Vaadin app which would serve as an add-on to other, non-Vaadin websites. Our part, developed as
Vaadin embedded in a div , would most of the time be hidden (display:none).
We already ran into two major problems with this approach. One was when we discovered that Vaadin’s ApplicationConnection checks whether CSS has been loaded by
checking if the “offset height” of the loading indicator is other than 0 (isCSSLoaded() method). When the entire UI is hidden, that value remains 0 even after CSS has been loaded. Vaadin then
waits 100 x 50ms before giving up on this check and proceeding with other initialization. We plan to circumvent this by minimizing our embedded div to 1px by 1px and hiding it only after the CSS check is done.
The other problem was that we didn’t want any system messages (“communication problem”, “cookies disabled”) to be shown to the user, since our UI was mostly hidden. We had to go around it via CSS - no way to turn them off by a configuration switch in code.
However, these issues lead us to wonder if we’re likely to encounter further major problems. Based on our experience so far, it seems this is a use case that Vaadin was not designed to handle. Should we therefore look into another solution, or perhaps we just happened to stumble upon these two issues, but the road ahead will likely be more smooth?
The symptoms look to me that the “theme” (basically a css file) used by your Vaadin application isn’t loaded propertly. Check out that you refer to it correctly e.g. with your browsers debugging tools (right click + inspect element in Chrome/Safari).
I think this is a very common way to use Vaadin applications, so I think its a shame the configuration is this tricky and error prone. In Vaadin 6 era apps I used couple of times a really handy helper called Vaadin XS, that lets you do the embedding even from other server, with just once javascript inclusion. I really hope are R&D would make this reality for Vaadin 7 as well soon. Related to this, the recent
CORS setup tutorial might help you to solve your case as well.
Many thanks for a prompt response! Regarding the CSS file being loaded, I assume you mean “styles.css” compiled from our custom .scss template, into which we happen to import valo. As far as I can tell, this loads correctly - it is available to look at in various browser developer tools, and styles from there do get applied.
I think the key difference for us, which triggers all these problems, is not that we’re embedding a Vaadin UI, but that our embedded UI is meant to be
hidden , at the beginning and most of the time afterwards. Both the issues we encountered seem to stem from the Vaadin assumption that the UI is
visible all the time.
Do you think this is the right diagnosis and we may have more problems in the future?
Regarding CORS, thank you for the pointers. We did initially use the tutorial setup in fact! That said, I’m afraid it didn’t seem to work for GET requests, such as fonts, so we switched to a general Tomcat CorsFilter. We actually wondered why the code explicitly only added CORS headers for “options” and “post” requests, with a comment that “All the other requests nothing to do with CORS”.
Ah, so you are using display:none for the Vaadin div? That probably just breaks the hack that tryis to detect the theme loading state. With modern browsers we should propably come up with another solution for that. Maybe you could try hiding with “height:0; overflow:hidden;” instead? This is just a guess, but I think that might work with the detection.
I think if you can make the loading detection work, it should be just fine to keep the Vaadin UI hidden.
Regarding, CORS headers, I think that my collegues Sami just went with Chrome or Safari. IIRC they are not that picky with cors headers for font, but I know FF at least is very picky with them aswell.
