I'm working on a plugin where we rely on the user's ability to drag-and-drop an image from our Google Docs plugin sidebar to their current Google Document, inserting it in the document when they drop.
This has worked fine up till now using HtmlService.SandboxMode.NATIVE, as the browser implements this natively, but that sandbox mode will soon be sunsetted in favor of HtmlService.SandboxMode.IFRAME.
In iFrame sandbox mode, this no longer works, as dragging and dropping between iFrames is disallowed by browser security.
I initially thought we might be able fake this by catching an event on drop, and inserting the image at the user's cursor location, but we're not getting any events for the drag and drop over the document.
It doesn't look like window messaging is an option.
Has anyone dealt with this or a similar situation?
Any insight into how we might either
a) make drag and drop work, or
b) fake it?
Related
So, here's is my doubt.
I'm using the MediaRecorder API, to make a recording of my browser's screen. I can capture the whole browser screen + audio(tab) + my microphone. Everything is working fine. But I only need to capture the screen+audio from the tab that started the recording. On that popup thats opens on google chrome, when I want to screenshare some tab or application, is it possible to show only the tab that started the screenshare? So I don't have to seek everytime the tab that I want to share.
I didn't find any information about that.
When working with the google chrome API, I see that we can capture only a tab, but outside this API, is it possible to accomplish something similar? Or is only possible to work with pre-selected tab if I develop a google chrome extension?
chrome.tabCapture.capture({audio: true, video: true}, callback);
Unfortunately you can't specify it or limit it to the current tab.
Note: Constraints never cause changes to the list of sources available
for capture by the Screen Sharing API. This ensures that web
applications can’t force the user to share specific content by
restricting the source list until only one item is left
https://developer.mozilla.org/en-US/docs/Web/API/Screen_Capture_API/Using_Screen_Capture
I'm working on an extension that's supposed to use the content of the page to determine whether to show an interface to the user.
The ways to show an interface, if I'm correct, are using a browser action or a page action.
And neither can be triggered programmatically. But content scripts could be written to inject an equivalent GUI into the webpage.
So, does it make sense to modify the DOM using content-scripts to display an interface as a substitute for page action? It seems like an obvious work around to me, and I'm sure there are good reasons to not let page actions be triggered programmatically.
Well, modifying DOM must be done by only Content Scripts, as that is the reason they exist.
Want to fetch any data from current page, alter anything in the page, add new UI in the page - whatever, content script will help you do that.
It has nothing to do with Page script Or Browser Script.
YES, you can not programatically trigger page/browser action. It has to be done by explicit clicking.
But if you want to open a UI by clicking a chrome extension, then there is a popup js for that.
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'm looking to build a chrome extension that allows the user to have an independent subwindow that is the same in each tab (for example you are taking notes and the notes are synchronized among each tab). Also, clicking a link should not destroy this subwindow.
One solution is to inject an iframe in each tab, and try to synchronize this data serverside and send back to each client tab, as it is updated.
This seems very tedious, plus the iframe would be provided by a third party, and I want to make it the easiest for them.
Is there a way I can have a shared dom piece and display it in its current state across several tabs?
There's an API (still experimental as of Chrome 17) that does more or less exactly what you want. If you visit about:flags, and enable "Panels" (they're enabled by default in Dev and on Canary (and on ChromeOS)), you'll be able to use chrome.windows.create with a type of panel to create a floating pane that exists independently from the browser window. That would likely meet your need.
Take a look at the Google Talk extension for an example of how it might work.
Every solution I've seen so far for opening a new browser window uses the target property in to set it to "_blank". This is frustrating because in some browsers it only opens a new tab AND combine that with the auto-resizing behvaiour at http://www.facebook.com/connect/prompt_feed.php?&message=test, it basically mangles my browser whenever I try updating my status from my site.
How can I be sure to open a new window when a user clicks on a link?
Thanks!
Trindaz on Fedang
Popups are windows, they just have some features disables. You can make a popup act like a regular window by enabling these features. For example, if you open a popup with
window.open('url', 'name', 'width=500, height=500, status=1, toolbar=1, location=1, menubar=1, resizable=1');
the window will have a toolbar, a URL bar, a status bar, menus, and it will be resizable. It will the same as any other window.
Keep in mind, however, that many browsers block window.open() under some conditions, and some of them will open new tabs if you specify a lot of features. Some are weird about it too; Chrome, for example, uses scroll bars on popups by default, but if you specifically tell it to use scroll bars in a popup (using scrollbars=1), it will open in a tab instead.
So basically there is no way to be completely sure that your page will always open in a new window, because browsers all handle this stuff differently, users can change settings too. The code above is probably your best bet if you have to have a new window, but you might want to look into other options.
window.open(URL,name,specs,replace)
function newwindow()
{
myWindow=window.open('','','width=300,height=300');
myWindow.document.write("<p>This should open in a popup</p>");
myWindow.focus();
}
There is a legitimate reason for using Target=_blank that everybody has completely overlooked, and that is when a website is written as a BOOK with chapters/pages and the Table of Contents must remain intact without using the BACK button to reload the previous page (Table of Contents). This way all a surfer needs to do is close the Target Page when finished reading and they will be back to the Table of Contents.
Lucky for us that HTML5 has reinstated the Target="_blank" code, but unfortunately the "Block Popups" must be unchecked for it to work.