I've created an agreement with the agreements REST API and am displaying it in an iframe using the signingURLs API. However, the UI that Sign presents in the iframe includes an Options menu in the top left with a "Read Agreement" option which, when clicked, reloads the document in the iframe in a read-only mode with no apparent way to get back to where the user can actually sign.
My main question is whether there's a way to prevent the Read Agreement option when the agreement is created (I pored over the API docs trying to find a way, but didn't spot one).
If not, is there a way to suppress the menu item at the account/group level? I was able to find some info online about how to suppress the Delegate and Decline option menu items, but not this one.
Related
The problem is that these days a page can attach a listener to an event that indicates closing/leaving a page and they inject cookies right at that point so you can't see them with a normal cookie inspection (which requires a page to be open/current).
The way to verify (or even notice) this is to open the same page in incognito/private and see different behavior (usually the absence of "pay me pay me pay me" intrusions).
The real question is - how to find them? And then eradicate. Are there any utilities, extensions, plugins etc? Say something similar to password inspection/search in Settings.
How ungroup the "Open as..." context menu entry?
If I am using only 2 Profiles, I'm good
Screen of only 2 profiles
As you can see in the screenshot, I have to do two clicks for opening an url link within the other profile.
Screen of 3 or more profiles
But if I have a third profile, the context menu changes, it creates an expandable item, grouping the other profiles. That is very annoying, because I have to navigate first to the "Open as" line and then after a short delay or an additional click the profile-list appeares where I need to select appropriate profile.
Can we revert the behaviour to list all available profiles within the root context menu?
May we create a keyboard-shortcut for every profile, so pressing the asssigned button while clicking on any links, will open the url in that profile.
Or is there an extension for doing the job? I couldn find any useful information to solve this...
Thanks in advance for any helpful advices :)
(sorry for the spellingmistakes)
Offtopic:
(migrating from ff to chromium. Everyday web-based apps for end-consumers getting more focus, which means in my eyes, programmatically design gets more limited due to the main concept behind our standardized world wide web. And additionally user control gets worse everyday because that's the new key to generate money no longer just for complex & highly specialized products. e.g. timeinvestigation is enormous to through out all the bugs and bullshit extensions to get a reasonably useful tool for accessing the world wide web.)
I am making a chrome extension that fetched JSON data from CoinMarketCap.com API and currently I have it running in the background script. I'm not 100% sure what the purpose of the page is really. I was wondering if I could simply fetch the data from the popup script after I click a button within my popup?
Each button represents a different coin. I basically want to get the price of a chosen coin and display it on whatever page the user is on when they double click the coin in a text article. Eventually I want to make it so you can double click any coin and have it show a live price conversion while you're on the web-page.
The point of a background page is to be always available (running if persistent: true, woken up / recreated for registered events if persistent: false).
A popup's lifetime is determined by its visibility. The moment the user clicks away and closes it, the page is closed (as if the tab with it was closed), so it can no longer process any events and its state is lost.
As long as:
The data you need fetched is to be received/processed while the popup is open
Any state you need to persist between popups being shown can be stored in chrome.storage
Then you don't need the background page to do the fetching. Popup page has the same level of access to Chrome APIs.
However, consider this scenario: suppose you want the data to be ready as soon as popup is opened (at least, you want it to be fresher than "since last time"). You may want to do periodic updates even while the popup is closed to refresh the data. You can only do that reliably with a background page (and, say, chrome.alarms API). Then you can cache the latest available data in chrome.storage and use that in the popup.
Background pages have their uses as some code that can run periodically regardless of user actions, and to be able to always react to events.
According to Changes to Cross-Origin Requests in Chrome Extension Content Scripts now you have to do your fetches in Background Script. Not in Content Script.
I'm building a Google Chrome extension at the moment and I have a question about when to use an event page.
A quick look at the Chrome extension docs shows that Google really want its developers to use event pages, if possible.
My extension currently uses a background page, but I was wondering if I should switch to an event page?
This is what my extension does:
When matched with a particular website, it injects a script that adds buttons for the user to access extra functionality.
Most of this extra functionality consists of doing fairly computationally expensive operations on user-entered data - this is all done in the background page (it is all it does).
When a user wants to run these operations on their data they press a button and this passes a message, from the injected script to the background page, which then passes a message back containing the results of its operations.
Essentially, all the background page is doing is waiting for message passing from an injected script in one particular website and then running some operations. Since it doesn't need to be active all the time, this suggests that I should be using an event page.
Can anyone confirm if this would be a good idea for me? Or are there reasons why I should stick to a background page?
Allowing the background page to suspend (chrome.runtime.onSusend) is great, because it will free up system resources. The page will automatically be launched when a matching event happens (chrome.tab.onUpdated etc). I can't think of any compelling reason to use a persistent background page. You can always store any long term state in chrome.storage.local or indexedDb, etc.
I am building an extension for Chrome and Can't decide If I should use chrome.windows.create type popup , panel or detached panel. I could not find a comparative study of the three options . Any links or short description of positives and limitations of each will be helpful .
Thanks
You are having difficulty understanding it, because unless you specifically enabled an experimental feature, they are exactly the same, or rather the latter ones are ignored and a popup type is created.
Unfortunately, this means that this API is unavailable for general use until Google decides to mark it stable.
Quoting the docs:
The 'panel' and 'detached_panel' types create a popup unless the '--enable-panels' flag is set.
As for what panels are, here is the API proposal with detailed description.
Panels are windows that are visible to the user even while the user is interacting with other applications. The small windows are positioned at the bottom of the screen, with minimal manual window management by the user. This API will allow extension developers to create and use panels.
[...]
An extension opens small "pop up" windows, for example, separate chat sessions, calculator, media player, stock/sport/news ticker, task list, scratchpad, that the user wants to keep visible while using a different application or browsing a different web site. Scattered "pop up" windows are difficult for the user to keep track of, therefore panels are placed along the bottom of the screen and are "always on top".
The user would like easy control of chat windows: finding them, moving them out of the way, etc. Window management of separate chat "pop ups" is time consuming. All panels can be minimized/maximized together.
If you want a real-life example, the Hangouts extension is whitelisted to use this window type; that's how they make the chat panels:
Since chrome doesn't by default enable panels , this need to be set to display panel behavior instead of popup window . Note that popup windows can be re positioned and one can view console window , but none of it is available in panel .