One way to deal with this is if PolyGerrit tells us where the label change came from: reply dialog or the metadata column. Or if it told us if this label change was propagated to the change object or not.

I took a quick look and it was not obvious to me how to do that.
Maybe +viktard@ has suggestions.

Also, I do not think this is a serious bug. I do not imagine many people do CR+1 in the reply dialog, do not publish, and expect to later be able to hit the quick approve button.
It should still be fixed but it will likely take a while to find the right fix.

One of the ways to fix this would be to reset user selection on reply dialog close, which would trigger callback for replyApi.addLabelValuesChangedCallback() - however, this might be confusing for users.

Would it be possible for the plugin to hide quick approve only based on label scores, received from server? callback for on('showchange') receives full change object and it's the last known state for the change, while replyApi.addLabelValuesChangedCallback() is triggered for user actions and will contain intermediate label updates.

> One of the ways to fix this would be to reset user selection on reply dialog close, which would trigger callback for replyApi.addLabelValuesChangedCallback() - however, this might be confusing for users.

I agree. Changing the current behavior would be confusing.

> Would it be possible for the plugin to hide quick approve only based on label scores, received from server? callback for on('showchange') receives full change object and it's the last known state for the change, while replyApi.addLabelValuesChangedCallback() is triggered for user actions and will contain intermediate label updates.

The problem with this is that when CR+1 is 'x'ed out from the left nav the quick approve button will not show up till there is a page load. And it would also be different from the default behavior. This bug is mainly trying to make chromium-behavior.html's quick approve button behave the same way as the default behavior to minimize confusion.
One way to do this (as I mentioned to agable@) would be to refresh the change object in replyApi.addLabelValuesChangedCallback() this would be expensive but could fix other issues as well (example: https://bugs.chromium.org/p/chromium/issues/detail?id=824459). Not sure how else to handle this unless we add something on the server side :/

(chat recap):

Looks like this can be solved if there was a way to propagate change object updates to a plugin (for example, removing CR+1 from change view via 'x')

I'll add a way for that, perhaps re-triggering on('showchange', ..) or something similarly powerful.

Hope this helps.

Regarding comment#5- As discussed yesterday, I believe that will solve the problem with labels updated via 'x'. Would it also be possible to re-trigger 'showchange' when unresolved comments are added? Thanks!

Triggering 'showchange' when labels are changed and comments are added seems like overkill: some of our plugins do a lot of heavy lifting .on('showchange'), including firing off RPCs and adding elements to the DOM. Firing that event more often than expected will break a lot of things.

But firing some sort of event for "something has changed but didn't require a whole page refresh; here's the new change object" would be super helpful.

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/gerrit-plugins/chromium-behavior/+/8df2c258de161b7b5c555989d5262ff125e62c7e

commit 8df2c258de161b7b5c555989d5262ff125e62c7e
Author: Ravi Mistry <rmistry@google.com>
Date: Tue Mar 27 18:47:06 2018

Use updated change object when Code-Review label changes without a page load

This will now use the correct information to display the quick approve button.
This is not as bad as I suspected earlier because the change object is only refreshed
whenever the Code-Review label changes (not for ALL label changes).

Bug:  chromium:820117 , chromium:824459 
Change-Id: I1b394f73e539103609e209578dd8a05c88244dab
[modify] https://crrev.com/8df2c258de161b7b5c555989d5262ff125e62c7e/src/main/resources/static/chromium-behavior.html

Fix is submitted but not copybara'ed yet. Waiting for https://chromium-review.googlesource.com/c/infra/gerrit-plugins/chromium-behavior/+/986674 to be submitted before creating a copy CL.

This is live and working. Marking as fixed.

FYI: less hacky API implemented in https://gerrit-review.googlesource.com/c/gerrit/+/169991

Yep, I saw that change and made a note to myself to use it in the plugin.
Thanks for the change!