this worked before https://docs.google.com/document/d/1I_LQ0PNxtrEQWmBtZfzWUhVxIbrxA1Z9SrdHyJldA4k/edit

Dave - Given the recent change in the PolyGerrit team I'm expecting it might be slow to fix this issue. Do you think we should roll back the bundled plugins for Chrome? I'm assuming that will fix this issue as that's the biggest PolyGerrit change I know of that feels related. Asking since I know you did the rollout itself.

I would at least give Ole a chance to chime in, but yeah I'm guessing a rollback is what will happen. Perhaps even have Ole perform it so he can learn now.

+nodir

I took a quick look at what's going on in Firefox, and looks like there's an runtime exception when loading in Firefox:
> TypeError: a.$ is undefined

And it looks that there are multiple a.$.client references in the bundle, originally something like "this.$.client"

I remember Nodir was troubleshooting this.$ usage during intialization, maybe that's somewhat related?

buildbucket code was cleaned up from "this.$.client". The code that you've found is in tricium, it also has this.$.client. +qyearsley

however, how does this explain the behavior? Could one plugin screw up all other plugins? That might be a bad side effect of bundling. If that's the case, it should be fixed, IMO.

Sorry for the delay. Ole and I have found some time and investigated the issue.

We could reproduce this with Firefox on Mac getting the same exception.

We also got to the same conclusion that the exception is coming from the tricium plugin.

Does anyone know when this was last working? Looking at rapid/polygerrit we had releases at:
Mon Jan 14
Tue Jan 8
Wed Jan 2
Thu Nov 15

Since Jan 2 there was no change to Polygerrit that could have caused this issue.

If we assume that the Nov 15 release was still working, then the only culprit would be Viktar's https://gerrit-review.googlesource.com/c/gerrit/+/208552

Since we are still ramping up on Polygerrit we need some help and input:

1. What is the impact of this issue? All of Chrome team cannot do code reviews with Firefox? How much of an issue is that?

2. Is it likely that a rollback to the state of Nov 15 makes users more happy than keeping the current release?

3. Can we leave fixing the bug to the Tricium maintainers or do we also have responsibility for fixing this?

4. Can someone explain the problem of using this.$ during initialization and what could have changed that the Tricium plugin does work anymore, although it did before?

can we verify this hypothesis by disabling tricium on canary (instant change)?
the "this.$.client" was in tricum since very beginning, aug 2017 https://chromium-review.googlesource.com/c/infra/gerrit-plugins/tricium/+/625965/6/src/main/resources/static/tricium-view.js#70
what has changed recently is the plugin deployment mechanism

we should also check the hypothesis "this was triggered by bundled plugins" by temporarily disabling bundles on canary (instant change). jrn did this once for me.

1. Impact is unclear, probably small: the behavior was noticed by an external developer

2. It will make at least 3 persons happy, see number of stars in crbug.com/855247

3. This depends on experiments above. In general, I think one plugin shouldn't be able to screw up all others (cascading failure), but only itself

4. this.$ may be undefined during initialization, due to polymer's async initialization. See above, tricium wasn't changed.

Comment 10 accidentally deleted; anyway what I said was disabling tricium plugin on canary sounds good to me, and testing both that and checking whether it's related to bundled plugins both sound like reasonable things to test, although I'm not sure how to do either, can a PolyGerrit team member take this bug?

I have verified on canary that disabling bundling and disabling tricium plugin each fixes the problem.

Given the small impact I assume that the Chrome team wants to keep plugin bundling enabled.

Not using this.$ during initialization is a problem the tricium plugin developers would have to fix.

Moved issue gerrit:10291 to now be issue chromium:923301.

brohlfs, i think it is still a polygerrit problem that one plugins can ruin all the others. It is cascading failure.

Right, so I think the particular fix for Tricium here is to copy over new the oauth client code from the buildbucket plugin -- and we should file a new bug for the cascading failure problem that one plugin can break the others?

SGTM