13px (1em in PG) should be the minimum body font size for a11y reasons.
Some other CSS is modified in this change in order to accomodate the
implications for the layout (mostly in the change actions).
Bug: Issue 9171
Change-Id: I7a7baa58bf5599888bd75e4b329fb4f75f198dc5
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
Uses padding and negative margin to increase the click target for
expanding/collapsing diff comments.
Also listens for tap events instead of click events.
Bug: Issue 8896
Change-Id: I1e54fb703795f5e153da5bc2ccfd5dc575a6e03a
Record the time it takes to save, update and delete comments starting
with the handlers for user corresponding interactions.
Change-Id: I9f22dc2e015fa46afcd5d531a3c0d4906e0bec89
Swaps out various shades of red and black with --error-text-color and
--deemphasized-text-color, respectively.
Also removes some vestigial CSS that was never applied, and a hard-coded
check for a specific color in gr-autocomplete_test.
Change-Id: Ideee67300d8bbaa8e86fb1a2991492fa22a2ac43
Declares several CSS variables for styling buttons throughout the app
and uses them.
Removes the concept of a 'tertiary' button -- primary and secondary have
the exact same styling, so all tertiary buttons are changed to secondary
buttons and the existing secondary button (only replyBtn) is changed to
a primary button.
Also removes some of the many ways to modify a button color and
background -- there is no need for mixins to specifically style various
attributes of the paper-button when the ability to apply any styles
directly to it (via @apply --gr-button) is already supported.
Change-Id: I19a4114764df80b06175032b228a6ec63b414089
Introduces and standardizes the various shades of medium dark gray used
throughout the app to #616161, or Material Gray 600.
Change-Id: I311155cfdba4381643451233dfafbfbdacd55e90
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
- Removes the blue background color
- Moves the robot comment specific buttons to be left aligned
- Makes the robot run ID selectable
- Displays the run ID as plain text if there's not a link
Bug: Issue 8514
Change-Id: Ic72caaf76977f5485655ef9ed45b4a7350397a9b
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
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
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
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
A few changes:
- Utilize mixins within gr-button internally, so less styles have to be
overridden by elements implementing their own button styles.
- All buttons have a hover background color, which is 12% black
overlayed on top of its current background color.
Bug: Issue 7894
Change-Id: I4f2879aa0232912267bbf1290a1c800d024099a6
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
This change makes the following replacement:
<content select=".header"> replace it with
the slot equivalent.
Change-Id: Icc68576a3b44559775103163febd429194802981
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
Some modifications to the styling of paper-button within gr-button
overrode a few deliberate styling decisions made in the delete comment
button (namely, color and padding). This change moves those CSS props
inside a styling mixin so that they are properly applied, and overload
the defaults from inside gr-button.
Change-Id: Ifdfc0a3959f4131e1bb86e8b66d70db2fde79077
The hidden attribute was erroneously left on the cancel button in diff
comments, causing it to not show up by default.
It showed up upon editing an existing draft because the hideOnPublished
CSS overrode the hack for the [hidden] attribute.
In addition, the buggy behavior was actually enforced by a buggy test --
it asserted that the button was not visible, but was labelled as "Cancel
is visible".
Bug: Issue 7664
Change-Id: I9e08c33fc4adf0f1465a52055a3308210625ffde
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
Because the order of buttons switched on most modals (cancel on left,
save on right) this updates the button order in gr-diff-comment for
consistency. Discard is moved to the left of 'save' and 'edit'.'
Change-Id: Ifa08976b77d99bb32fb1d6388f38843ad9e065fa
This change moves the admin-only commment up above the comment next to
the date and styles it more subtly, saving vertical space.
Bug: Issue 7274
Change-Id: Id3095a5439e33055eec3191f6e31d17bb8640615
It makes the most sense (at least for left-to-right language speaking
locales) to have the most final and most destructive UI elements read
last, as interacting with those is the most permanent, and requires the
full context of the information in the element.
In diff comments, actions like 'Save' and 'Discard' (which affect the
entire comment) were on the left, whereas toggling the resolved state
was on the right. This change flips these alignments.
Bug: Issue 5924
Change-Id: Id00e19d662a983fad071df0fb866052b2001beb4
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
