Previously, the absolute path HighlighJS loader did not work when served
from a CDN. With this change, the absolute path for the script considers
the domain that the GR-APP element is served from.
Change-Id: I024507aed175ce7000e3db0c711cbf559e3d2126
This causes issues when the app is vulcanized and the paths are
different as a result. The async/defer attributes will ensure
the script does not block parsing of the page.
Adds a flag to the Vulcanize rule that excludes HLJS. Confirmed that the
tag is ignored by Vulcanize phase in the compiled WAR file. Confirmed
that the `onload` case functions as expected via browser throttling.
Change-Id: Ie9603a5a07d4bae198ccc1ee56f408bfa0d37d49
Previously, the HighlightJS library (HLJS) was being Vulcanized into the
PolyGerrit build, even if the library was not being used (for example if
the user does not navigate to a diff or has syntax highlighting disabled
in preferences). Because HLJS is a substantial file -- ranging in size
from 47KB to more than 455KB (ungizpped) depending on the build
environment, this is not ideal.
In order to lazy load a JS library:
1) It needs to be copied into the built WAR file to be addressable, and
2) It should not be Vulcanized into the built gr-app.js file.
Previously, the PolyGerrit build system supported copying and
non-vulcanizing exactly one JS library: namely webcomponents-lite.js.
This change generalizes the mechanism by which webcomponents is copied
and adds HLJS to that list. This satisfies **1**.
Furthermore, the GR-SYNTAX-LAYER is rewritten to dynamically import HLJS
in the `process` step by crafting a SCRIPT element and attaching it to
the local DOM. (Syntax processing is invoked only after entire diff is
rendered.) Code that depends on the library awaits this load before
using it. Thus, the conventional JS import can be removed from the
element's HTML and will not be recognized by the Vulcanize phase. This
satisfies **2**.
Tests are updated accordingly.
Bug: Issue 4298
Change-Id: I9a95d6d4c211cd8f1ca1bc4daec770b64b22b3d1
Adds checkboxes to both diff preferences controls, adds an `enabled`
boolean property to the `gr-syntax-layer` element, and updates all
relevant tests.
Bug: Issue 4297
Change-Id: I10cef760c354c53e03acfb3c84379e82859ef25f
Formerly, the annotation layer interface provided the GrAnnotation
library as a parameter to the `annotate` method. This was so the layer
would not necessarily need to import the library at the module level
and instead could use it as a utility toolbox.
With this change, the library is no-longer part of the interface and the
layers are now expected to import it at the module layer (if they have
a use for it).
Change-Id: I49b96c67ec724708c2861ab6be3ce27a53cc1b05
Introduces the gr-syntax-layer element. This element works as an
annotation layer that is configured with the diff and asynchronously
computes/applies syntax for the diff.
Introduces a custom build of Highlight.js which gr-syntax-layer makes
use of. Building the script is documented in
scripts/vendor/highlight/building.md.
The layer is connected to the annotation pipeline in gr-diff-builder as
the lowest layer and syntax processing is triggered only after a diff
has been completely rendered.
A number of styles are added to the gr-diff element for syntax markers.
Tests added for gr-syntax-layer.
Bug: Issue 3916
Change-Id: Ic33e40f4fe39dfce1a62de133cfaf32be5e3f25a
