This will be used by gr-thread-view so that comment threads can have
context. In order to generate URLs, comment threads will also need a
line and change property.
Change-Id: I35d405c8af9f10b4e0c89dd5fcb9e48b7b373534
Future changes will enhance the aesthetics of this component and insert
it as a tab by the messages list
Bug: Issue 8241
Change-Id: Ia68519ba67aa0fa07d1687e731e1ed82e9979369
When a new comment is being added to a line, Gerrit checks to see if
there is an existing thread on the same line (and same range, if any) so
that the comment can be appended to it if so. Otherwise, a new thread is
created.
However, following I4f7804ac02, the logic to identify the appropriate
thread by range was refactored to not use range location strings, but
use range objects instead. Problematically, there were two flaws in this
code:
1) The range object references were compared rather than their values.
2) Only new threads were being rendered with their corresponding ranges
whereas existing threads were not.
As a result, if the user attempted to add a line comment on a line with
an existing ranged comment, the ranged comment's thread would be
identified as the destination (because the new comment has no range and
the existing thread's range was not being set). Appending the range-less
comment to a ranged thread resulted in incoherent data and the draft
would be unsavable.
With this change, the logic uses value equality to match ranges and the
`gr-diff-comment-thread-group#_getThreads` method is updated to set the
range on existing threads.
Bug: Issue 8410
Change-Id: If34e0d46a5c1af81bec82125217088fb574a2f61
Introduce the gr-diff-mode-selector which componentizes the diff mode
buttons already used in the file list and adds them to the diff view.
With this new component, when authenticated users change their diff
preference using the new selector (or by the 'm' keyboard shortcut), the
new mode is saved to their preferences. Unauthenticated users see no
change in diff mode preference persistence.
The diff selector is now consistently labeled as "Diff view" rather than
as "Diff views".
Bug: Issue 8144
Change-Id: I4b30714deb9a466e707b3d4ae90c1d4c60222c64
For some dialogs, the confirm event should fire on enter. This change
adds this optional property.
Checking the disabled property before firing the confirm event should
prevent unintended side effects throughout the app.
Change-Id: I5603065b37bf87b1c4b36ff54376fb4066869afe
Line numbers in diffs had been specified in data-attributes and CSS to
avoid including them in pasteboard selections. However, we have since
moved to a different system that avoids including non diff content in
selections, and this CSS needlessly complicates style application.
With this change, diff line numbers show content, and the relevant CSS
is simplified. This provides a small, but measurable diff render
performance improvement.
Change-Id: Iad062553be533ead1dd29eaaacd5af8867249a16
Follow-up to https://gerrit-review.googlesource.com/c/gerrit/+/157590
which no longer used locationRange to group comments together into
threads. However, locationRange was still used for a few other things
including thread removal, which could result in a bug if there were
two threads that had the same locationRange and the wrong one was
found first.
Things included in this change:
1. Determine whether a thread group exists
- This is identified as it was before. The thread group now gets a
commentSide attribute, as it can pass it to all of its children
(the same for all).
2. Determine if a thread exists within the group for a given range in a
group
- The range object is now included as an attribute on the comment
thread instead of the locationRange string.
3. Be able to remove a thread group
- A rootId attribute is now stored on the comment thread, which is
data bound to each comment. When a comment is removed, it finds the
thread with the rootId within the thread group to remove.
- In the event that a thread group only contains a single draft,
there is no roottId.
Change-Id: I4f7804ac02f4259b4964c6333d258f0fc3b29d24
Ieae237f9bb1 adds a keyboard shortcut to switch diff view modes in the
diff view. With this change, the key is changed from 'v' to 'm', support
is added to the change view as well as the diff view, and tests are
added.
Bug: Issue 8269
Change-Id: Ifeaa26bc1d6256809d58673232cf982b6faac400
Formerly, if diff rendering is started, but then unloaded or navigated
away from, the rendering work would needlessly continue in the
background. Cancel rendering when a diff will not be used.
Bug: Issue 6061
Change-Id: I695281229335e84f2d5c802c1fa971842c588330
The ability to modify the preference in the diff settings will be added
in a later change.
Bug: Issue 4676
Change-Id: I8c335acd9c50344714e56901f82c09327e7f4366
The UI does not allow creating multiple comments at the same diff
location, but instead encourages contributing to the comment threads
already at a location. The uniqueness of thread locations was leveraged
to simplify the collection of comments into threads by mapping their
locations to keys.
However, the REST API does permit multiple threads starting from the
same diff location, so this expectation in the key-based UI threading
logic can be wrong. In such scenarios, an unresolved thread may be
mistakenly inserted into a resolved thread, resulting in a comment that
is not resolvable through the UI.
With this change, the `getCommentThreads` method is updated to associate
comments into threads via the `in_reply_to` graph rather than location
map in the same way that the `unresolved_comment_count` detail property
is determined server-side.
Although this corrects the issue in the `getCommentThreads` method, as
of this change, the diffs do not yet use it to thread comments.
Migrating diffs over to use it will be done in follow-up.
Bug: Issue 6779
Change-Id: I9427ccc716acdf7ef4c63eba48d2287875fa5534
The UI does not allow creating multiple comments at the same diff
location, but instead encourages contributing to the comment threads
already at a location. The uniqueness of thread locations was leveraged
to simplify the collection of comments into threads by mapping their
locations to keys.
However, the REST API does permit multiple threads starting from the
same diff location, so this expectation in the key-based UI threading
logic can be wrong. In such scenarios, an unresolved thread may be
mistakenly inserted into a resolved thread, resulting in a comment that
is not resolvable through the UI.
With this change, the threading logic in gr-diff-comment-thread-group is
updated to associate comments into threads via the `in_reply_to` graph
rather than location map in the same way that the
`unresolved_comment_count` detail property is determined server-side.
Bug: Issue 6779
Change-Id: Ibb29d4ba5c5de9e92dfbfba8ac7ac8037c332028
- Updaotes the unresolved property to be public, and reflects the
attribute. This will be used for the toggle to show unresolved threads
or all threads.
- Update logic to always show drafts at the end of sorted comments.
Without this, the thread could get in a weird state where you can
still add another draft, but since they are not threaded, and once the
comment is published, its date changes to the published date anyway,
so its ordering will be at the end.
- This change also adds the __draft attribute in gr-diff-comment-api so
that draft comments will render correctly in the new view.
Change-Id: Icacc46ab5fd643b061ecfac8dcd313f815d17199
When there isn't an explicit revision, the view defaults the base patch num to
PARENT. When the base patch num is PARENT, baseCommit should be set to the
parent commit.
Change-Id: I2c5291f67356111ef4562f36636647f0cb98bea6
We encountered an issue where PolyGerrit was not respecting browser
font preferences. Browser font preferences include both a default font
size and a minimum font size.
In the event that a font declared in px is smaller than the minimum font
size, the size is increased to equal the minimum font size. However,
if the font is declared in px and greater than the minimum, the
preferred font size is not taken into account.
Browsers' default font size is 16px [1], So instead of declaring the
base font in px (previously 13px), this change makes it a percentage
of the default font size. If the user has changed their default, this
is taken into account.
From this point, all other fonts will be declared in rems, which makes
it easier to base the new size off of the base font size of the <html>
tag, rather than ems which bases it on the container[2]. This allows us
to declare font sizes in a way more similar to pixels, yet relative.
A follow-up change will change all font size declaration to use rem from
em for consistency.
[1] https://stackoverflow.com/questions/29511983/is-the-default-font-size-of-every-browser-16px-why
[2] https://webdesign.tutsplus.com/tutorials/comprehensive-guide-when-to-use-em-vs-rem--cms-23984
Bug: Issue 8157
Change-Id: I04ec2c861b2fb288ec7556dfb655d7feea9c9157
Commit d5d9a13ec8fa62f0c36df7b75a2231663056668f fixed Issue 5091 by
adding a newline to the end of each diff line. In files with CRLF line
endings, this causes spurious newlines as described in Issue 7164.
This tweaks the aforementioned fix to specifically target empty lines
thereby still ensuring that (empty) diff lines don't collapse to 0px
height while avoiding inserting spurious newlines elsewhere.
Bug: Issue 7164
Change-Id: Iafbbf004cfb588fc123988674bbce8dfabf4d2b8
The saveReviewedState observer observes params.*, but should not set
reviewed state when view !== Gerrit.Nav.View.DIFF. This can (and did)
happen when the Gerrit.Nav API is used to change the view -- the
observer is triggered before the view is detached.
Bug: Issue 8192
Change-Id: I06c1875f6f515c0d001277e63eb7724728c85cba
When users navigate to the diff view with a line number specified at the
end, depending on their context preference, the line might be in a
shared region that gets collapsed when the diff renders. With this
change, the location specified in the URL is prevented from being
collapsed by marking it as a "key" location.
Bug: Issue 5247
Change-Id: Ifd5827cd922b022cddb1601911a9ecea6a054f35
Formerly, the save button would be disabled when attempting to edit a
comment to have the same content as what's already been saved. This can
be a confusing UX where it isn't clear why a comment cannot be saved.
Allow saving comments even when the text has not been changed.
Bug: Issue 8128
Change-Id: I615c38e0cc109ea87f58c9b8a9b7de28ec459b88
Change edits must be able to get file content from non edit patch sets.
This new function gets the file content and type, regardless of what
patch set is being referenced (edit or otherwise).
This change also uses the new function in gr-editor-view.
Bug: Issue 4437
Change-Id: Id0e395df42aa5c635d126573814cb4fdd61486cb
