When creating, updating or deleting draft comments, the diff containing
the draft does not need to be kept open for the underlying requests to
succeed. However, in a number of ways, the draft UI suggests that it
does. This results in the draft writing process feeling like a blocking
experience when it need not be.
Change the draft UI to feel less blocking:
- Instead of merely disabling the textarea when saving, the textarea is
hidden and the presentation form of the message is shown immediately.
- Instead of disabling a draft as its being discarded, the draft
disappears immediately.
- The `_savingMessage` is removed.
Bug: Issue 6970
Change-Id: Ia396f0f1780571def84be0d20f19c98bdb0b0cde
The gr-reporting "time" and "timeEnd" methods provide a convenient
mechanism for PolyGerrit components to record timings. However, because
they record the start time in a global dictionary keyed by the timing
name, they do not work well when multiple timers with the same key may
be reported simultaneously.
This multiple-timer scenario can come about when creating diff drafts,
which uses the CreateDraftComment timing key to time each draft,
potentially overwriting timers for earlier requests.
Create Create Draft 1 Draft 2
Draft 1 Draft 2 Created Created
| | | |
+------------------------+ |
| | | |
| +------------------------+
| | | |
Time ----+-----------+------------+-----------+---------------->
| | | |
Save Save Timer Timer attempts
Timer Timer Ended to end, but no
Baseline Baseline timer is running!
(Overwrite!)
Provide a new method to record timing using timer objects that do not
store start times statefully. This gives a simple tool for the
concurrent timer cases, while preserving the convenient interface for
the timers for which concurrency is not an issue.
Change-Id: Ia5c030a16c87537700928df71a175821770e6814
Record the time it takes to save, update and delete comments starting
with the handlers for user corresponding interactions.
Change-Id: I9f22dc2e015fa46afcd5d531a3c0d4906e0bec89
Until the thread list was added, we rarely rendered a large number of
diff comments at once. A diff would add them incrementally in an
asynchronous loop, and even then, their number was reduced by being
filtered to to the given path and patch range.
Rendering all comments at once in the thread list exposed inefficiencies
in instantiating gr-diff-comments, and, for changes with many comments,
could temporarily lockup the browser.
The biggest cause of slowness in comment instantiation was the textarea
for editing. Because existing comments are not in an edit state by
default (...and because only the final comment in a thread can be edited
anyway ... assuming the user even chooses to edit ... assuming there
even is an authenticated user...) it's more efficient to put the
textarea in a dom-if until it's needed.
The overlays are also expensive but infrequently used. These are put
inside a dom-if as well.
Change-Id: I50702afe2b178221110ad3200c5e3862a7722c5d
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 changes updates the unresolved toggle so that it only attempts to
save when explicitly tapped (as opposed to the value of resolved
changing on its own).
This was causing issues with comment synchronization between
gr-thread-view and diff comments, and also re-rendering the order of
comments in gr-thread-list within the dom-repeat.
This change also lets the resolved checkbox get selected via the enter
key.
Change-Id: I6065c745a0eabcf19df38f3cd6fd2c0d7e7434f3
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
Previously, the resolved checkbox called _saveDraft(). Using save()
instead disables the comment while waiting for the save request to
return.
Bug: Issue 7933
Change-Id: I44ce88094b271aa46a726a75aa4eb283b29f1a35
Draft comments with message text should have a confirm dialog when
discarded to prevent accidental data loss.
This is a regression introduced by I0dae814.
Bug: Issue 7900
Change-Id: Ibd9829ccf36a551445282e5cb0d37c1a6df46ab9
A recent change modified some comment editing UX. As a consequence, the
save button disabled state was erroneously based entirely on whether or
not the comment message had changed.
With this change:
- Save disabled state on a comment takes into account resolved state
- The resolved checkbox is always visible on an expanded draft comment
- When the resolved checkbox is modified on a non-`editing` draft
comment, it is saved immediately
Bug: Issue 6023
Change-Id: I40b0b280129e5a76c13e38c97525f91a8e56482d
Recently, the comment editing UX was changed (the discard button was
removed from the editing view). This (obviously) made it impossible to
discard a draft comment whilst editing it.
Editing a comment, clearing the text, and saving now removes the
comment.
Bug: Issue 7832
Change-Id: I0dae814b9ce2e7a5b57530f839c708e59c215341
The removal of the 'Discard' button from comments in the editing state
complicated the UX of the 'Cancel' button a bit.
Previously:
- Discard deleted the draft completely.
- Cancel cancelled whatever edits were made, and reverted to the prior
draft state. Cancel was also hidden on new drafts.
Currently:
- Cancel cancels whatever edits were made, and reverts to whatever edit
was last stored.
This behavior is problematic, for a few reasons:
- Due to some vestigial code, the actual value of the comment's message
(not just the buffer value '_messageText') was updated any time the
draft comment was edited. This was done to prevent multiple drafts
from being created on the same thread -- that issue was made obsolete
by the removal of buttons from individual comments, and their
consolidation to the thread level.
- If a user cancels a draft, then restarts it (having their text
repopulated from localstorage), then cancels it again, the draft is
rendered as a saved draft comment with the localstorage value, despite
having never been saved at all.
So, with this change:
- Cancel cancels whatever edits were made.
- If a user tries to add a draft in the same place...
- ...and the draft has been saved on the server, the textarea is
prepopulated with the value from the comment received from the
server.
- ...and the draft has NOT been saved on the server, the textarea is
rehydrated from localstorage.
This UX makes sense because...
- Case 1 occurs when a user clicks "Edit" on an existing draft comment -
thus expecting to edit the content shown in the UI.
- Case 2 occurs when a user cancels a draft that they started
constructing, but did not save -- thus there is no suggestion of any
prepopulated value by the UI, _and_ the case in which a draft was
erroneously cancelled during editing can be solved.
Bug: Issue 7709
Change-Id: Iacf9a91fbb0226aba3a518f56edd61f28c15a8ef
Unsaved diff drafts are kept in localstorage so they are not lost if
they do not get saved (for example, if the browser crashes). However,
this stored copy of the comment is cleared when the save request is
started, not after it succeeds. As such, if the save request fails (for
example, if the user credentials are invalid), the comment can be truly
lost.
With this change, the localstorage copy is only cleared after save
success. If the request fails, it allows the error message to appear
rather than showing a misleading "All comments saved" toast.
Bug: issue 7289
Change-Id: Id5c8144ecccec50de35f83af616b4e4915b62b5c
The [Save] button cannot be clicked when the comment is disabled (via
`pointer-events: disabled;` in the CSS), and clicking the [Save] button
results in setting disabled to true. However, it is possible to click
save again before the style is applied. It's also possible to trigger
the button using a non-pointer-event (such as a key). With this change,
an extra check is added to the [Save] button's click handler to prevent
clicks when the component is disabled.
Bug: Issue 6972
Change-Id: I16117af31c5e7b5d7d49a025eebb690d8802b64b
The discard confirm dialog is added alongside the delete confirm dialog
and the dialog opening/closing code is refactored to work on either. The
confirm discard dialog only appears if the draft message is savable.
Feature: Issue 6984
Change-Id: I6d88a8734fa7736f685796790e02437b10c81f00
With this change, toast messages show when diff comments are being saved
and notify when saving is complete, even when the diff view is no-longer
loaded. This signal is intended to encourage users to write diff
comments and feel free to navigate away to view other parts of a change.
With this change, new toast messages are able to replace existing toast
messages.
Feature: Issue 6970
Change-Id: I5973673d85c73b14794cb5e5b21327dd0c27ec1d
The release of eslint 4 introduced some breaking changes -- a full
upgrade guide can be found here [1].
In this change, the "no-useless-escape" and "indent" rules are disabled,
"indent" being replaced with "indent-legacy" to minimize breaks due to
lint. Also, extra spaces before comments and other assorted new lint
issues are corrected.
The long-term plan is to move away from the deprecated "indent-legacy"
rule and also reenable the "no-useless-escape" rule, but for now we
want to minimize breakages and not affect PG developer velocity.
[1] http://eslint.org/docs/user-guide/migrating-to-4.0.0
Change-Id: I8044256c95e3fe3f94fa9acc7922600908f8a0f4
In the previous fix, the function was not called and since it was
the function that set the class to 'hidden' it did not hide.
Change-Id: Ic8f908802cb515086860f20e2c82d0ddd06c0278
There was a formatting issue caused by delete buttons in a draft change.
It really does not make sense for the button to be there for drafts
anyway. This change hides the delete button for admins on draft changes.
Bug: Issue 6257
Change-Id: I236eff9db1f0ca76ed658f3048132c9c675ee407
Previously, there was a race condition in which erasing a draft comment
could occur prior to the updated version of the comment getting saved.
When this happened, if the user replied to the same thread, their old
draft would be pre-populated in the new reply.
This change cancels the 'store' debouncer when erasing a draft comment,
to avoid this race condition.
Bug: Issue 6141
Change-Id: I11a646acf01b1ac986c587e1e8fdb4fd7efc25b7
Previously, the rest api interface set '__isOnParent' for comments.
When comments were added, the property from the comment thread
'isOnParent' was passed as a property. When the draft was saved, it was
expecting '__isOnParent' rather than 'isOnParent' and this caused
comments to show up on the wrong side after saved/refreshed, because
'__isOnParent' was undefined.
Instead of changing to either '__isOnParent' which would be strange to
pass as an attribute or 'isOnParent' which would look like it came from
the api directly, this change introduces isOnParent functions so that
translation doesn't need to be done with the API.
Bug: Issue 5831
Change-Id: I3b849ba5878275cda0a39638626a12bd51341a29
Use '__isOnParent' as a boolean in place if 'side' ('PARENT vs
'REVISION'). In doing so, it's necessary to convert to/from 'side'
whenever interacting with the REST API.
Change-Id: Ic023c9be1969597e4b9c73a51cfed9f5eb9bc23e
Previously, if a PARENT revision was getting compared to a patchset,
the local storage key would be the same for both, and there were issues
if a user was trying to write drafts on the same line on either side.
This addresses the issue by storing 'PARENT' as the patch number in the
local storage key, so that each key is unique.
Bug: Issue 5412
Change-Id: Ia8b2f0abe1d24a3849628fe335c931f07bcaff52
Move all buttons that generate a reply of some sort (done, ack, reply,
quote) to the comment thread instead of the comment [1].
When there is a draft for a particular comment thread, all reply buttons
are hidden [2]. For example, if you click reply, you cannot click done
on the same thread, unless you remove the draft.
Each thread can have up to 1 draft. It's also worth noting that if a
thread has a draft, and the user clicks on the line or 'c' at the same
range, the existing draft will switch to 'editing' form.
[1] With the exception of "please fix" for robot comments.
[2] In this case, The please fix button will be disabled when other
reply buttons are hidden.
Feature: Issue 5410
Change-Id: Id847ee0cba0d0ce4e5b6476f58141866d41ffdad
Goes along with c/95273/. Adds commentSide attribute to comments to see
which side of the diff view they belong on. This is also used as part
of the locationRange for the gr-diff-comment-thread-group, so that two
thread groups can be on the same line or range for the unified group (
one for the right, one for the left).
Note: there is already a 'side' attribute on the gr-diff-comment, which
is confusing. This side actually references 'PARENT' or 'REVISION', to
identify whether the comment belongs to the parent or any revision. On
diffs where two revisions are compared to each other, this cannot be
used to determine left/right. However, because 'side' is part of
the CommentInfo entity[1], it is difficult to change the name and make
more sense out of that.
[1] https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#comment-info
Bug: Issue 5114
Change-Id: I5cc4c17d4bb134e31e5cc07ff9b08ed349488c97
Previously, drafts were only based on line number and not patch range.
This adds range to the key in localstorage so that multiple drafts can
be stored for a line range. It also prevents the wrong draft from
surfacing in the incorrect context.
This change is also important for the multi-thread changes that are
currently in development as well, because it is possible to have
separate threads for these ranges, each of which can have its own draft
saved in storage.
Bug: Issue 3548
Change-Id: Id4c1beb5d73a47a1f98b0b169091905c80f8c64a
This change leverages the unresolved flag to automatically expand only
the last UNRESOLVED_EXPAND_COUNT comments in unresolved threads.
Feature: Issue 4752
Change-Id: Ia23920e1a210246838645d56a6bc81d0dff7da07
This change tracks and exposes the resolved state of a comment thread
without exposing the UI for modifying that state. This enables features
to be built out while the API request does not exist in the backend.
Feature: Issue 4879
Change-Id: If002035024920a7762519cedf5a869221bbbc3c8
This change addresses a few issues that existed due to multiple comments
in an editing state at the same time.
1) Fixes issue where if you create two replies and add text to the
second reply, then delete the first one, the text in the second textarea
gets removed.
2) Fixes issue where if you reply and add text, then reply again with
the first draft still editing, the second draft gets populated with the
message from the first comment.
3) Fixes issue where if you have multiple replies and delete one of
them, local storage gets erased. This change sets local storage to the
value of the first editing message found after deleting the other one
(if it exists).
Bug: Issue 4409
Change-Id: Ib5913a34a79783a4a87b4a298e25b02fc587b8dd
This change adds an API request to get robot comments for displaying
inline in the diff view. They are styled in a different color, contain
build and robotId information, and a "please fix" action rather than the
standard set of actions.
Feature: Issue 5089
Change-Id: I1f5954a2ed01920bb7c3dc897e3285687ff7d3ca
Previously, when a user discarded a draft comment, the draft was still
stored in local storage. If they tried to reply to a comment on the same
line, the previous message appeared when it shouldn't have. This change
removes drafts from local storage when they are discarded.
Bug: Issue 4361
Change-Id: Id234676972a21a879e68e754968abf7008098cf6
+ This does not cover on-keydown handlers within elements.
A follow-up change will account for those.
+ Keyboard shortcuts are disabled within gr-overlay, input,
and textarea elements.
+ Added tests for new behavior (plus some missing ones covering
broken behavior).
+ Removed blur hacks used on elements to placate the kb
shortcuts due to restrictions that have been removed.
Bug: Issue 4198
Change-Id: Ide8009a3bfc340a35a8ec8b9189a85b49c8a95aa
Previously, the escape key closed and cancelled any in progress comment.
This was particularly painful for some who were used to a certain text
editor, so now escape only closes an in-progress comment if it's empty.
Bug: Issue 4816
Change-Id: I2749a995ebf914c4387261c387b008f6ce91dd86
This change adds keyboard shortcuts to the "gr-diff-comment-thread"
expand all comments when 'e' is pressed and collapse all comments when
'shift + e' is pressed. Note that the keyboard event is detected on the
thread instead of the comment to minimize the number of events getting
triggered.
Feature: Issue 4738
Change-Id: Iab77349bd1527d7af5e05a827919a78a86909835
Previously in Polygerrit, comments were always expanded. You could
always see the full comment (if multiline) and any applicable actions.
This change creates a collapsed comment view. It adds a preview of the
text to the header row when collapsed, and can be toggled open when any
part of the header is clicked.
Bug: Issue 4698
Change-Id: Idca5caf92eb32518b6737dbb5a3380d227513996
Shortcut only functions while editing the actual text area of the
comment. This makes sense, as one should have to save each individual
comment as a draft. This also mimics the current behavior of GWT UI.
Bug: Issue 3848
Change-Id: I7037d3dbdc5dae3048fcae580ed09c41e54f0669
