I've been trying to figure this out from the docs and samples but there just isn't enough there yet (or maybe I'm missing something?).
I want to create a devtools panel but I still want access to the inspected window's dom like I get in content scripts. Right now my option is eval something in the context of the inspected window, but i would really rather not do that if I can avoid it. If I can just use a content script along with my devtools page/scripts that would be idea, but it doesn't seem to be working like I expect that it should - i can't seem to use the background page to send messages between my devtools page and my content script.
Also, is there a way to get those cool dom subtrees to display like they do in the elements panel or in the console along with the awesome hover/highlight feature?
UPDATE
So I can connect to the content script from the panel page by forwarding the tab id of the inspected window and pulling that out in my background page. So I have to do this
// devtools.js
chrome.extension.sendMessage({
'to': chrome.devtools.inspectedWindow.tabId,
'message': 'whatever'
});
and
//background.js
chrome.extension.onMessage.addListener(function(message,sender,callback) {
message.from = sender.tab.id;
chrome.tabs.sendMessage(message.to, message, callback);
});
And my content.js script gets the message just fine ... and i thought that the sender's tab id would work to send things back from the content script, but it doesn't. The background script gets the message but the devtools page never gets it back.
I'm having a bit of trouble figuring out how to properly debug devtools extensions as well. The content script can log to the page's console and the background script logs to the background page that you can inspect from the extensions page, but where does the devtools page log to?
The code I was originally testing works fine now with Chrome 26+ ... I think I was doing something that should have worked but didn't at the time that caused the behavior I was seeing.
#Konrad Dzwinel's comment was very helping on debugging devtools and noting that fact that this method actually should and does work. Thanks!
Just a quick update from 2016 (and Chrome 54+) for anybody who could also struggling debugging DevTools extension:
After adding custom DevTools pane successfully and showing Angular2 app in it, I found that the extension isn't connected to the page DevTools console and sources. Hitting on the page DevTools window F12 as suggested above doesn't work (have no idea if it's Chrome itself of some problems in my system), the page DevTools window is closed. But pressing Ctl+Alt+I on the page DevTools window opened one more DevTools window with the custom pane application sources and console attached.
Related
I have developed an add-on for Firefox and Chrome. It has content scripts. I want to access them in the browser tab's console (on Firefox the Web Console). For example, I want to enter a global variable defined in the content script(s) in the console, and it will output its value.
In Chrome, I can open the console by pressing F12, then navigate to the Console tab in the developer tools. It has a dropbox, right after the filter button, to select which context I am in (page/content script):
In Firefox, how to do the same thing?
The ability to change the context/scope of the Web Console (opened directly with Ctrl-Shift-K or F12 and selecting the Console tab) to that of the content scripts for an extension does not appear to exist. In addition, this capability does not exist in any of the other ways to view a console in Firefox. A bug/RFE should be filed on Bugzilla requesting this functionality; it would be quite useful. You will want the RFE to clearly explain that there should be the ability to switch to the content script context/scope for each frame in the tab (i.e. the top frame and each child frame). This should be the case for both the Console and the Debugger.
NOTE: You can change the console into the context/scope of the iframe's page scripts by selecting the frame from the drop-down menu opened from the frame-selector drop-down:
If this drop-down icon is not appearing for you, go to the DevTools settings and check "Select an iframe as the currently targeted document". However, doing this A) does not switch into the content script context/scope and B) does not work properly with the Web Debugger (testing in the current version of Firefox and Nightly (54.0a1).
Web Debugger
You can use the Web Debugger (Ctrl-Shift-S, or F12 and selecting the Debugger tab) with WebExtension content scripts. The content scripts for the extension are listed in the "Sources" under a moz-extension:// URL. You will need to identify the UUID that is used for the extension. You can view the content of variables, set breakpoints, etc. However, this does not give you the ability to explicitly switch to the context of the child frame. Placing debugger; directives in the JavaScript which is running in the child iframe is ineffective.
Web Debugger debugging content script (in top frame):
Console in background script context
If you were wanting to open a console which was in the context of your WebExtensions' background script, you could do so by clicking on the Debug button for your extension in about:debugging. However, this will not get you access to a console in the content script's context.
Workarounds for seeing variable values in the iframe
For what you need: unambiguously indicating that values are in the iframe context, not the top frame; I see two methods of doing so:
Use console.log() with information prepended that clearly indicates that the script believes it is running in the iframe. For example:
console.log('In iframe', 'foo=', foo);
So that you don't have to have 'In iframe' in every call to console.log() you make, you could create a function that prepends that text to all calls to that function. You could even override the console.log() function so your code still just calls console.log().
However, this only tells you that your code thinks that it is running in the iframe. Part of what you may be debugging is your content script code detecting that it is in an iframe.
This method does not indicate with certainty that the reported values are actually in the iframe.
Store values into the DOM using Element.dataset, or other DOM element attributes, and then inspect the DOM for these values. To view these attributes, I find that the DOM Inspector shows these quite clearly:
This method can be used to unambiguously show that the values are ones in the iframe, and exactly which iframe, without relying on the code running in the iframe to accurately determine that it is in an iframe and which iframe it is in.
A simple solution is to just console.log() in the content script and then click the sourcemap link to view the script. As shown below:
It's not yet possible. There is a bug Implement UI for switching context to content script opened (since Nov 2017) for that.
In Firefox Developer Edition, go on "about:debugging" page and click on the "Debug" button beside your add-on to open the dev tools.
If my Google Chrome extension does not have a default_popup as I need to use chrome.browserAction.onClicked.addListenerwhich is not called if the property 'default_popup' is set in mainfest.json file.
Problem
As shown in screen shot given below the inspect popup is disabled which is the key to open the dev. console for the extension.
How to debug?
Open the Extensions page of Chrome (chrome://extensions/), and enable developer mode if you haven't done so already. Click the link next to "Inspect views" to inspect your extension's background page.
Note that your extension's background page is not the same thing as its popup. Inspecting the popup and the background page of an extension that has both will give you two completely different inspectors!
Each html page your extension loads needs a separate devtools instance.
You can find all inspectable views at "chrome://inspect"
If you want to break on uncaught exceptions and the devtools are not opened yet, you can use a function wait_for_devtools to delay your startup function (e.g. after window.onload or document ready)
I am trying to debug a web page in Firefox v42.0 Windows 10, where that web page goes through a proxy server and has code injected into it inline via <script>...</script> (not including a separate .js file) by the proxy server. When I right-click View Page Source, I see the original page plus the code I expect to see injected (and which is actually running). I also see the injected content in the DOM view of the Inspector tab. And it is also visible in the Network Tab in the Response section. However, when I view the same page in the debugger, the injected code is not visible, as if the page were not running through the proxy server.
Furthermore, if I insert a debugger; statement in the injected code, I do hit the breakpoint, but in the Firefox debugger tab it tells me I'm on line 550 of a file with only 173 lines in it according to Firefox. So I can not step through the code.
When I do the same thing in Chrome, I see what I'm expecting, which is the injected code in my page, and I am able to debug this code without problem.
I have cleared my cache to no effect. I looked at the Network tab and everything looks as expected there.
How and why is Firefox not showing me the actual page in the debugger tab (matching what's in View Source or the DOM view), and not letting me step through the injected code?
There are a few bugs in Firefox that can cause this that I've encountered myself:
A local caching issue which can be solved by first closing the dev tools window, hard-reloading the page (Ctrl/Cmd + Shift + R), then opening the debugger again.
Trying to debug a tab in a container, but the source is showing the page as it would be outside a container. See bug 1375036). This particular case should now be fixed.
Similar to the previous point, the debugger source showing you a slighty/completely different document to the one that's actually currently rendered by the browser. This is due to the fact that the debugger does not have access to the original markup & inline script the browser used to render the current page! Apparently designed that way to be memory efficient, but seems to ignore the fact that a developer wants to use the memory for storing the source, because they want the actual source. See bugs such as 1060732, 1149835, and 1472581.
If this is happening to you try debugging in the default/no container, or just do it in Chrome 🙁. If you can't debug in another browser, at least try a fresh profile before you "refresh" (nuke) Firefox as others suggest. You can do this from the about:profiles page (address must be typed manually or bookmarked), or by opening Firefox with the -P flag and creating a new one. To use those flags, run firefox -P --no-remote from a *nix/Mac terminal or C:\Program Files\Firefox Developer Edition\firefox.exe -P --no-remote from the Windows Run dialogue; the --no-remote flag is not required but allows you to run the new profile alongside your main one, and disregard links clicked in other programs.
The below worked for me
Copy url from address bar and close the tab.
Open the url in private mode, the debugger shows the source.
Close private window and open in default mode, the debugger shows the source now.
Try to refresh Firefox:
"Refresh Firefox
Click the menu button and then click help.
From the Help menu choose Troubleshooting Information.
Click the Refresh Firefox button in the upper-right corner of the Troubleshooting Information page.
To continue, click Refresh Firefox in the confirmation window that opens.
Firefox will close to refresh itself. When finished, a window will list your imported information. Click Finish and Firefox will open."
Check this for more information:
https://support.mozilla.org/en-US/kb/refresh-firefox-reset-add-ons-and-settings
I had the same problem. I solved it following these instructions.
I had a similar issue, but this was due to the index page redirecting to a subdirectory. The subdirectory contained the index.html with the javascript include files. The src files only got displayed only when an error occurred. To get around this, I cleared all my cache and I went directly to the subdirectory.
I created a notification window using the Chrome Extension API:
var notification = webkitNotifications.createHTMLNotification("notification.html");
notification.show();
Also there is an external notification.js for all the scripts I would like to run in the notification window (Since the manifest version 2 discourages inline javascript). Everything works fine except I couldn't open developer tools for the notification window to inspect the page. I can do it for the background as well as the popup pages, so not sure if I didn't find it or I simply can't inspect notification through the developer tool. I know I can send messages between background and notification so that outputs show up on the console, but it would be nice if I could inspect directly.
Thanks much!
Navigate to chrome://inspect/ and you can see all the pages that can be inspected. Under the section "Extensions" you should be able to see your notification page and you can inspect it.
Adding this answer for completeness, because #JJin's answer may had been working before but not in Chrome versions 24 and 25.
After some experimenting I accidently found that the developer tool is available for the notification page. The trick is to
fire up the notification window first and keep it on;
navigate to chrome://extensions and notification.html should appear alongside the background.html or whatever name the background page's name is,
as shown in the screenshot:
Make sure the notification window is on otherwise the notification.html would disappear.
I'm writing a Firefox extension and need to notify an iFrame page of certain events. The iFrame page is contained within a sidebar created by the extension, and this iFrame page is controlled by me.
When I load the iFrame page, the extension code needs to send a notification and trigger something to happen within the iFrame page.
To accomplish this, I'm creating an event from the extension Javascript and firing the event, which the iFrame page is listening to.
Unfortunately, when invoking document.createEvent(), this error pops up (copied, with the quotes, straight out of Firebug):
Operation is not supported" code: "9
Any clues on the error, or suggestions on how to trigger something in an iFrame page from the extension Javascript?
Firebug helps debug web pages. From your description it appears that the problem happens in your extension, so set up the profile according to the documentation and look in the Error Console.
Other than that, remote debugging requires seeing more of your code :)
That error is NS_ERROR_DOM_NOT_SUPPORTED_ERR. Are you using the right document (the content one, not the XUL window)? Although, I'm not convinced that that would error out either (in fact, I think it should work).
This is an example of code that works for me:
var eventName = "my-event";
var event = document.createEvent('Events');
event.initEvent(eventName, true, true);
document.getElementById('my_event_listener').dispatchEvent(event)