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
Diff comments are threaded together based on the in_reply_to relation
(which potentially expresses a tree structure) but are always displayed
linearly in the UI. This means that some comments in the middle of a
linear thread may be actually stored as leaves of a tree.
For example, the following thread of comments can be created if comments
two and three are created at nearly the same time.
Comment 1: thread root, unresolved,
┣ Comment 2: in reply to comment 1, unresolved,
┗ Comment 3: also in reply to comment 1, unresolved,
┗ Comment 4: in reply to comment 3, resolved
Because the thread is flattened, the resolved state of the thread should
be determined by the state of the chronologically latest comment (#4),
resulting in this thread being considered as resolved.
However, in a couple of locations, the resolved state is counted
differently. Namely, it finds the "leaf" comments -- that is, the
comments that are not marked as the parent of any other comment -- and
the number of unresolved threads is determined as the number of
unresolved leaves.
This approach was used by:
- ChangeComments#computeUnresolvedNum in the UI, which determines
the string stating the number of unresolved threads in a file row.
- ChangeData#unresolvedCommentCount in the Java server code, which
determines, among other things, the value of the
unresolved_comment_count change detail property, as well as the Prolog
fact used by the Prolog recipe that requires all comments to be
resolved before a change can be submitted.
Instead, the unresolved thread logic is modified to group comments into
flat threads, and consider the resolved state of each one based on the
chronologically final comment, irregardless of the leaves.
Bug: Issue 8472
Change-Id: I2788fdb22ecfd56f0b3da763790a7732ec73be33
With this change, in merge changes, patch ranges can diff against a
specific parent (as indicated by a negative parent index) similarly to
the GWT UI.
- Parent options appear in patch range selectors when available.
- The router no longer redirects parent indexed patch ranges now that
they are supported.
- The RevisionInfo class is added to house revision related functions in
a form that's easily passed between components.
- On merge changes the default patch range base is labeled as
"AutoMerge" rather than "Base".
Feature: Issue 4760
Change-Id: I221ba97e28be52f225f7d90f5f8c5a0f17ddb8c2
Observing both revisions and _sortedRevisions in <gr-patch-range-select>
is unnecessary.
This change does not fix any bugs, but does simplify the code.
Change-Id: I01e5562e3ca40ba5f0be1d73036bbeb70313c7cf
As discussed with UX (and as exists in GWTUI), highest-first order is a
more convenient ordering for patchset dropdowns.
Bug: Issue 7551
Change-Id: I6212d293accbee3772c2765f1e20e951f110d4d2
Previously, comments were not used as a parameter in the computed
function that calculated patch range values. Instead, it just used the
value of 'comments' when the patch dropdown was computed.
However, if comments were loaded after the dropdown values were
calculated, it was not updated to display the comment counts.
This change fixes the problem by using comments as a parameter in the
value calculations, and includes a default empty object in the case that
comments are not used as an input for the patch range selector
(currently the diff view).
Bug: Issue 7444
Change-Id: I2646800afc1632bf39b3c6a451c848669007ca18
Two-way databinding was causing some cyclical UI updating, resulting in
an incorrect redirect URL. Instead of binding to the patchNum and
basePatchNum in both directions, the patch-range-select fires an event
when it notices a change in the selected patchsets.
Bug: Issue 7336, Issue 7315, Issue 7316
Change-Id: Ifdf476dcf4fa1353d0b280d7e6dd25e4ef40865a
This also moves the change reloading logic back to the change view,
where it gets updated patch ranges via a two-way data binding.
Change-Id: Ib09ad1a176ba96bac77a513d344226df029aef7b
Slight refactoring required in order to satisfy both use cases:
- Fire an event when patch range changes and let parent element
handle it.
- Support comment strings
- availablePatches becomes an array of objects instead of an
array of integers.
Change-Id: Ia8da9296f41eb2d45c9358d03fbec3940273ad9d
ORIGINALLY: Iafd4b80af53624027c347f0f443b4cdfde292e29
This change makes the change view and the diff view change edit aware.
Mutation operations on edit itself, like editing files in editor, are
beyond the scope of this change.
Change edits must be fetched with a separate change edit endpoint and
merged into the change.revisions object. The _number of an editInfo is
'edit'. It has a special property called 'basePatchNum' that marks
which patch set the edit is based on. In patch set selectors, the edit
is sorted right after its basePatchNum.
Alternative implementation considerations:
It could be easier to handle edits on the Polygerrit UI, if
GET /changes/<id>/detail endpoint
would optionally include the change edit in the resulting
change.revsions map.
TODOs:
* Overwrite change.current_revision with change edit commit in some
use cases
* Mark the change edit as Change Edit in the header of the change view
* Allow for modification of the edit in the change/diff view
* Disable commenting on files in edit patchsets
* Modify file list rows to have appropriate actions when edit is
selected (e.g. allow revert, disable marking as reviewed)
* Identify and whitelist valid change/revision actions for an edit
Bug: Issue 4437
Change-Id: Ia4690d20954de730cd625ac76920e849beb12f7c
Polymer2 does not support type extension. As such, elements that rely on
it are updated.
Instead of
<select is="gr-select"><select>
This will now be..
<gr-select>
<select></select>
</gr-select>
This is similar to the implementation of iron-input, except that is more
complex, as it is supporting both type extention and non-type extension.
https://github.com/PolymerElements/iron-input/blob/master/iron-input.html
Bug: Issue 6371
Change-Id: I31091ff24791a9dc073b3325c7b0daa1580b69ef
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
Previously, on a changelist or file view, if you change the patchset
to a lower number and then click the back button, dropdown value did not
change properly. The issue was related to how the selected option was
rendered in a dom-if. This change refactors the gr-select element to fit this
use case.
Bug: Issue 4800
Change-Id: I66ee5b7aba5421a01ca79f9e72a853a73c32e589
There is no change in functionality. Only moving things around.
+ Separate html from the js.
+ Place the unit test for a component within the same folder.
+ Organize the components in subfolders.
Change-Id: I51fdc510db75fc1b33f040ca63decbbdfd4d5513
