Is there a way to communicate between the webview and the main window without enabling the remote module ?
<webview src="http://www.google.com/" enableremotemodule="false"></webview>
When this attribute is false the guest page in webview will not have access to the remote module. The remote module is avaiable by default.
https://electronjs.org/docs/api/webview-tag#enableremotemodule
Not quite what you asked but I took heed of the Electron team's warning and opted to use iframes rather than webviews
We currently recommend to not use the webview tag and to consider
alternatives, like iframe, Electron's BrowserView, or an architecture
that avoids embedded content altogether.
I've had success using Window.postMessage() but I am far from an "expert" on any of this.
The window.postMessage() method safely enables cross-origin
communication between Window objects; e.g., between a page and a
pop-up that it spawned, or between a page and an iframe embedded
within it.
Related
I'm using Playwright (Java) to drive a particular third-party Web site, the first page of which apparently containing two images which are password protected; this causes a sequence of basic-authentication dialogs to open when the page loads.
I'd like the script to dismiss these dialogs (cancel), rather than providing any credentials, and then continue working with the page. But as it stands now, the page.navigate() blocks and eventually times out, unless I cancel these dialogs manually with the mouse.
Note that this is the native browser dialog, not anything generated from js on the page.
Is this possible with Playwright?
Interestingly, I was able to work around this by disabling images entirely in Chrome, which might have other (performance) benefits, too.
Added this to the array of Chrome startup arguments:
--blink-settings=imagesEnabled=false
Of course, this only solved this specific case, in which the login prompts were being triggered by image URLs.
According to Electron documentation when BrowserWindow or Webview is created with option nodeintegrationinsubframes then specified preload should be executed in every iframe.
But defined preload script is executed in all iframe except "about:blank" iframes.
(iframe without defined src attribute).
Is it bug? Is there any work-around?
I have tested if other options like nodeIntegration or contextIsolation has some impact to this, but it has not.
From Documentation
nodeIntegrationInSubFrames
A Boolean for the experimental option for enabling NodeJS support in sub-frames such as iframes inside the webview. All your preloads will load for every iframe, you can use process.isMainFrame to determine if you are in the main frame or not. This option is disabled by default in the guest page.
Webview
BrowserWindow
There is Github Gist to reproduce issue in Electron Fiddle.
I am learning web allowed objects in the universal application. Previously I am using script notify to know any action on the content in my web view, where i specified the URL of my web view content in the app manifest file. Now I am trying to switch it from script notify to web allowed object. But without specifying any URL in the app manifest it is working as expected. Is is the behavior of the web allowed object or something I missed?
According to Accessing the Windows Runtime in a web view section of WebView class:
You can use the AddWebAllowedObject method to inject an instance of a native class from a Windows Runtime component into the JavaScript context of the WebView. This allows full access to the native methods, properties, and events of that object in the JavaScript content of that WebView.
So that you may not need to specify URL to make it work with accessing the native methods in Runtime component, but ensure to decorate the class with the AllowForWeb attribute.
Specifying any URL you mentioned in the app manifest is for addition features that trusted JavaScript content in WebView can be allowed to directly access Windows RuntimeAPI. This provides powerful native capabilities for web apps hosted in a web view. For more details about this feature please reference Accessing UWP features.
After loading up a Webclip with some links in it, clicking a link launches Mobile Safari instead of loading the link in the same window. Is there a way to prevent the link loading in Safari instead of the Webclip instance? I'm trying to mock up a mobile app just using PHP on my local Apache installation.
According to the Apple docs it looks like external page links will always open in Mobile Safari:
In this mode any external links will be opened in Safari on
iPhone, meaning that you will have to keep your web application to a
single page and use Ajax to update parts of that page.
In addition to the option of using a single page loading new content with AJAX, you can use the JavaScript self.location=URL; return false on hyperlinks that must stay within the application. This can be added to the HTML code directly, or with another script upon loading the page.
If you are using jQuery, I would recommend something like this:
$('a:not([target])').click(function(){
self.location = $(this).attr('href');
return false;
});
Obviously this script should be ran after the HTML has loaded, to ensure that it actually attaches to the A elements onClick event.
I worked with Chrome extensions which have so called background page - an html page that is loaded in background once per browser window. You can store there some javascript variables, can access extension's own localstorage, can communicate back and force with content scripts (scripts injected to pages).
Is there anything similar in Firefox and how do I use it for the tasks listed above?
If you are using the (relatively) new Add-On SDK, then the main javascript file residing in your lib directory is equivalent of a Chrome extension's background page - a persistent script that runs in the background and spawns/creates/inserts panels, widgets and content scripts.
Regarding your specific asks:
1. localStorage: Add-Ons in Firefox cannot access localStorage directly. However, you can use simple-storage for storing data similar to localStorage.
2. Communication with content-script: Add-ons can communicate with content scripts using port or postMessage.
From the point of view of a traditional Firefox extension, the browser itself is just another window containing a document, although this is a XUL document rather than an HTML document. So you can store per-window variables, although you have to be careful not to overwrite other extension variables, which usually means declaring a top-level object and adding all your variables as properties of that object.
Sharing variables between windows used to be a little harder but fortunately JavaScript modules solve that problem in simple cases (primitive types).
Extensions can communicate with content scripts although there are some wrappers in place to prevent you from accidentally doing something silly.