Flow: Populate info extracted using JS into WebBrowser

[Legioth]

WebBrowser has code inherited from Vaadin Framework for receiving details such as screen dimensions and time zone information from the client, but the client never sends these when using Flow.

One challenge here is that the data was sent during the "browser details" request that triggered the UI instance to be created and initialized. This means that the data was available already when constructing the initial view.

With Flow, the initial view is constructed already during the first request, i.e. before there has been any opportunity to run any JS for extracting the data. This means that the data wouldn't be available when constructing the initial view, but only when handling events in that view or when constructing that the user subsequently navigates to.

[pleku]

This would need some use case examples (and votes) to be considered.

[Legioth]

One use case is to find the current browser window dimensions: https://stackoverflow.com/questions/51004994/how-to-get-browser-window-width-in-vaadin-10-in-server-side-java-code

[heruan]

I'm facing a use case where I need to display a timestamp in the user's local time-zone, e.g. 2018-06-24T23:00:00 UTC, displayed as:

• 23:00 of June 24th by a viewer in UK
• 01:00 of June 25th by a viewer in Italy

Til now the workaround was to geolocate the user's IP address to get the time zone, but this isn't always accurate; now I'm in the process of porting the conversion on the client side, but for this I need a client-side component with a third-part JS library.

It would be great to be able to get the client timezone directly in Flow or a new Vaadin Component.

[Frettman]

My use case is to display dates and times in the user's time zone. Just as the user's preferred languages (set in the Browser) are already used by Vaadin to pick a sensible default for the locale (from the provided locales), I'd like to pick a sensible default for the user's time zone.

[pleku]

As this has been lately requested (along with #4320 and partly #4312, which can be done separately though), it should be investigated how we can now in the best way overcome the "delay" that we would have for when this information is sent to the server side, while not delaying the UI creation when necessary. Based on also the issue https://github.com/vaadin/flow/issues/3522 (preserving UI state on refresh) which would also require the two-step bootstrap, my current hypothesis is:

• we can add another bootstrap step request from client to server, that can be used _optionally_ for delaying the UI creation and actions when required based on some information that would be gathered from the browser similarly as with the old Framework versions (7 and 8)

For instance we could have an callback have (eg. method override like onAttach on component or listener you register, or annotation on router or something else...) that is triggered only after the second roundtrip has populated the data. So this callback would be called

• after the second roundtrip on initial load of the page / refresh
• immediately for any other attach/detach (since the browser details are already there)

We probably should make it so that this bootstrap request can be removed or postponed so that the data is sent in the next _other request_ that will go to the server.

[pleku]

This issue should be split into more concrete steps before started, and also there needs to be (not immediately) a design for the API for the second bootstrap phase request callback.

[heruan]

Seems like this didn't land in 12, unfortunately. Any idea of a workaround to get the timezone being pushed to the server along with an event from DatePicker and TimePicker?

[heruan]

I tried to make a web component which has the browser infos I need as default properties, and I just found out that default values are not reflected on the Flow's PolymerTemplate instance (which I should expect since that would need an additional server round-trip 🤦‍♂️). I really hope this will be tackled down in 13!

[pleku]

@heruan at the moment, unfortunately this is not in scope for V13 but for V14.

[pleku]

Available on server side with Page.retrieveExtendedClientDetails( ExtendedClientDetailsReceiver receiver) since 2.0.0.beta1.