New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 658772 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Unreviewed code in Browser::SetWebContentsBlocked

Project Member Reported by a...@chromium.org, Oct 24 2016

Issue description

In my implementation of  issue 629964 , I came across a bug in the implementation of Browser::SetWebContentsBlocked(): it checks to see if a WebContents is the active tab of a browser window, but fails to check to see if the browser window is front in the browserlist. I started work on fixing it, but wanted to make sure I didn't regress the original issue for which that code was added.

That code turns out to be unreviewed.

It was added in r119861, and the diff is at https://chromium.googlesource.com/chromium/src/+/41f022e8bbb57b11bf5a7c71b32a656c4f1d7570%5E%21/#F0 . The function used to be called Browser::SetTabContentBlocked, and you can see that the function gained two lines at its end:

+  if (!blocked && GetSelectedTabContentsWrapper() == wrapper)
+    wrapper->web_contents()->Focus();

The review happened at https://chromiumcodereview.appspot.com/9297043 , and those two lines were not present in that review.

This was nearly five years ago, before there was a CQ, so I consider this a mistake, where a few lines of code meant to be a local patch accidentally got included in the subversion commit.

The problem here is what to do with these lines. Certainly at the time that they were written, they addressed _some_ issue that was going on, but it's unclear what that issue was, or if it's still an issue that needs addressing in this way (as opposed to a different way) or even if the applicable code is still here (this was the era of a GTK interface, and perhaps it was meant for that one).

I'm inclined to remove this code entirely and see what breaks (if anything) but I want to get thoughts.

+ some involved engineers
 
I'm not sure how that happened. I would rule that an accident. Please write what makes sense to you now. If it ends up messing up print preview in some way, I'll deal with the fallout from that.

Comment 2 by a...@chromium.org, Oct 24 2016

I remember the days of juggling multiple svn checkouts, so this being accidental is my best explanation for this, too.

I want to do a quick test to see if removing it causes any immediate obvious issues. If not, I'll proceed with removal. If so, then I'll write up a targeted CL to fix my bug without regressing and will send it out.

Thanks!

Comment 3 by a...@chromium.org, Oct 24 2016

There doesn't seem to be any obvious regression, so I'm going to proceed with removal.
Project Member

Comment 4 by bugdroid1@chromium.org, Oct 26 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/713077b86adca2120992f5432afb2b58a1ff0909

commit 713077b86adca2120992f5432afb2b58a1ff0909
Author: avi <avi@chromium.org>
Date: Wed Oct 26 19:44:04 2016

When unblocking a WebContents, don't bring it to the front if it is not already.

BUG= 629964 ,  658772 

Review-Url: https://codereview.chromium.org/2443383002
Cr-Commit-Position: refs/heads/master@{#427776}

[modify] https://crrev.com/713077b86adca2120992f5432afb2b58a1ff0909/chrome/browser/ui/browser.cc

Comment 5 by a...@chromium.org, Oct 26 2016

Status: Fixed (was: Untriaged)
Rather than removing (which seems to cause tests to fail), I fixed this. Calling this done.

Sign in to add a comment