Fixed
Status Update
No update yet.
Comments
dt...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Blink>Loader Blink>SVG]
[Monorail components: Blink>Loader Blink>SVG]
jh...@chromium.org
[Empty comment from Monorail migration]
ph...@chromium.org
Not Reproducible:
------------------------
#84.0.4147.89 using Windows 10 and able to see the all icons while enable/disabled cache.
@Reporter: Could you please check the attached screenshot and let us know if anything missed here.
------------------------
#84.0.4147.89 using Windows 10 and able to see the all icons while enable/disabled cache.
@Reporter: Could you please check the attached screenshot and let us know if anything missed here.
st...@niit-tech.com
[Comment Deleted]
st...@niit-tech.com
[Comment Deleted]
st...@niit-tech.com
Hi Phanindra,
If you, with the dev. tools open, right click on the reload icon and choose "empty cache and hard reload" then the icons don't work. After unchecking "Disable cache" under Networks tab and you refresh again the icons appear because then they come from browser cache. If you acccess the SVG file there is no issues. The problem is when Chrome tries to render it.
If you, with the dev. tools open, right click on the reload icon and choose "empty cache and hard reload" then the icons don't work. After unchecking "Disable cache" under Networks tab and you refresh again the icons appear because then they come from browser cache. If you acccess the SVG file there is no issues. The problem is when Chrome tries to render it.
ed...@gmail.com
I attach a short video reproducing the issue. We're able to reproduce it in different machines on our end.
Only on one machine wasn't reproducible, that's why we found that was something related to the Chrome version, this machine had v83 and the issue wasn't reproducible. After updating Chrome to the latest version the issue appeared.
Only on one machine wasn't reproducible, that's why we found that was something related to the Chrome version, this machine had v83 and the issue wasn't reproducible. After updating Chrome to the latest version the issue appeared.
[Deleted User] <[Deleted User]>
Thank you for providing more feedback. Adding the requester to the cc list.
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
For more details visit
[Deleted User] <[Deleted User]>
I'm experiencing the same issue immediately after upgrading to 84 from 83. Also happens in the latest edge (84) which is also chromium yes?
When cached all icons show up correctly. But after a hard refresh, or with caching disabled in the network tab. Many icons are not rendered. My reproduction steps are the same as the video above.
When cached all icons show up correctly. But after a hard refresh, or with caching disabled in the network tab. Many icons are not rendered. My reproduction steps are the same as the video above.
sc...@chromium.org
I'm not aware of any SVG changes that would affect cache behavior. So removing that component for now.
[Monorail components: -Blink>SVG]
[Monorail components: -Blink>SVG]
pd...@chromium.org
[Empty comment from Monorail migration]
kr...@gmail.com
We are experiencing this as well. SVG icons in various places in our web app disappeared, and we do not see this issue in previous versions of the browser. A refresh sometimes helps, but not always. I just cleared my cache, closed Chrome and returned to find the icons in both places gone again. Without the buttons, it is preventing our customers from proceeding/completing time sensitive workflows, while using our software in Chrome. Thanks.
pd...@chromium.org
I can reproduce and will bisect.
pd...@chromium.org
pd...@chromium.org
Updating labels, as this is likely to affect all platforms.
[Monorail components: Blink>SVG]
[Monorail components: Blink>SVG]
tr...@skinport.com
We're having the same issue on https://skinport.com - Only happening with Chrome 84. I just reproduced it by switching between Page e.g. https://www.youtube.com/ => https://skinport.com => https://www.youtube.com/ => https://skinport.com (after some time the Logo dispear on our site)
pd...@chromium.org
[Empty comment from Monorail migration]
sc...@chromium.org
Adding comment left on 1107921:
It appears that this may actually be an issue with React and recent changes to HTML Imports/Shadow DOM. It appears to work reliably when the markup exists already on the page when it is loaded as well as when the "href" value is changed the to point to another SVG symbol (even while the resource is still loading).
It appears that this may actually be an issue with React and recent changes to HTML Imports/Shadow DOM. It appears to work reliably when the markup exists already on the page when it is loaded as well as when the "href" value is changed the to point to another SVG symbol (even while the resource is still loading).
[Deleted User] <[Deleted User]>
I am seeing this issue as well and I am not using React for my current project.
We have our HTML rendered server-side
I see that when the icon is pulled from cache, it shows up correctly, however, if not pulled from cache, the svg icon is missing
Here is a screenshot of view as source so you know that this is not rendered client-side
We have our HTML rendered server-side
I see that when the icon is pulled from cache, it shows up correctly, however, if not pulled from cache, the svg icon is missing
Here is a screenshot of view as source so you know that this is not rendered client-side
pd...@chromium.org
Adding ReleaseBlock-Stable because this bug seems to affect many users (28 stars in 2 days).
pa...@radio-canada.ca
If it can help. We are also having this issue with one of our SVG spritesheet. https://ici.radio-canada.ca/unit/app/assets/svg/rc_icons.svg
The first few icons will properly load when the file is not in cache. Then after a certain breaking point the other icons will be ignored. Removing some of the first symbols will make icons declared further down the file appear. Our icons are inserted in alphabetical order, so our Document icon will show up, but not the Play icon.
The first few icons will properly load when the file is not in cache. Then after a certain breaking point the other icons will be ignored. Removing some of the first symbols will make icons declared further down the file appear. Our icons are inserted in alphabetical order, so our Document icon will show up, but not the Play icon.
ey...@gmail.com
We have the same issue like described above. The first 20-22 sprites are displayed if file is not in cache. The rest is not visible. You can check www.lights.co.uk . We are also not using React.
ja...@chromium.org
I think I've diagnosed the problem and have a tentative fix, but I haven't sorted out a regression test yet.
jo...@gmail.com
There seems to be a size threshold as alluded to in #22 -- the following page _should_ exhibit the problem with glue_icons.svg but doesn't, maybe because it's only 3.9 kB.
https://apps.google.com/meet/
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/48275f119b44f18f82eaeb89ee78cca290d8363f
commit 48275f119b44f18f82eaeb89ee78cca290d8363f
Author: Nate Chapin <japhet@chromium.org>
Date: Sat Jul 25 02:26:04 2020
Don't prematurely initialize a Document for an external SVG resource
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2316805
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#791315}
[modify]https://crrev.com/48275f119b44f18f82eaeb89ee78cca290d8363f/third_party/blink/renderer/core/BUILD.gn
[modify]https://crrev.com/48275f119b44f18f82eaeb89ee78cca290d8363f/third_party/blink/renderer/core/svg/svg_external_document_cache.cc
[modify]https://crrev.com/48275f119b44f18f82eaeb89ee78cca290d8363f/third_party/blink/renderer/core/svg/svg_external_document_cache.h
[add]https://crrev.com/48275f119b44f18f82eaeb89ee78cca290d8363f/third_party/blink/renderer/core/svg/svg_external_document_cache_test.cc
commit 48275f119b44f18f82eaeb89ee78cca290d8363f
Author: Nate Chapin <japhet@chromium.org>
Date: Sat Jul 25 02:26:04 2020
Don't prematurely initialize a Document for an external SVG resource
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#791315}
[modify]
[modify]
[modify]
[add]
ja...@chromium.org
This should be fixed in today's Canary (version 86.0.4214.0 or later). If you have a chance to install the canary (https://www.google.com/chrome/canary/ ) and verify that your issue is resolved, I would be grateful.
ju...@gmail.com
Appears to be fixed in 86.0.4214.0, when would this be released?
ey...@gmail.com
On canary everything seems to work properly
ja...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
This bug requires manual review: M85's targeted beta branch promotion date has already passed, so this requires manual review
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:https://chromium.googlesource.com/chromium/src.git/+/master/docs/process/merge_request.md#when-to-request-a-merge
- Chrome OS:https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), bindusuvarna@(iOS), dgagnon@(ChromeOS), srinivassista@(Desktop)
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:
- Chrome OS:
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), bindusuvarna@(iOS), dgagnon@(ChromeOS), srinivassista@(Desktop)
For more details visit
ja...@chromium.org
1. Does your merge fit within the Merge Decision Guidelines?
Yes, it's RB-S.
2. Links to the CLs you are requesting to merge.
https://chromium.googlesource.com/chromium/src.git/+/48275f119b44f18f82eaeb89ee78cca290d8363f
3. Has the change landed and been verified on master/ToT?
Yes, see comments 27 and 28.
4. Why are these changes required in this milestone after branch?
The feature in question (SVG resources from external SVG documents) is not a terribly common one, but this regression caused those SVG resources to not appear relatively frequently when it is used. This results in user-visible bugs.
5. Is this a new feature?
No.
6. If it is a new feature, is it behind a flag using finch?
N/A
Yes, it's RB-S.
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
Yes, see comments 27 and 28.
4. Why are these changes required in this milestone after branch?
The feature in question (SVG resources from external SVG documents) is not a terribly common one, but this regression caused those SVG resources to not appear relatively frequently when it is used. This results in user-visible bugs.
5. Is this a new feature?
No.
6. If it is a new feature, is it behind a flag using finch?
N/A
ja...@chromium.org
[Empty comment from Monorail migration]
sr...@google.com
Merge approved for M85 branch:4183 please merge your changes asap
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/cd88ec17089fc85b823444abf026b9311ab8ec09
commit cd88ec17089fc85b823444abf026b9311ab8ec09
Author: Nate Chapin <japhet@chromium.org>
Date: Tue Jul 28 23:00:33 2020
Don't prematurely initialize a Document for an external SVG resource
(cherry picked from commit 48275f119b44f18f82eaeb89ee78cca290d8363f)
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2316805
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#791315}
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2324490
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/branch-heads/4183@{#1011}
Cr-Branched-From: 740e9e8a40505392ba5c8e022a8024b3d018ca65-refs/heads/master@{#782793}
[modify]https://crrev.com/cd88ec17089fc85b823444abf026b9311ab8ec09/third_party/blink/renderer/core/BUILD.gn
[modify]https://crrev.com/cd88ec17089fc85b823444abf026b9311ab8ec09/third_party/blink/renderer/core/svg/svg_external_document_cache.cc
[modify]https://crrev.com/cd88ec17089fc85b823444abf026b9311ab8ec09/third_party/blink/renderer/core/svg/svg_external_document_cache.h
[add]https://crrev.com/cd88ec17089fc85b823444abf026b9311ab8ec09/third_party/blink/renderer/core/svg/svg_external_document_cache_test.cc
commit cd88ec17089fc85b823444abf026b9311ab8ec09
Author: Nate Chapin <japhet@chromium.org>
Date: Tue Jul 28 23:00:33 2020
Don't prematurely initialize a Document for an external SVG resource
(cherry picked from commit 48275f119b44f18f82eaeb89ee78cca290d8363f)
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#791315}
Reviewed-on:
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/branch-heads/4183@{#1011}
Cr-Branched-From: 740e9e8a40505392ba5c8e022a8024b3d018ca65-refs/heads/master@{#782793}
[modify]
[modify]
[modify]
[add]
go...@chromium.org
M85 is already in Beta and Stable promotion coming soon. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If yes, please make sure to land the fix & request a merge to M85 ASAP, so the change gets enough beta coverage. Thank you.
ju...@gmail.com
Do you guys know when this will be released? our site first load looks absolutely broken, this is having a big impact in our site. I see that version 85 is planned for August 25th and honestly this is too much time for us to live with this issue.
Thanks.
Thanks.
pd...@chromium.org
This has high impact (58 stars in 8 days) and the patch is a one-liner, but it is likely we have long missed the M84 train. Krishna, do you have guidance about M84 here?
Nate, is there any kind of workaround for impacted sites? I'm thinking cache headers or script snippets to pre-load before rendering.
Nate, is there any kind of workaround for impacted sites? I'm thinking cache headers or script snippets to pre-load before rendering.
ey...@gmail.com
we had roughly 900K sessions with v84 so far....so many users cant see conversion relevant icons. the bug is very critical for us. we are now inlining some of the icons. would be great to have better workaround
st...@gmail.com
This is having a big impact for our first time visitors when the first impression is to see our page all broken, please fix this asap, thanks.
de...@ramius.net
I haven't found a workaround to avoid this issue. Anyone else?
ja...@chromium.org
This fix should be available in the M85 beta soon. Assuming it doesn't show any problems, I'll request merge to the next M84 stable respin.
go...@chromium.org
[Empty comment from Monorail migration]
he...@gmail.com
This issue is too critical for our customers after they upgrade to Chrome 84. Could you please fix it and release it in next hotfix of Chrome 84?
jq...@gmail.com
We have this issue too, this is the workaround we implemented
const svgs = document.querySelectorAll('svg');
svgs.forEach(item => {
const content = item.innerHTML;
item.innerHTML= content;
});
not the best, but seems to work just fine
const svgs = document.querySelectorAll('svg');
svgs.forEach(item => {
const content = item.innerHTML;
item.innerHTML= content;
});
not the best, but seems to work just fine
ao...@gmail.com
having the same issue
ju...@gmail.com
Nice one #45
we'll simplify it as:
document.querySelectorAll('svg').forEach(x => {x.innerHTML = x.innerHTML});
Thanks!
we'll simplify it as:
document.querySelectorAll('svg').forEach(x => {x.innerHTML = x.innerHTML});
Thanks!
fb...@gmail.com
I can confirm bug reports here. It's a major issue for our application that relies on showing large number of dynamic status icons.
Also I believe this bug more clearly affects larger sprites, smaller sprites can falsely appear to work. Please include a large sprite (megabytes) in your tests to ensure this.
I also think this is hot-patch level bug and hope for a near term v84 update.
Thanks for working on this!
Also I believe this bug more clearly affects larger sprites, smaller sprites can falsely appear to work. Please include a large sprite (megabytes) in your tests to ensure this.
I also think this is hot-patch level bug and hope for a near term v84 update.
Thanks for working on this!
ey...@gmail.com
Nice one #47/45...is working for me....thanks for this and of course for everyone who has worked to fix this bug.
ed...@gmail.com
Hi all,
Thanks to everyone for reporting the issue, sharing a workaround (which works for us too) and of course for fixing it.
Thanks to everyone for reporting the issue, sharing a workaround (which works for us too) and of course for fixing it.
sr...@google.com
This bug is marked as RBS for M85. M85 has been promoted to beta. Please help review this bug if this indeed should block the stable release for M85, if not please remove RBS label, If it is a RBS , please help get a fix ready for merge to M85 asap so we can bake the fix on beta channel asap.
Beta release happens every wednesday and beta RC gets cut on Tuesday afternoon 3pm PST. Please help get the fixes landed and verified on canary so that the changes can be merged in time for beta release.
Beta release happens every wednesday and beta RC gets cut on Tuesday afternoon 3pm PST. Please help get the fixes landed and verified on canary so that the changes can be merged in time for beta release.
fb...@gmail.com
Here's a slightly larger SVG sprite with symbol ID-paths that I hope you can include in your tests to verify this bug. We use dynamically generated icons (#IDs) via <use> tags that xlink:href to the sprite.
As said, since we dynamically chose icons in generated html the workaround to scan and nudge innerHTML is not quite practical for us.
When can we know if this patch reaches a near-term v84 Stable? If it is not included until v85 at end of August we might become forced to "hack" though.
As said, since we dynamically chose icons in generated html the workaround to scan and nudge innerHTML is not quite practical for us.
When can we know if this patch reaches a near-term v84 Stable? If it is not included until v85 at end of August we might become forced to "hack" though.
ma...@gmail.com
Hello, we have the same problem. I've just tested it on Version 85.0.4183.48, it seems to work fine on beta. Looking forward see to the release
jo...@gmail.com
Our company is launching a large website redesign soon and we are experiencing this icon issue. Unfortunately our developers weren't able to get the proposed workaround above working, but we have verified that it is resolved with Chrome Canary (Version 86.0.4217.2 ).
We are trying to determine if we should continue our efforts of finding a fix and implementing during code freeze or if there is any chance this issue can be included as a patch before the Version 85 release? Releasing the new website with broken icons for Chrome is not an option. Thanks!
Attached is our large SVG sprite in case it is helpful.
We are trying to determine if we should continue our efforts of finding a fix and implementing during code freeze or if there is any chance this issue can be included as a patch before the Version 85 release? Releasing the new website with broken icons for Chrome is not an option. Thanks!
Attached is our large SVG sprite in case it is helpful.
le...@gitlab.com
A more stable workaround for us rather than the ones mentioned above has been employing the library svg4everybody which was polyfill for older browsers: https://github.com/jonathantneal/svg4everybody . It essentially inlines the referenced SVG. It worked better for us than the innerHTML Solution because it also fixes dynamically loaded icons and the innerHTML solution wasn’t working for one of our engineers on Linux.
Here you can see our implementation:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38304
Hope it helps.
Here you can see our implementation:
Hope it helps.
[Deleted User] <[Deleted User]>
ja...@chromium.org
I don't see any crashes on canary from this, so I think we're good to merge to M84.
sc...@firstclasswatches.co.uk
Good afternoon,
Hopefully this can be pushed to a stable build soon, I first noticed the issue on our live site a few weeks ago but assumed it to be a temporary browser error.
We use a large SVG sprite sheet (with xlink href) for the majority of our icons and our main website logo so we are heavily impacted. I have tried the workaround suggested above but it does not appear to work consistently.
Considering this issue was reported 21st July, when should we expect a fix to be live - I appreciate these things take time but a broken image implementation is a serious problem - what if this had been JPEG or PNG images?
Thanks,
Scott
Hopefully this can be pushed to a stable build soon, I first noticed the issue on our live site a few weeks ago but assumed it to be a temporary browser error.
We use a large SVG sprite sheet (with xlink href) for the majority of our icons and our main website logo so we are heavily impacted. I have tried the workaround suggested above but it does not appear to work consistently.
Considering this issue was reported 21st July, when should we expect a fix to be live - I appreciate these things take time but a broken image implementation is a serious problem - what if this had been JPEG or PNG images?
Thanks,
Scott
go...@chromium.org
Approving merge to M84 branch 4147, please merge ASAP. Thank you.
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/4bfda8a87f7f9f505e32d476cc0846df37064184
commit 4bfda8a87f7f9f505e32d476cc0846df37064184
Author: Nate Chapin <japhet@chromium.org>
Date: Mon Aug 03 18:56:43 2020
Don't prematurely initialize a Document for an external SVG resource
(cherry picked from commit 48275f119b44f18f82eaeb89ee78cca290d8363f)
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2316805
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#791315}
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/2333073
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/branch-heads/4147@{#1006}
Cr-Branched-From: 16307825352720ae04d898f37efa5449ad68b606-refs/heads/master@{#768962}
[modify]https://crrev.com/4bfda8a87f7f9f505e32d476cc0846df37064184/third_party/blink/renderer/core/BUILD.gn
[modify]https://crrev.com/4bfda8a87f7f9f505e32d476cc0846df37064184/third_party/blink/renderer/core/svg/svg_external_document_cache.cc
[modify]https://crrev.com/4bfda8a87f7f9f505e32d476cc0846df37064184/third_party/blink/renderer/core/svg/svg_external_document_cache.h
[add]https://crrev.com/4bfda8a87f7f9f505e32d476cc0846df37064184/third_party/blink/renderer/core/svg/svg_external_document_cache_test.cc
commit 4bfda8a87f7f9f505e32d476cc0846df37064184
Author: Nate Chapin <japhet@chromium.org>
Date: Mon Aug 03 18:56:43 2020
Don't prematurely initialize a Document for an external SVG resource
(cherry picked from commit 48275f119b44f18f82eaeb89ee78cca290d8363f)
Bug: 1107442
Change-Id: Ifc0d515e10bb73a3217dd6164aded10731e126ee
Reviewed-on:
Commit-Queue: Nate Chapin <japhet@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#791315}
Reviewed-on:
Reviewed-by: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/branch-heads/4147@{#1006}
Cr-Branched-From: 16307825352720ae04d898f37efa5449ad68b606-refs/heads/master@{#768962}
[modify]
[modify]
[modify]
[add]
kr...@gmail.com
Chromium team, Thanks for the fast turn around and frequent updates. Could you pls expedite the next chrome 84 update or let us know an ETA when the next 84 update scheduled to happen? Thanks again.
am...@google.com
Should be ~Aug 11 to start serving, but could be a bit later if we run into any last minute issues, and it'll take a couple days to ramp up and reach everyone.
pe...@chromium.org
Able to reproduce the issue on reported chrome version #84.0.4147.89 using Linux 16.04, Windows 10 and Mac 10.13.6 as per https://crbug.com/chromium/1107442#c0 https://crbug.com/chromium/1107442#c7 .
Verified the fix on Linux 16.04, Mac 10.13.6 and Windows 10 on latest M-85 #85.0.4183.57 and M-86 #86.0.4222.0.
Attaching screen-casts for reference.
Able to see all the icons.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks..
Verified the fix on Linux 16.04, Mac 10.13.6 and Windows 10 on latest M-85 #85.0.4183.57 and M-86 #86.0.4222.0.
Attaching screen-casts for reference.
Able to see all the icons.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks..
su...@gmail.com
Hi, we are also facing icon missing issue regardless of disable cache. Could you please confirm when will this fix be available. Thank you.
li...@chromium.org
Reply to #64. Thanks for verifying, for M84 you need to use chrome version - 84.0.4147.119 or higher.
Reply to #65. The fix will be available for upcoming releases, Beta(08/05) and Stable (mostly week of 08/10)
Reply to #65. The fix will be available for upcoming releases, Beta(08/05) and Stable (mostly week of 08/10)
pe...@chromium.org
Able to reproduce the issue on reported chrome version #84.0.4147.89 using Linux 16.04, Windows 10 and Mac 10.13.6 as per https://crbug.com/chromium/1107442#c0 https://crbug.com/chromium/1107442#c7 .
Verified the fix on Linux 16.04, Mac 10.13.6 and Windows 10 on latest M-84 #84.0.4147.125.
Attaching screen-casts for reference.
Able to see all the icons.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks..
Verified the fix on Linux 16.04, Mac 10.13.6 and Windows 10 on latest M-84 #84.0.4147.125.
Attaching screen-casts for reference.
Able to see all the icons.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks..
su...@gmail.com
Hi, thank you for your response. Verified in Chrome beta, I am able to see all the icons.
I understand fix will be available in Stable this week. It would be great if you can give us a date. Thanks
I understand fix will be available in Stable this week. It would be great if you can give us a date. Thanks
me...@gmail.com
#68, it looks like it was released today - Version 84.0.4147.125 was just released for me.
ma...@gmail.com
My team is currently on what Chrome is saying is the most recent update (85.0.4183.83) but this issue still persists. I see, based on the comments, that an update for 84 was released to resolve this issue and the ticket is marked as closed, but when will the current version of Chrome see this issue resolved? Downgrading to previous versions is not an option.
fs...@opera.com
In https://crbug.com/chromium/1107442#c64 the fix was verified on 85.0.4183.57, so should be in 85.0.4183.83 (as far as I know...). Could you file a bug for your specific case so that we can analyse it?
ha...@google.com
[Empty comment from Monorail migration]
ha...@google.com
[Empty comment from Monorail migration]
is...@google.com
This issue was migrated from crbug.com/chromium/1107442?no_tracker_redirect=1
[Multiple monorail components: Blink>Loader, Blink>SVG]
[Monorail mergedwith:crbug.com/chromium/1107921 , crbug.com/chromium/1110318 ]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Blink>Loader, Blink>SVG]
[Monorail mergedwith:
[Monorail components added to Component Tags custom field.]
Description
Chrome Version : 84.0.4147.89 (Official Build) (64-bit) (cohort: 84_Win_89)https://www.trafalgar.com/en-nz/tours/t/european-whirl
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Chrome(previous versions): OK
Firefox: OK
Edge: OK
What steps will reproduce the problem?
(1) Navigate to the page with disabled cache on devTools, some SVG icons are missing.
(2) Reload with cache enabled on devTools and all icons are there.
Every time I disable cache and reload the page the icons are missing. The SVG file appears to be downloaded correctly on the network tab.
What is the expected result?
All icons should appear no matter if the svg file is cached or not
What happens instead?
Icnos from svg file are missing if the file wasn't on the cache on page load.
Please provide any additional information below. Attach a screenshot if
possible.
It happens on many if not all the pages, just added the link of one of them. I've also tried with other browsers and the previous version of Chrome and worked perfectly and after the update to v84 the issue started.