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.
Related
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.
I want to add back and forward navigation button to my browserWindow in my Electron App, but although with Firefox and chrome when we use the back navigation any form input are reloaded with cached data with Electron webview using goBack()function clear these everytime. Is there any setup, options or way of keeping the data ....
It isn't clear.
Electron documentation doesn't explicitly state whether Electron implements what is called BFCache or HistoryLists.
It isn't clear from Electron source code either. I created relevant issue on Github.
Electron uses Chromium to implement BrowserWindow. Situation with BFCache and Chromium itself isn't very clear. There are multiple issues that state
that BFCache isn't implemented in Chromium (455226 Chrome reinitializes all fields to the value they had on their initial presentation when history back is used, 510340 Investigate faster back/forward page navigation). Although I've seen in practice that BFCache works in Chrome.
You can save and restore form state using JavaScript, sessionStorage and window load and unload events. But in this case you also need a mechanism to clearly identify input nodes and store serialized files in case if form contains file inputs.
For more information check:
You Do Not Understand Browser History article by Matthew Beale
Window.sessionStorage MDN page
MDN page about BFCache
I'm currently debugging a webpage which is embedded in a UIWebView for display in the app.
It uses some elaborate on-load Javascript which works fine in the Android app but breaks in the iOS app.
This answer pointed me to Safari Web Inspector for UIWebView - however, since the broken Javascript is being run on page load, I can't actually attach the inspector in time to capture whatever's going wrong.
Right now I'm hacking around it by manually inserting a delay into the page, but is there a better way (one that doesn't require I make changes to the page code itself, start the app, rush to load it up in Safari, then wait a while longer for it to continue)?
Important edit: in Safari 7.0, you can reload the page by selecting the "Resources" view, and clicking the refresh arrow next to the top-level page. [It seems you can also do it in at least some versions of Safari 6 by selecting the document tab, clicking the top-level page to select it, and pressing Command+R (the same shortcut used to refresh the page in normal Safari).] Breakpoints you set will still exist if you refresh the page from the Safari Web Inspector, because doing so does not cause SWI to detach the way reloading the page from within your app or the Xcode debugger does. This means that as long as the page doesn't do a Javascript redirect or trigger side-effects in the app itself, you can step through the onload Javascript by loading the page once, setting your breakpoint there, and then reloading the page from within SWI.
Original post: The only solution I was able to find was putting in an "extra" call to shouldStartLoadWithRequest: as follows:
Add a script (not onload, synchronous) as the first element in the page head:
<script type="text/javascript">
window.location = "myapp://catchme";
</script>
Set an XCode breakpoint in shouldStartLoadWithRequest:
Edit the breakpoint to set a condition of:
(bool)[[[request URL] absoluteString] isEqualToString:#"myapp://catchme"]
(Without this condition it will stop on the initial shouldStartLoadWithRequest: call, which isn't what you want because the page won't yet be available to attach the Mobile Web Inspector to at this stage.)
Start the page load, and when it hits the (Xcode) breakpoint, switch to Safari, and launch Mobile Web Inspector with Develop > iPhone Simulator > (my page), then switch back to Xcode and resume execution within a short window before all the resource requests on the page time out.
Weinre helped me to solve this issue, since it's connected right from the start, you get full control of the page.
Why not putting a breakpoint in shouldStartLoadWithRequest and then open the inspector?
Not 100% related to the question OP asked, but I had a similar problem with an Android WebView, in a mobile app whose native code I do not control (but which has WebView debugging enabled).
document.reload() and all other similar means of reloading the page were not working for me
I was thinking to put alert() at the very top of the page, which in theory is a blocking call, but it was not working for me either.
Finally, I went with a blocking, synchronous XHR.
In order to inject an artificial delay when the page is loading, I added a fake call to an endpoint under my control that returns 200 OK after 15 seconds.
Put this at the very top of the <head>
<script>
try {
var request = new XMLHttpRequest();
request.open('GET', 'https://whatever/please-freeze', false); // false = sync XHR
request.send(null);
} catch (err){
debugger;
};
debugger;
</script>
You can for example create your own simple http server with an endpoint behaving like this, but this is a bit of an overkill.
The debugger statements didn't trigger breakpoints in Chrome for whatever reason, but the manually defined breakpoints in the dynamically loaded code (created before) worked fine.
A hack for Windows (Fiddler) users
Since I'm on Windows, I used Fiddler to create an autoresponder with latency.
I also used Fiddler to edit the HTML of the original page request, to inject the <script> mentioned earlier.
I'm binding to the jQuery Mobile pageinit event to do some additional stuff after a page has been created/enhanced and loaded into the DOM (per the docs) like so:
$('#home').live('pageinit', function()
{
...
};
But, all I'm getting is a white spinner and the page never displays on an iOS device running OS6. It works fine in the simulator. What could I be doing wrong?
There are plenty of references to pageinit not working if placed in the wrong part of the page, though generally that wouldn't cause the page to stop loading.
A script error in the event handler (the ... part) could cause the symptoms described, but would likely work the same in the simulator.
Are you sure all the files are referenced correctly? Unlike OSX, iOS is case sensitive, so a reference to jQuery.js instead of jquery.js will cause problems that you can't see anywhere else. You should be able to connect the desktop safari web inspector to the app to find any load errors.
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.