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

Issue 739126 link

Starred by 2 users
Status: Untriaged
Owner: ----
Cc:
eseckler@chromium.org
nyerramilli@chromium.org
rbasuvula@chromium.org
█ msrchandra@chromium.org
jmukthavaram@chromium.org
█ ranjitkan@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression : Background color of newly opened tab changes after switching between tabs.

Reported by avsha...@etouch.net, Jul 4 2017 
Chrome Version : 61.0.3148.0 (Official Build) 155b257ae4cf8873f8561ec6a00c61ebec47548a-refs/heads/master@{#484021} 32/64 bit
OS : Windows(7,8,10), Linux(14.04 LTS)

Test URL : https://msu.edu/~urban/sme865/resources/embedded_pdf.html

What steps will reproduce the problem?
1. Launch chrome and navigate to above test URL.
2. Scroll down the page, right click on a link "urban@msu.edu" in the PDF file and select 'Open link in new tab' option (link opens in a new tab).
3. Now switch between both the tabs twice and observe the new tab opened in step 2.

Actual Result : Unnecessarily background color of newly opened tab changes after switching between tabs.

Expected Result : Instead, the background color of newly opened tab should remain white and should not change after switching between tabs.

This is a regression issue broken in ‘M-60’, below is the Manual Regression range and will soon update other info.
Good build : 60.0.3088.0
Bad build : 60.0.3089.0

Note : 
1. Above issue is not seen in Mac(10.11.6, 10.12.3) OS.
2. Unable to reproduce issue in Firefox and Internet Explorer as the right click context menu does not show 'Open link in new tab' option.
Actual_Result.mp4
1.5 MB View Download
Expected_Result.mp4
1.1 MB View Download

Comment 1 by jmukthavaram@chromium.org, Jul 4 2017

Cc: jmukthavaram@chromium.org
Labels: hasbisect
Owner: npm@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 7 & Ubuntu 14.04 using chrome latest Canary#61.0.3147.0.
Manual bisect info:
------------------
Good build : 60.0.3088.0-Revision-468845
Bad build : 60.0.3089.0-Revision-469220

Error observed while running bisect with new python script for the above range,providing bisect with old script:
Bisect tool info:
----------------
You are probably looking for a change made after 469074 (known good), but no later than 469097 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/81fc1da24b2a450637d1f457df2f8f524f7f8b5a..1863716bb870b7b229530f2bdf853322b30178c0

Blink roll:
----------
https://chromium.googlesource.com/chromium/src/+/c0bd6b7a2d7708a6e972d352937e610f2a1e892d

Possible suspect:
----------------
https://pdfium.googlesource.com/pdfium.git/+log/1e5a98afd195..746babded81e

Npm@Could you please take a look & help us to reassign this issue to a right owner if not with respect to your change.

Thanks.!

Comment 2 by npm@chromium.org, Jul 4 2017

Owner: jmukthavaram@chromium.org
My CL is in PDFium (not Blink), which does not affect background color of tabs that are not PDFs. Reassigning back to you.

Comment 3 by thestig@chromium.org, Jul 6 2017

Cc: eseckler@chromium.org
eseckler: This feels a bit like  bug 730848 . Any ideas?

Comment 4 by eseckler@chromium.org, Jul 6 2017

Components: Internals>Compositing
Owner: chrishtr@chromium.org
Yeah, this feels like the background from the first tab is rendered while waiting for a new CompositorFrame from the second tab's renderer. In this particular case (a tab that loads an email address, rather than a page with content), maybe the renderer doesn't submit one, even though it is supposed to.

Provided that regression range is correct, and given the change log, I'd guess that it might be related to https://codereview.chromium.org/2802503002 by chrishtr@. Chris, what do you think?

Comment 5 by chrishtr@chromium.org, Jul 11 2017

Components: -Internals>Plugins>PDF -Internals>Compositing Internals>Views
Labels: -Pri-1 Pri-3
Owner: ----
Status: Available (was: Assigned)
Yes, my commit technically caused this. However, mailto links are special external links, and do not actually spin up a corresponding Blink instance. I'm not so sure this is worth fixing. Leaving
unassigned for now.
Project Member

Comment 6 by sheriffbot@chromium.org, Jul 12

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Comment 7 by khushal....@etouch.net, Nov 14

Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
Update:

***Mass UI Triage***

Issue is still reproducible on Windows (7, 8, 10) and Linux (14.04 LTS) using latest canary #72.0.3609.3.

Please refer the attached screen-shot.

Thank You!
739126.mp4
1.4 MB View Download
►

Sign in to add a comment