New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Occasionally getting empty page #3893

Closed
avernet opened this Issue Jan 16, 2019 · 7 comments

Comments

Projects
2 participants
@avernet
Copy link
Collaborator

avernet commented Jan 16, 2019

With the following exception showing in the console:

screen shot 2019-01-15 at 3 35 12 pm

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

This is most likely due to #3565 and external scripts. When this is enabled, which is the default, we load dynamic data structures as external scripts. This includes:

  • xformsPageLoadedServer
  • opsXFormsProperties
  • orbeonInitData

In order, things happen like this:

  • load jquery-*.js
  • load more supporting JavaScript files
  • load xforms.js
  • load more XForms JavaScript files
  • load eventually orbeon-form-runner.js
    • completes the initialization of the ORBEON objects
    • registers $() for initializing the XForms processor
  • loads external static XForms functions and data structures
  • loads external dynamic XForms functions and data structures

Now surprisingly enough, it looks like jQuery's $() can fire before defered scripts! Very surprising, as it was meant to be a better DOMContentLoaded, and MDN says that:

Scripts with the defer attribute will prevent the DOMContentLoaded event from firing until the script has loaded and finished evaluating.

It doesn't look like this is going to be fixed in jQuery proper.

So in our case, jQuery might run our initialization before the external static/dynamic JavaScript files are loaded.

We could poll for the presence of orbeonInitData, as a solution.

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

Also check whether orbeonInitData was mandatory in 2018.2 and earlier.

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

In 2018.1 and 2018.2, orbeonInitData is always output since we set val hasPath = true. So we could rely on this.

In 2019.1, refactoring makes this unconditional.

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

Verified that:

  • delaying the load of the dynamic JavaScript (for example with Thread.sleep()) causes the problem
  • waiting for orbeonInitData to be ready on the client addresses the problem
@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

We now have a fix for master which is based on heavily refactored client-side initialization. Now we need a fix for 2018.2 and earlier.

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

Fix for 2018.2 is ready too.

@ebruchez

This comment has been minimized.

Copy link
Collaborator

ebruchez commented Jan 16, 2019

And fix for 2018.1 is ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment