I will be working on part (1) above & leave (2) to folks in browser UI team.

Ken: how do I retrain the gpu image tests?

Assign to kbr@ to answer #1

I created a CL not to show the warning infobar for flags which are not in about:flags.
https://chromium-review.googlesource.com/c/chromium/src/+/977252/

This is the first I've heard about this proposal. I'm sorry, but I won't approve any CLs that retrain the GPU tests to expect a 50% white overlay on top. A major goal of the GPU tests is to test what we ship. Adding a transparent white overlay will be hugely confusing to anyone writing or debugging the GPU tests, and will very likely let bugs slip through.

There is a --test-type flag which has been used in https://codereview.chromium.org/1384823002/ and  Issue 537776  to suppress various infobars. That flag could plausibly be used verbatim in order to suppress these infobars.

Ned, assigning this back to you.

kbr@ and I chatted briefly.  To clarify, the proposed overlay idea would be over the top chrome area only, not the content area.  It sounded like that distinction would affect his response here.  I'm not actually sure what retraining is needed (i.e. what breaks with this solution).

For additional clarity, I don't think we can just hide this specific infobar entirely under a test-type flag, as it can be misused in malicious ways.

Yes, sorry for my confusion. As long as the content area is untouched, this seems fine.

However, looking at this failure from  Issue 824779 :

https://ci.chromium.org/buildbot/tryserver.chromium.win/win7_chromium_rel_ng/127541

https://chromium-swarm.appspot.com/task?id=3c63a88280ff6210&refresh=10&show_raw=1

Look for "see http:" in the logs. They lead here:

http://chromium-browser-gpu-tests.commondatastorage.googleapis.com/view_test_results.html?1bfb96c9d43620c6aa0222ed5a718c7bf59032cd_win7_chromium_rel_ng_telemetry

The generated images clearly show a shadow at the top of the content area that wasn't there before. I would like that to be removed. If it were, then the pixel tests would not require rebaselining. Can that be fixed?

Peter: can I reassign to you to fix the shadow?

Unfortunately, I have no engineering time available for at least the next six months.

I don't know why you'd be getting a shadow with one infobar and not another.  You'll need to investigate why that's happening.

Honestly, I don't really think you should be using --enable-automation at all if you don't want its main effects.  If you need it anyway, fine; but otherwise we should either make whatever flags you are using map to the as-yet-unimplemented "use overlays instead of infobars and disable infobars" mode, or else add some flag like --perf-test that does that explicitly, or make --disable-infobars do that and have you use that.

I am not familiar with C++ chrome ui code. So leave this bug available for now.

#9: we need to rely on --enable-automation until issue 825873 is addressed. I highly suspect that addressing issue 825873 will be very slow/difficult process, hence using --enable-automation flag even if it has some side effects is the best way for now.

By "investigate" I mean "I don't know what's causing the shadow because the screenshot clips out what's actually above that".  You don't have to debug the code, just run things manually enough to know what's causing a shadow in one case and not another.

I still don't understand what bug 825873 means, nor do I understand what you're "relying on" here related to that bug.  I thought this bug was about finding a way to avoid showing an infobar for --ignore-certificate-errors-spki-list, which sounds unrelated to anything I can understand bug 825873 to be about.

#11: Peter, if we don't rely on --enable-automation to show warning over the top chrome area and disable the infobar, then we need to rely on --devtool-port to do that.

That is the basic of issue bug 825873: making sure any time browser is started with --devtool-port enabled, we show the warning over the top chrome area and disable the infobar.

So you're saying Telemetry tests always pass --devtool-port today?  And that that can be used to control the browser in malicious ways?  And we have no UI that warns users of that today?

If so it sounds like the short-term fix for that bug is that --devtool-port needs to show a "browser is being controlled" infobar like --enable-automation does, and changing that to be an overlay instead of an infobar is still relegated to a long-term fix.  Separately, it seems like you want both of these flags to disable _other_ warning infobars, as well as infobar animations.

None of these changes seem like they call for --enable-automation.  What is the non-security urgent problem you're trying to fix on this specific bug that's making you suggest adding --enable-automation now?

#13: you're correct. That's what issue 825873 about.

The urgency on fixing this specific bug is mostly to make sure people don't have to deal with false perf alert anytime they work on infobar UI. If you have more insights that it doesn't happen very often & this bug is not very urgent, I guess we can wait for the real fix in issue 825873

Narrowing.  This bug is now only about the issue of getting other infobars (e.g. for --ignore-certificate-errors-spki-list) when trying to run Telemetry tests, which interfere with perf.  Other issues, like having UI for these cases or what that UI should be, are covered on bug 818483 and bug 825873.

If all Telemetry tests already already pass --devtool-port, my proposal is: --devtool-port should disable other infobars.  We might get this for free if both the above bugs are fixed.

***Mass UI Triage***