In recent versions of Chrome-based browsers, for some reason (probably, not a bug, it's a feature), after debug mode is detached, Chrome leaves this notification:
"Programm started debugging this browser"
Screenshot
Basically, I run this code
let debugee = {tabId: sender.tab.id};
chrome.debugger.attach(debugee, '1.2', ()=>{});
chrome.debugger.detach(debugee);
And see the picture above. Chrome removed this notification on detach until version 80 (or so).
I've found the description of the issue:
https://chromium.googlesource.com/chromium/src/+/HEAD/chrome/app/generated_resources.grd
<!-- DevTools attached infobar -->
<message name="IDS_DEV_TOOLS_INFOBAR_LABEL" desc="Label displayed in an infobar when external debugger is attached to the browser. The label does not disappear until the user dismisses it, even if the debugger is detached, and so should not imply that the debugger must still be debugging the browser, only that it was, and could still be.">
"<ph name="CLIENT_NAME">$1<ex>Extension Foo</ex></ph>" started debugging this browser
</message>
I'm looking for a suggestion on how to clear or disable this message automatically, from the chrome extension.
TL;DR there's no such method.
The new behavior in Chrome is the consequence of an awkward fix for a security problem: a malicious extension can quickly do a lot of damage via chrome.debugger API and no one will know that something even happened if the work was performed in less than say 100ms.
Since a security problem was involved, the old behavior won't be restored, but they agreed the UI should at least reflect the current debugger state, see https://crbug.com/1096262. Their current plan is to auto-close the infobar after being visible for >=5s if the extension has detached and update the buttons/strings to be in sync with state.
A workaround is to run chrome with --silent-debugger-extension-api command line switch. It's a dangerous switch though in the sense that you'll have to be careful not to install a malicious extension that uses debugger permission either right away or upon an update.
Related
Following the instructions in the Chrome blog Prerender pages in Chrome for instant page navigations, I am trying to enable pre-rendering on a website. I have added this snippet just before </body>.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["/Test/1","/Test/2","/Test/3"]
}
]
}
</script>
However, on the latest version of Chrome 108, none of these valid URLs are prefetched or prerendered when opening the page. I can confirm this in the Network tab of Dev Tools, and by following links to the pages which take the usual load time.
In the console, HTMLScriptElement.supports('speculationrules') returns true.
Am I missing something?
I can confirm this in the Network tab of Dev Tools
As the new prerender happens in a separate process (effectively like a background tab) any network calls are not shown in the current page’s DevTools. The Chrome team are working on adding DevTools support.
So here’s a few things to check:
Chrome doesn’t prerender when it’s already using a lot of memory. Try restarting Chrome with just that tab to rule this out.
Make sure you have “Preload pages” ticked in Settings->Privacy & Security->Cookies and other site data
Chrome Canary has a handy experimental setting which shows the reason pre-renders fail worth checking that out. Hopefully that will make it to stable soon.
It’s worth confirming if this is a specific issue to your site, or a general prerendering issue. Checkout the demo linked from that article and let us know if that works
Switching tabs currently cancels any prerenders. So make sure you launch straight from your page.
URL param differences can prevent prerendering being activated as it’s effectively not the same page.
There have been a few bug fixes since 108, so it maybe you’re hitting one of those? Check Dev, Beta, or Canary versions.
There is a “holdback” group of people we randomly select to disable this feature so we can continue to monitor it as it is rolled out, and compare to those not using it. It could be you’re in this group. Unfortunately there’s no easy way to tell this (the Chrome team is working on adding this). Try guest mode to see if that works which is usually the best sign you’re in this group.
Might be able to advise more after you try above steps and let me know.
I've scoured the web (and here) but still can't find detailed information on how to properly debug a website in which Chrome reports is insecure.
no http/https errors in the browser console
used dev tools to find
http: function to prove not exists cleared browser cache tried
incognito mode other browsers report secure
Everything I've read about this exact scenario eventually fixes itself with time. This is not professional to just wait.
I'm simply looking for a way to see exactly what Chrome thinks is insecure so I can fix it. Is this even possible?
I finally found the answer. There is an initially hidden "Security" tab in dev tools that lists all errors Chrome sees.
All I had to do was click the 3 vertical dots in the upper right corner of dev tools and choose "More Tools" submenu and then "Security".
I am experiencing an issue with opening a Microsoft Office Document, using IT Hit WebDAV AJAX library, in latest Chrome 39.0. running on Windows OS. It is a sporadic issue that occurs only in Chrome, and it happens when one opens a document multiple times. Word instance won't start, the page freezes and browser becomes unresponsive, and Chrome suggests killing the page. The only solution is restarting the browser, which solves the issue.
I have tried opening a document in Chrome on Mac OS X, and it is working fine. So are Mozilla and Safari on all operating systems. It seems to be a Chrome + Windows issue only.
Has anyone experienced this issue and is there a fix?
The Microsoft Office plug-in that opens the document displays a warning popup "Some files can harm your computer.", which is a modeless dialog:
If you quickly click on a link that opens the document more than one time the dialog will hide behind the main web browser window. As a result the web browser window is blocked.
You need to switch to that dialog and confirm or reject document opening, otherwise after some time Chrome will ask you if to kill the page or wait.
Note that there is no way to avoid that dialog, this is a built-in MS Office functionality as far as I know.
Chrome will only work good with ITHitWebDAV if the user has got Office 2013 or superior.
Google is blocking all Java applets and NPAPIs now, so good luck with that. I just detect the browser of the user that wants to edit a document, and if it's chrome, I warn him to change to another browser like Firefox with a modal, and that's all.
Very poor support between Chrome and ITHitWebDAV, and no much you can do about it.
With Chrome 32.0.1700.77 the new emulator tab is handy except it's the default tab when I refresh my page.
During my standard development workflow, I constantly refresh the page when I make changes. I usually have the console window open at the bottom of the network or source views. But every single time I refresh the page, the Emulators tab takes focus and I can't see the console.
This is truly annoying since the app will fail because of a simple JavaScript typo, but I can't see the console without clicking one more time (to focus the console tab).
Has anyone found a workaround for this?
Combined with the Chrome Developer Tools unresponsive since update 32.0.1700.76 m issue, I would have to say Google really tripped up this release.
Unfortunately there doesn't seem to be a workaround yet. It looks like there has been a bug reported to Google as found on this thread, but no fix has come about yet.
I think the only way (right now) to prevent the console tab from being hidden when needed is to avoid using the emulator or revert to a previous version of Chrome.
Hopefully a fix comes soon!
It's been a while since this post was made, but I came across the same issue recently. When you have the developer toolbar open, the phone icon beside the "Elements" tab should be blue. Clicking that will disable Emulation.
source: https://groups.google.com/d/msg/google-chrome-developer-tools/g_93_bKmaiA/SdHk0aXdEo4J
This is a question about debugging a project, not about writing the code.
I am on the final stages of developing an HTML5 web app. Fairly last minute, our client tells us it should run on IE8. Since I use the HTML5-canvas in the app, this required the addition of Google Chrome Frame. Once installed and testing, however, IE8's developer console no longer prints any data, and the HTML viewer never loads. Is this a bug? Is there a way to fix it? It will really suck if I need to debug with alerts...
From Google Chrome Frame documentation:
You can use the Web Inspector in GCF just as you would in the Google Chrome browser. To use it, right-click and choose "Inspect Element". Logging is available via the console.log method, and you can set breakpoints and inspect network activity.