Duplicated tab forgets external stylesheet charset if dev tools have been opened
Reported by
tristanb...@gmail.com,
Feb 11 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36 Steps to reproduce the problem: 1. Open demo.html with demo.css in the same directory 2. Open the dev tools, eg by pressing command+option+i 3. Right click on the active tab and select "Duplicate" What is the expected behavior? The newly created tab interprets content using the same character set as the source tab. What went wrong? The newly created tab interprets the external stylesheet using a different character set, resulting in incorrect characters displayed. Did this work before? N/A Chrome version: 56.0.2924.87 Channel: stable OS Version: OS X 10.12.3 Flash Version: Shockwave Flash 24.0 r0 - The correct character is displayed if it is in the HTML rather than the stylesheet, including in inline CSS. - The correct character is displayed if the stylesheet explicitly sets its character set with `@charset`. - The bug is still present if you close the dev tools before duplicating, as long as you at some point opened them on the original page.
,
Feb 13 2017
Thanks for the report. I can reproduce this on Linux 58.0.3009.0. After refreshing the duplicate tab, the correct character is restored.
The same bug occurs if I replace the <link> tag with:
var ss = document.createElement('link');
ss.rel = 'stylesheet';
ss.href = 'demo.css';
document.head.appendChild(ss);
Workaround: After opening DevTools on the first tab, turning on "Disable cache (while DevTools is open)" from the settings before duplicating the tab will use the correct character.
Perhaps reusing text from cache is using an incorrect string format?
@dgozman, could you please take a look? Might there be another Blink team that knows about this better?
,
Feb 13 2017
,
Feb 14 2017
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.12.2 using chrome version 56.0.2924.87 and canary 58.0.3011.0. This is regression issue broken in M56.Please find the bisect information as below Narrow bisect:: Good :: 56.0.2924.86 -- (build revision 433059) Bad:: 56.0.2924.87 -- (build revision 433059) Unable to provide tool bisect as the good and bad builds are from branch builds.hence providing manual CL from omahaproxy https://chromium.googlesource.com/chromium/src/+log/56.0.2924.86..56.0.2924.87?pretty=fuller&n=10000 Possible suspect:: https://codereview.chromium.org/2664233003 lushnikov@ Could you please look into this issue,else please route this to an appropriate owner for this issue. Thanks,
,
Oct 30 2017
That's happens because cache is used for the second tab.
,
Oct 31 2017
Respectfully, why won't this be fixed? It remains broken in 62.0.3202.75 on macOS 10.13. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ajha@chromium.org
, Feb 13 2017