Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.1
-
Component/s: Web - Templates & Resources
-
Labels:None
-
Difficulty:Unknown
-
Similar issues:
XWIKI-8490JS error when importing a XAR and the server returns an error message XWIKI-8486JavaScript errors when annotations are merged with comments XWIKI-7729IDs migration fails due to foreign key constraints XWIKI-7309Exception while saving a document due to migration of boolean properties from strings XWIKI-3175 Clean the javascript global object from method and properties that should not be exposed XWIKI-8890javascript error : Uncaught ReferenceError: isc is not defined XWIKI-1692Improve the javascript mimetype detection in SkinAction#isJavascriptMimeType XWIKI-4053Javascript Error throwing in Tree Tab of Main All Docs in Enterprise Manager 1.6.1 XWIKI-6084Adding a gadget to an empty dashboard fails with a javascript error XWIKI-3182Bad english in error string
Description
Most scripts are now loaded with defer, except prototype.js and xwiki.js.
It seems that we rely on the fact that xwiki:dom:loading and xwiki:dom:loaded would be triggered after all scripts are loaded.
But this is not true, xwiki:dom:load* is triggered during XWiki object initialization, and this object is created in a handler of prototype's dom:loaded event, which is itself an equivalent of DOMContentLoaded event with some fallback compatibility for non-supporting browser.
The DOMContentLoaded event is triggered when the DOM parsing is finished, and since deferred scripts do not interrupt DOM parsing and some browsers fire the DOMContentLoaded at the end of parsing (Gecko one in partcular), all scripts are not necessarily ready when the DOMContentLoaded event is triggered. Therefore:
- using xwiki:dom:load* in defered scripts does not ensure that the event will be trigerred,
- and using them in page content does not ensure that a related script will be available either.
The most visible issue of this is the LiveTable that is not initializing (case 1), this is particularly frequent in FireFox. The same is true for the table in RightsUI, which use a 'copy' of the same code.
The second (potential, since I have not reproduced it) issue is for viewers and widgets, for each the instance depends on the xwiki.dom:loaded event, which may occurs before the script being loaded and therefore observing the event.
Since the xwiki:dom:load* event may arrive any time, event before a deferred script depending on it being loaded, I have added a state flag to XWiki, that should be checked before waiting on such event:
before waiting on xwiki:dom:loading -> check XWiki.isInitialized (already existing flag)
before waiting on xwiki:dom:loaded -> check XWiki.domIsLoaded (new flag)
If the flag is true, it means the event has already been triggered and that the handler could be called immediately. This solve case 2.
For case 1, we need to ensure that both the DOM is loaded and the livetable script is loaded. Therefore, I have choose to put a new event on livetable: xwiki:livetable:loading similar to xwiki:dom:loading but obviously triggered only when the livetable script is ready, and which depend on the xwiki:dom:loading being triggered.
I add documentation on XWiki.org about these improvements.
Since there is not back compatibility breakage and this solve a major issue for FireFox, I have commit to both stable-3.1.x and master.