New issue
Advanced search Search tips

Issue 883984 link

Starred by 2 users
Status: Verified
Owner:
braveyao@chromium.org
Closed: Sep 19
Cc:
mfo...@chromium.org
m...@chromium.org
taku...@chromium.org
powerb@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Incognito mode tab mirrors the wrong tab. The non-incognito mode tab gets mirrored instead

Project Member Reported by dbbrooks@chromium.org, Sep 13 
Chrome Version: 71.0.3551.0
OS: Mac, Win
MR: 7118.910.0.0

Happens every time.

What steps will reproduce the problem?
(1) Go to any site, for example nytimes.com
(2) Open an incognito tab to google.com and cast the tab to a Chromecast device.

What is the expected result? The incognito tab (google.com) should be mirrored to the receiver.

What happens instead? The non-incognito mode tab gets mirrored to the receiver.

Internal feedback ID: 85659417025

Comment 1 by dbbrooks@chromium.org, Sep 13

Labels: ReleaseBlock-Stable
Owner: braveyao@chromium.org
Status: Assigned (was: Untriaged)
braveyao@, miu@chromium.org (Yuri) thought you'd be the right person to take a look. He noted that it's prob related to the tab capture extension API change that gets the currently active tab.

Comment 2 by mfo...@chromium.org, Sep 13

Labels: -ReleaseBlock-Stable ReleaseBlock-Beta
This is a must-fix for M71. There are privacy implications to mirroring the wrong tab.

Comment 3 by braveyao@chromium.org, Sep 13 

So we should use back "chrome::FindAnyBrowser(Profile::FromBrowserContext(browser_context()),
                             include_incognito_information());", but not chrome::FindLastActiveWithProfile() for tabCapture. Is that right?

Comment 4 by mfo...@chromium.org, Sep 13 

The behavior should remain identical to that in existed in M70.  The API should capture the active tab for the active window/profile.  Ideally it would take the tab id, since we know what tab requested capture from MR, but the API doesn't seem to allow that.
Project Member

Comment 6 by sheriffbot@chromium.org, Sep 17

Cc: mfo...@chromium.org
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 7 by bugdroid1@chromium.org, Sep 19 

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

commit 6b1291f72ef6219990d523fa8f0c7e264469a89c
Author: Weiyong Yao <braveyao@chromium.org>
Date: Wed Sep 19 16:24:22 2018

tabCapture: restore the modified logic in capture()

In another cl, the logic in capture() was modified according to the
review comments, which causes the problem in  crbug.com/883984 .

This cl is to restore the logic in capture() as before.

Bug:  883984 
Change-Id: I0c8684c7611fd75f37ce9d3b12c2dc8290668534
Reviewed-on: https://chromium-review.googlesource.com/1225974
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Yuri Wiitala <miu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592432}
[modify] https://crrev.com/6b1291f72ef6219990d523fa8f0c7e264469a89c/chrome/browser/extensions/api/tab_capture/tab_capture_api.cc

Comment 8 by braveyao@chromium.org, Sep 19

Status: Fixed (was: Assigned)

Comment 9 by dbbrooks@chromium.org, Sep 27

Status: Verified (was: Fixed)
verified with 71.0.3559.6
►

Sign in to add a comment