chrome displays the wrong source map files - google-chrome

After installing the latest dependencies in my React js app built with webpack/webpack-dev-server, chrome is displaying the wrong source map files: showing the content of A.js when I open the file B.js. Any ideea what I might be doing wrong?

For me, upgrading from version 51.0.2704.106 (stable) to 52.0.2743.49 (beta) seems to have fixed it.
This seems to be the relevant Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=611328
TL;DR: Stable will remain broken until Chrome 52 becomes stable, around July 26th, 2016.

Not a solid fix, but I switched to Chrome Canary and now source maps are working as expected.

Related

Why does Google Chrome only displays the first page a pdf file?

I'm facing a problem with Google Chrome. One of my PDF only shows the first page and the rest looks as following:
Example:
First page is displayed normaly.
It recognizes the amount of pages in the PDF.
If I download the PDF, it is completely fine and useable, I even can open it in Chrome and it works fine. The problem doesn't occur on Firefox or Safari.
I'm using Google Chrome Version 85.0.4183.83 (Official Build) (64-bit)
Thanks for your help.
I experienced the same issue (but with another website). After investigation, it appears that this has something to do with SameSite cookies.
You can fix it by setting this flag to Disabled then restart Chrome:
chrome://flags/#same-site-by-default-cookies
Update: Found an issue in the Chromium bug tracker related to this problem:
https://bugs.chromium.org/p/chromium/issues/detail?id=961617
This issue appears to be caused by a conflict between Chrome and Fast Web View pdf optimisation. To fix it you need to turn off the optimisation within your pdf program settings and save the file again (in Adobe products this is located Preferences>Documents>Save Settings - uncheck Save As optimizes for Fast Web View). Pdf files which don't include this optimisation render all pages correctly.

What does bis_skin_checked="1" mean? It's showing on most of my elements when using chromes code source view?

I'm confused I don't know if the latest update of chrome AKA version 73 just integrated this attribute on purpose but I'm getting a strange attribute that I did not added into my web pages and i'm wondering what this means in chrome?
CHROME BROWSER
EDGE BROWSER
Should I be concern with this? It's only showing on Chrome.
There is another Chrome and Firefox plugin that does same, sadly, but probably one of best VPN tools Urban VPN Browser Extension. The solution is same, just deactivate. Btw, those guys have other extensions, haven't tested others.
Just uninstall any type of VPN that you installed in you browser and afterwards bis_skin_checked="1" will removed automatically.
The attribute is added just because of one of an extension of the Chrome Browser you have installed in your Chrome Browser. I also got this attribute added to my HTML when checking in the console. Then I replicate this by deactivating extensions one by one and found it's adding from Hover Over extension.
This problem has happened to me recently. I installed the Urban VPN plugin and after that, I faced this issue. But uninstalling the plugin, the problem is solved.
I've got the SpeakIt! [Version 0.3.20] extension installed for Chrome [Version 74.0.3729.131 (Official Build) (64-bit)] on Windows 10, and I am seeing the same bis_skin_checked="1" when it's enabled. When I disable the SpeakIt! extension, the bis_skin_checked="1" goes away.
This thing append from different Chrome/Mozilla extension.
Disable recent extensions to see the changes(bis_skin_checked="1" goes away
).

Chrome Canary removes Mapbox access token

since a few days I have problems developing a website with a mapbox map using Chrome Canary (Build: 68.0.3409.0) on macOS.
Problem:
Mapbox is sending requests with a query param access_token=XXXX this param gets a special treatment by Chrome Canary resulting in access_token=anonymized. Therefor mapbox is denying my request.
Screenshot from DevTools Networktab Screenshot from Console
Localy I can reproduces the problem easily and I also created a JS fiddle (https://jsfiddle.net/LiquidSky/xr4rq9zw/) demonstrating the problem, however the offical mapbox examples work fine.
I have no adblocker or stuff installed, just the usual webdev tools.
Question:
Now I wonder if this is related to some security feature coming up in chrome or if this might even be a bug, for which I should open a bug ticket?
Thanks for every info :-D
Kind regards Nico
SOLUTION: Disable Ghostery
Did you get anywhere with this? I have the exact same issue in stable chrome.
It only seems to have caused me issues in the past week or 2 though

GoogleMaps 3.7 map displays blank in IE

this page, which worked fine for the last couple of years, now displays a blank map, apparently since 15 May 2012, when 3.9 was released.
Following the release of version 3.9, applications requesting 3.6 are served 3.7, which seems to be the cause, but I can't see what I'm doing wrong.
I've developed a squint from re-reading the code, but I can't see what's amiss. Is there a kind soul who could help?
Thanks in advance
you need to check the settings of your application. Because when you run the web application on IE9 modifies Document mode from IE9 to internet explorer 7. This could be cause by an setting in your IIS or apache depends of web application even in your markup of your application. to replicate the error
Close the IE9 if it's open
Open the browser and open the developers tools f12
Put the url
Check the document mode it's change to IE7

Chrome toDataURI bug

Until a day or so ago, the Canvas2Image JS library and .toDataURI JS method worked in Chrome. http://www.nihilogic.dk/labs/canvas2image/ Now, with Chrome version 19.0.1084.46, if you try clicking Save PNG on the referenced page to download a PNG version of the HTML5 canvas element, it doesn't prompt a download - but generates a MIME type error. Is this intentional - perhaps for security reasons, or a bug? (It continues to work in Firefox.)
It's a bug in Google Chrome v19 as it works fine in v18 and v20. I'm sure it'll be fixed soon.