I'd like to know why base64 images are mangled in Chrome's dev tools Watch values:
When I right click on the underlined value -> "copy value" Chrome decides to remove a GREAT part of the original base64 code, and to add "..." in between, destroying the base64 encoding
After making a text diff between what I've obtained from Chrome dev tools and the base64 data that reaches the server and I found there was a huge part of the text missing on what Chrome shows as the value and the infamous "..." (indicating that there should be more code in between i guess) that should't be there either
So What should I do to be able to retreive the proper value of a base64 image on Chrome dev tools?
Related
A customer of ours using our software has generated a letter.
Our software converts it to a PDF and then displays it to them in a preview window.
This PDF shows correctly on every other computer that we have tested on, but for them, they have an experience of blotchy text. Some letters are not there, some have been cut in half.
It's worth noting, but when they download the pdf and open it in Chrome in full, it shows without issue.
(I've had to redact personal information, but there should be enough to get a good idea)
Has any one seen this occur.
Chrome 105.0.0.0 - Windows 10
Try this, turn off accelerated 2D canvas rendering in Google Chrome with the following steps:
In Google Chrome, go enter chrome://flags in the address bar and press enter.
In the search bar, type accelerated 2d canvas
Change the setting from "Enabled" to Disabled
Click Relaunch
Source
I built a PDF in Illustrator, and am linking to it from a web page. It looks fine in SumatraPDF and in the Windows preview pane, but the browser renders this (just so you know, this is not how I want it to look)
Is this because I have font embedded? The only thing that I want to have happen with this is for a couple links on it to be clickable; otherwise, I'd convert it all to outlines. Is there something I need to do here that I haven't done?
EDIT: Here's a weird update about this. The browser follows the link embedded in the pdf when I click it. So it has the right data, but the wrong presentation apparently.
I'm assuming you are/were using either the Dev or Canary channel of Chrome. There was an experiment running in both channels that was causing this, which has since been reverted in Canary but is still affecting Dev 59.0.3053.X. For the more technical; this experiment enabled the PDFium code to use Skia to render paths instead of Anti-Grain Geometry and caused this font gibberish.
Here is the link to the bug report:
https://bugs.chromium.org/p/chromium/issues/detail?id=705039
UPDATE: This was fixed in the Dev Channel with update 59.0.3071.X
I noticed strange behaviour for google chrome.
I have web application based on java spring-mvc framework.
In head tag <meta charset="utf-8">is set.
For each page response headers return Content-Type:text/html;charset=UTF-8
In IE 8,9,10,11 and FF if user changes encoding in browser's settings to KOI8-R and then goes to another page inside domain - browser encoding will be automatically returned to UTF-8.
BUT in google chrome in same case KOI8-R will be present even if we go to other pages inside domain.
Is it expected behaviour for Chrome? Maybe it is some kind of bug?
Chrome doesn't like to use UTF-8 by default so you have to do:
Click the Chrome menu on the browser toolbar.
Select "Tools"
Select "Encoding".
Pick one "Unicode (UTF-8)" from the menu of encodings
To make the client do this by default you would probably have to write some script but I'm afraid I can't help you out there.
How do I get Chrome to display a text file containing backspace characters?
I have a static text file on a server that contains backspace characters (ASCII code 08), and when I navigate the file's URL in Chrome (or Safari), the browser downloads the file to a folder instead of viewing the file's text in the browser window.
I've confirmed that the Content-type header is sent correctly, and if I remove the backspace characters, it works correctly again and displays in the browser.
I don't care if the browser shows an odd glyph or code where the backspace is, or if it dutifully removes characters preceding the backspaces, but I do want to view the file in the browser.
I have control of the server, so I can send custom headers if that helps. Also a browser plugin/extension would be okay.
When I click on an image link right now, Chrome downloads the image instead of opening it.
Even if I right-click and select Open link in new tab Chrome still downloads the image, and I have to go through the extra steps of opening the file for viewing manually.
This feels like a mime-type issue to me, but why would Chrome not recognize "image/png" as a valid mime-type for viewing? All PNG images display just fine in an HTML page.
NOTE: This only happens for PNG images.
The web server is probably serving the image using the image/x-png MIME type. Chrome does not recognise this as an image (as of August 2012 February 2013), hence offers the file as a download.
image/x-png is a legacy MIME type from the days before it got its official name, image/png, in 1996. However, when Internet Explorer uploads an image it does so using image/x-png "for backward compatibility". I believe this was the case up to IE8, and was "fixed" in IE9. If the web server does not correctly handle this (the web server should detect this non-standard MIME type and treat it as image/png), then it may serve up the client-provided MIME type to other users, including to Google Chrome. Additionally, some web sites will serve up all PNGs as image/x-png.
If you're the web developer you should detect incoming image/x-png and treat it as image-png (never serve up image/x-png).
If you're the user report it as a bug and see #kriegaex's answer for a workaround.
#Tom Clift is right, and here is my workaround for it: use Chrome extension Redirector and add a rule replacing the Content-Type header. That's it. :-)
You can use the Chrome extension Undisposition to achieve this.
When you right click on the image you need to select then 'Open image in new Tab' from the drop down and NOT 'Open link in new tab' this will then open the image in a new tab.