Support for markdown files would only typeset text as bold or italic
when it appeared inside the corresponding inline Markdown syntax. It
didn't render the Markdown, but rather approximated what the text might
look like if rendered. Because this provides little real value, and
because HLJS sometimes incorrectly parses these Markdown constructs,
markdown is dropped from the highlighting layer.
Bug: Issue 9056
Change-Id: I97865dc8b522dca5a50264456274590fac83dae9
Until recently, the only side-loaded resource was the HLJS library for
computing syntax highlighting. For this task, the gr-syntax-lib-loader
provided an interface to load the library whether or not PG is being
served from a CDN.
With this change, the component is refactored to allow loading resources
other than the syntax library. A method is added for loading the
"dark-theme" document independently of whether a CDN is configured.
Also, some documentation comments are added to the existing methods.
Change-Id: I9891539cd4cf76ac0fe430ff3988e3a9dfbb0ca3
It is highlighted in with javascript.js in highlight.js so it dosen't
have a seperate file for it's lang.
Bug: Issue 8646
Change-Id: I5f561c342b96334eda82f8165b018209f10cab36
These tags are preserved by the Closure compiler and vulcanize in order
to serve the license notices embedded in the outputs. In a standalone
Gerrit server, these license are also covered in the LICENSES.txt served
with the documentation. When serving PG assets from a CDN, it's less
obvious what the corresponding LICENSES.txt file is, since the CDN is
not directly linked to a running Gerrit server. Safer to embed the
licenses in the assets themselves.
Change-Id: Id1add1451fad1baa7916882a6bda02c326ccc988
This is a partial roll-forward of c/106190
This replaces all loads of iron-test-helpers with a load of a file
that wraps it, and adds that file to test files that do not currently
load iron-test-helpers.
A future CL will also install polymer-resin via common-test-helpers.html.
I tested by running
$ WCT_ARGS="-l chrome" ./polygerrit-ui/app/run_test.sh
Change-Id: Ifb3cd2c8db13d724f57e56e7e78045470d103a43
polymer-resin intercepts polymer property assignments
before they reach XSS-vulnerable sinks like `href="..."`
and text nodes in `<script>` elements.
This follows the instructions in WORKSPACE for adding a new bower
dependency with kaspern's tweak to use the dependency in a rule so
that it's found. //lib/js/bower_components.bzl has already been
rolled-back per those instructions.
The license is the polymer license as can be seen at
https://github.com/Polymer/polymer-resin/blob/master/LICENSE though
I'm not sure that //tools/js/bower2bazel.py recognizes it as such.
Docs for the added component are available at
https://github.com/Polymer/polymer-resin/blob/master/README.mdhttps://github.com/Polymer/polymer-resin/blob/master/getting-started.md
With this change, when I introduce an XSS vulnerability as below,
polymer-resin intercepts and stops it.
Patch that introduces a strawman vulnerability.
--- a/polygerrit-ui/app/elements/core/gr-main-header/gr-main-header.js
+++ b/polygerrit-ui/app/elements/core/gr-main-header/gr-main-header.js
@@ -55,6 +55,10 @@
url: '/q/status:abandoned',
name: 'Abandoned',
},
+ {
+ url: location.hash.replace(/^#/, '') || 'http://example.com/#fragment_echoed_here',
+ name: 'XSS Me',
+ },
],
}];
---
Address kaspern's and paladox's comments.
---
Undo version bumps for bower dependencies.
---
Change Soy index template to parallel app/index.html.
---
update polymer-resin to version 1.1.1-beta
----
Load polymer-resin into polygerrit-ui/**/*_test.html
After this, I ran the tests with
-l chrome
-l firefox
I ran a handful of tests with -p and observed that the
console shows "initResin" is called before test cases start
executing.
These changes were done programmaticly by running the script below
(approximately) thus:
```
gerrit/ $ cd polygerrit-ui/app
app/ $ find . -name \*test.html | xargs perl hack-tests.pl
```
```
use strict;
sub removeResin($) {
my $s = $_[0];
$s =~ s@<link rel="import" href="[^"]*/polymer-resin/[^"]*"[^>]*>\n?@@;
$s =~ s@<script src="[^"]*/polymer-resin/[^"]*"></script>\n?@@;
$s =~ s@<script>\s*security\.polymer_resin.*?</script>\n?@@s;
return $s;
}
for my $f (@ARGV) {
next if $f =~ m@/bower_components/|/node_modules/@;
system('git', 'checkout', $f);
print "$f\n";
my @lines = ();
open(IN, "<$f") or die "$f: $!";
my $maxLineOfMatch = 0;
while (<IN>) {
push(@lines, $_);
# Put a marker after core loading directives.
$maxLineOfMatch = scalar(@lines)
if m@/webcomponentsjs/|/polymer[.]html\b|/browser[.]js@;
}
close(IN) or die "$f: $!";
die "$f missing loading directives" unless $maxLineOfMatch;
# Given ./a/b/c/my_test.html, $pathToRoot is "../../.."
# assuming no non-leading . or .. components in the path from find.
my $pathToRoot = $f;
$pathToRoot =~ s@^\.\/@@;
$pathToRoot =~ s@^(.*?/)?app/@@;
$pathToRoot =~ s@\/[^\/]*$@@;
$pathToRoot =~ s@[^/]+@..@g;
my $nLines = scalar(@lines);
open(OUT, ">$f") or die "$f: $!";
# Output the lines up to the last polymer-resin dependency
# loaded explicitly by this test.
my $before = join '', @lines[0..($maxLineOfMatch - 1)];
$before = removeResin($before);
print OUT "$before";
# Dump out the lines that load polymer-resin and configure it for
# polygerrit.
if (1) {
print OUT qq'<link rel="import" href="$pathToRoot/bower_components/polymer-resin/standalone/polymer-resin-debug.html"/>
<script>
security.polymer_resin.install({allowedIdentifierPrefixes: [\'\']});
</script>
';
}
# Emit any remaining lines.
my $after = join '', @lines[$maxLineOfMatch..$#lines];
$after = removeResin($after);
$after =~ s/^\n*//;
print OUT "$after";
close(OUT) or die "$f: $!";
}
```
---
update polymer-resin to version 1.2.1-beta
---
update Soy index template to new style polymer-resin initialization
----
fix lint warnings
----
Load test/common-test-setup.html into *_test.html
Instead of inserting instructions to load and initialize polymer-resin into
every test file, add a common-test-setup.html that does that and also fold
iron-test-helpers loading into it.
----
imported files do not need to load webcomponentsjs
Change-Id: I71221c36ed8a0fe7f8720c1064a2fcc9555bb8df
The logic inside the syntax layer that decides whether the next step of
the processing is done synchronously or after a timeout would not choose
to use a timeout if it is processing the zeroth section of the diff.
For diffs with very large initial shared chunks (for example a chunk of
more than 20,000 lines as linked in the bug) this results in the syntax
layer processing the entire chunk using synchronous recursion.
As a result, the (1) UI would lock up while processing the syntax for
this chunk, and (2) when rendering all diffs on the change, the call
stack would be exceeded.
With this change, the syntax layer allows asynchrony when processing the
zeroth chunk of the diff.
Bug: Issue 5654
Change-Id: I0e60479b2c59c9c626199e7a6b8d63ccb55ebaa7
HLJS emits a syntax class for function parameters which the PolyGerrit
syntax stylesheet would color blue. However, HLJS did not always apply
this class accurately, for example, in the C++ case described in the
linked issue.
Because the class was not very informative anyway, and the HLJS default
stylesheet does not style it either, this change removes it from the
PolyGerrit syntax styles.
Bug: Issue 4975
Change-Id: I26ed0b8f745ac6add994a5d1cfc8eb1303dac8cf
Include workarounds with bug references for a pair of simple HLJS bugs
related to parsing character literals.
* In Go, HLJS misunderstands backslash character literals.
* In C++, HLJS misunderstands wchar_t character literals.
Bug: Issue 5007
Bug: Issue 5242
Change-Id: I4c92b254062198dbf043ccd401e3224961a84a33
In lieu of upstream fixes to Highlight.js, write local workarounds for
some known parsing bugs.
Bug: Issue 4864
Bug: Issue 4776
Change-Id: I6bde7d44821df18a07ea45dbbc2a7343d597963d
The syntax class whitelist is a feature that restricts the DOM elements
created for syntax highlighting only to classes which have CSS styles.
However, the test for this whitelist was being applied at the wrong
place, and would ignore whitelisted classes that were nested inside
non-whitelisted classes.
With this change, the location of the whitelist test is fixed, and a
unit test is added to encode the correct behavior.
Bug: Issue 4578
Change-Id: Ic3631b0fb44dc2c691069b8134ad88a55feb977a
Tapping the "Show Diffs" link in the change view to display all of a
change's diffs inline spawns several asynchronous syntax highlighting
processes. Sometimes (especially for long file lists and slower HLJS
download rates) multiple highlight processes would request HLJS before
it had been loaded, resulting in multiple load/definitions of the
library. Occasionally this would result in a JS exception.
With this change, the HLJS loader functionality of GR-SYNTAX-LAYER is
separated into the GR-SYNTAX-LIB-LOADER component. This component
employs a singleton property to track state across multiple lib requests
behind a promise interface.
Tests are updated.
Change-Id: I673998d406a33afa158e04c4dbb91fe31442d527
The syntax layer sometimes emitted syntax annotations which did not have
corresponding styles, making the resulting elements dead weight in the
DOM. With this change, the syntax layer only attaches the subset of
syntax annotations which have styles by comparing them against a
whitelist.
Change-Id: Id6ced6df2ef765abd3d93cd4798381726619230b
Applies a minor performance improvement when both sides of the diff are
labeled by an unsupported language. Previously, the GR-SYNTAX-LAYER
`process` method would needlessly traverse the entire diff when the
languages were not in the support map. With this change, the `process`
method resolves early in such a scenario.
Change-Id: I8e5ef9fa410facdd60ca33c234ced682ffb182d7
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
Adds new languages and removes an unused language. The built, minified
and gzipped size of the HighlightJS library increases from 17KB to 25KB.
Change-Id: Id3c83e5b0592b85c9f2adf53f07b6852966dcced
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
