Unreviewed code in Browser::SetWebContentsBlocked |
||
Issue descriptionIn 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
,
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!
,
Oct 24 2016
There doesn't seem to be any obvious regression, so I'm going to proceed with removal.
,
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
,
Oct 26 2016
Rather than removing (which seems to cause tests to fail), I fixed this. Calling this done. |
||
►
Sign in to add a comment |
||
Comment 1 by thestig@chromium.org
, Oct 24 2016