is it possible to replace the action of an existing item in the context menu in Chrome. Simple example, every time I press "Inspect Element", it opens another developer tool extension instead of the default.
It is not: at the moment, devtools APIs only function if the web inspector is open. There's no mechanism to open the web inspector for a user, it has to be her explicit choice.
That said, it sounds reasonable to give an extension the ability to hook into an element's context menu. That might be a good idea for an extension to the existing devtools or Context Menu APIs. Would you mind filing a request at http://new.crbug.com/? I'll make sure it lands in the correct queue.
Related
So I have recently started working on building a Google chrome extension, and found the entire landscape fascinating to say the least. While I was checking to understand how some of these extensions work, I found that many of them have blocked 'inspect element'. I found only 'Adblock Plus' which allows it.
My question:
Are there any more complex interesting chrome extensions that allow inspection?
Any way to find such extensions or how to get around the ones that have blocked viewing?
As a beginner, I would appreciate any advice or tips in this area.
You can inspect and debug all extensions right in the browser.
You may need to use a different method of invoking devtools.
To inspect the popup you can enable developer mode switch in chrome://extensions and then right-click the extension's icon in the toolbar or click ... inside the puzzle piece menu that lists all extensions, then choose Inspect popup.
Similarly, to inspect something shown in the tab, you can open devtools via the standard hotkeys like (F12 or Ctrl-Shift-i in PC) when the cursor is focused on the toolbar even if the page actively intercepts these hotkeys and/or the context menu.
You can also open devtools from the browser menu "More tools".
There's also chrome://inspect.
I'm developing a chrome extension. When the user goes to the options page, they might modify a setting which will require them to refresh any tabs they have in which they're using the extension. So if the user changes one of these settings, then goes back to a tab which requires a refresh, I'd like to notify them of this in a non-intrusive way.
Is there a part of the API specifically for doing this sort of thing, or some other recommended way of doing it? I was thinking of maybe a little message that comes down from the top of the page, but can be closed, or a popup coming out of the browser action.
You have many options.. To name a few:
Do not require it. As much as you can, make the (presumably) content script adapt to new settings. It's by far a better UX - in some cases.
Least intrusive would probably be to update a browser action / page action icon if you use one.
Both APIs allow a per-tab change of icon/badge. You could also animate it a little to bring attention.
An in-page notification injected into the DOM. Some sort of toast or <dialog>.
Watch tab changes with chrome.tabs events, and do something on activation of affected tab, such as a chrome.notifications notification.
Is it possible to add items to the application window (as opposed to the context menu) in a Chrome app? (Or, for that matter, alter it in any way?)
No. This menu is not part of the Chrome App execution environment. On some platforms (e.g., Chrome OS) it doesn't even exist. Where you see it, it's because the app wrapper for that particular OS supplies it automatically. Instead, use context menus, buttons and other controls, or, if you like, your own menu bar.
I have recently created a extension for devtools, which adds a new ExtensionPanel on devtools. Since this panel is useful only on certain pages, I wanted to show it conditionally depending on contents of current page. I can create a panel dynamically,depending on context of the page, but I was unable to find any way to close it (I've tried window.close() and panel itself doesn't have any methods like this).
So my question: Is there any way to close ExtensionPanel programmatically?
This is not supported by DevTools at the moment -- if you add a panel or sidebar, it's for the life of DevTools front-end. All stock DevTools panels are displayed unconditionally and the rationale for the lack of API methods to remove panels is to avoid confusion created by panels coming and going. If a panel is not applicable to the page being inspected at the moment, you can perhaps display a banner explaining why it's not applicable.
I have a chrome extension I am working on, which lives in a devtools panel (http://developer.chrome.com/extensions/devtools.panels.html).
I want to add a button to quickly open up my extension. I added a browser_action button just fine, but I can't find any information on launching developer tools from a browser action.
Is there a way to open developers tools and switch to my pane from a browser action button?
It seems unlikely that this is possible or will ever become possible. From Chromium Issue 112277:
We only allow explicit devtools opening.
While the issue described there is slightly different from your use case, your needs still seem to run contrary to the requirement of "explicit dev tools opening".
I read "explicit devtools opening" to mean "only open devtools when the user explicitly requests devtools". This reading is incompatible with allowing extension buttons to open developer tools. You could have a button that appeared to do something (say, redirect you to a website) but when clicked, actually opened developer tools -- you've just opened dev tools without the user explicitly asking for it, which is inconsistent with my reading of "explicit devtools opening".
Consider the theoretical statement, "We only allow explicit deletion of user data." Certainly that directive would preclude allowing an arbitrary extension button from deleting user data, wouldn't it? Even if the user explicitly clicked on a button, they didn't explicitly opt to perform a delete.
Perhaps you could read "explicit devtools opening" more loosely to mean "open devtools only in direct response to user action" which would leave open the possibility of future support for this functionality.