I'm using QT 5.8 and trying to load webpage using QAxWidget (set to IE) that displays HTML 5 empty canvas.
QString url = "https://h3manth.com/demo/canvas/full-page.html";
ui.browser->dynamicCall("Navigate(const QString&)", url);
Running the same url directly in IE works fine.
But when running it from my simple QT application I'm getting script error:
And getting the blank view as a result even when pressing 'Yes' in the dialog.
Any ideas for possible solution?
Modifying the reg keys as described on msdn: msdn.microsoft.com/en-us/library/ee330730(v=vs.85).asp ensures using the intended IE version for "embedded" browser
Related
i´m currently using JavaScript and HTML with eel and Python. But unfortunately when I am trying to create a file in the Chrome-Browser window (as an download) over JS i can only download it once.
The second "download" is not working.
-> Chrome just shows this (as it does when it downloads something) but then nothing happens:
When I am using Edge browser or only JS without eel it works perfectly fine!
My JS function that creates the download: (string is a json string that is generated earlier).
var jsonLink = document.getElementById("jsonLink");
jsonLink.download = "exportedToJson.json";
jsonLink.href = "data:application/json;charset=utf-8," + encodeURIComponent(string);
Ok I found a solution:
My chrome browser was blocking more than one download from "localhost:8000". So I had to go to settings and allow more than one download.
Maybe this helps someone :)
Why did I not find this earlier:
When I started my Python script, it calls:
eel.start('index.html', mode='chrome', port=8000) #starting chrome
Which does open a new Chrome Tab without the Tabbar (so i did neither see the tabs nor my favorite sites). Therefore I did not get a notification when chrome stated that download is blocked.
But after starting the eel-local webserver and open localhost:8000 in my normal chrome window, I did get a notification and I was able to allow the downloads.
-> afterwards it also worked in this eel-chrome window.
We have some functionality for exporting data to an excel file.
When the 'export' button is clicked, some client-side javascript is called, firstly checking the client browser version, and based on this, deciding which way to render the excel document.
It is working in Chrome & Firefox & IE11 when tested locally.
However, when I remotely test using a windows 10 machine running Edge browser, the excel is not rendered.
I might add that my local machine is a Win7 machine and Im running VS2012 and IE11. The remote machine is Win10 with Edge, hence the need to test remotely.
I've tried the emulation in IE11 F12 dev tools but cant replicate the Edge error there.
An error of 'undefined or null reference' is thrown for 'open' when using the following code:
excelIFrame.document.open("txt/html", "replace");
excelIFrame.document.write(sHTML);
excelIFrame.document.close();
excelIFrame.focus();
excelIFrame.document.execCommand("SaveAs", true, "Spreadsheet.xls");
The iframe exists in the html and is not added dynamically.
<iframe id="excelIFrame" style="display:none"></iframe>
I have tried the following possible solutions to get this working, to no avail -
Possible Solution 1: Same 'undefined or null reference error when assigning the document to a temp var
var doc = excelIFrame.document;
doc.open("txt/html", "replace");
doc.write(sHTML);
doc.close();
doc.focus();
doc.execCommand("SaveAs", true, "Spreadsheet.xls");
Possible Solution 2: Using the contentWindow property of the iFrame. No error thrown, it just opens 'about:blank' containing no content.
excelIFrame.contentWindow.contents = sHTML;
excelIFrame.src = 'javascript:window["contents"]';
Totally at a loss with this at this stage.
The page is an angularJS web page.
From reading up on it, I'm aware the document.open is problematic in edge when using iframes. But the following link document.open fails in an iframe I felt would solve the problem.
Any thoughts or suggestions greatly appreciated.
This may be helpful to others who are searching for it.
//For Edge browser ….. U have to write separate logic for each browser
if (ua.match(/Edge/)){
var blob = new Blob([sHTML], {type: 'data:application/vnd.ms-excel'});
window.navigator.msSaveBlob(blob, "P2P_Report_"+new Date().getTime()+".xls");
}
Pretty straight-forward, I'm developing an MVC5 application and have noticed (lately) that my Browser appears to be caching the JavaScript code I have on the view within #section Scripts { }.
Currently I am developing with Chrome and I have tried CTRL+F5 & CTRL+SHFT+R which reloads the page, but the alert() I uncommented within the javascript code is still rendering as commented. I also tried going to my localhost through Incognito Mode as well as other Browsers (Firefox, IE) and am getting the same behavior. This is my /Home/Index.cshtml View, which is the default View which loads when the application starts. I have also tried adding some extra HTML text into the page and again the new code is not taking effect/showing.
My current Chrome version is Version 41.0.2272.118 m if anyone has any ideas what might be going on?
UPDATE:
I have gone under the Developer Tools => General Settings in Chrome and checked [X] Disable cache (while DevTools is open) and then repeatedly (with DevTools still open) tried CTRL+SHFT+R and CTRL+F5 with the same results of before where my changes are not taking effect.
UPDATE 2:
With DevTools open I have also held the Refresh button down and tried Normal/Hard/and Empty Cache & Hard Reload options all with the same result. For simplicity of testing I added an alert in the below to dispaly as soon as the page loads (and currently no alert comes up):
$(document).ready(function () {
alert("Test");
// Other Code/Functions -- No Error showing in Console
});
If you are using Bundling from MVC, you have two options to disable caching:
Use BundleTable.EnableOptimizations. This instructs the bundling to minify and optimize your bundle even while debugging. It generates a hash in the process, based on the content of the script, so your customers browsers can cache this file for a long time. It will generate a whole different hash the next time your file changes, so your customers can see your changes. The downside is that your script will become unreadable and you won't be able to debug it, so this might not be your best option.
Use System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("url", true) to resolve your script's URL, the second parameter (true) is requiring a hash to be generated with the URL, thus, preventing caching from your browser when you change the file. This is exactly the same hash generated in the first option, but without minifying.
I created a small demo showing that the second option prevents caching from happening, the trick is getting the hash generated from your script's content without minifying your script.
I created a script file called myscript.js with this content:
$(document).ready(function () {
alert('a');
});
Then I added this to my BundleConfig.cs:
// PLEASE NOTE this is **NOT** a ScriptBundle
bundles.Add(new Bundle("~/bundles/myscripts").Include(
"~/Scripts/myscript*"));
If you add a ScriptBundle, you will get a minified response again, since ScriptBundle is just a Bundle using JsMinify transformation (source). That's why we just use Bundle.
Now you can just add your script using this method to resolve the script URL with the hash appendend. You can use the Script.Render
#Scripts.Render(System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/bundles/myscripts", true))
Or the script tag:
<script src="#System.Web.Optimization.BundleTable.Bundles.ResolveBundleUrl("~/bundles/myscripts", true)"></script>
Either way will generate a URL with a hash to prevent caching:
After editing my file:
You might want to add a no_cache variable after your script url like:
<script src="js/stg/Stg.js?nocache=#random_number"></script>
If you manage to put a random number to the place i indicated, the browser will automatically download the latest version of the script after an F5
A quick trick that solves this problem consists of opening the script file in a new tab, then refresh it on this page.
If you happen to have Chrome dev tools open it will even refresh it there.
From dev tool you can even easily right click-open in new tab the script.
How do i set up a custom protocol handler in chrome? Something like:
myprotocol://testfile
I would need this to send a request to http://example.com?query=testfile, then send the httpresponse to my extension.
The following method registers an application to a URI Scheme. So, you can use mycustproto: in your HTML code to trigger a local application. It works on a Google Chrome Version 51.0.2704.79 m (64-bit).
I mainly used this method for printing document silently without the print dialog popping up. The result is pretty good and is a seamless solution to integrate the external application with the browser.
HTML code (simple):
Click Me
HTML code (alternative):
<input id="DealerName" />
<button id="PrintBtn"></button>
$('#PrintBtn').on('click', function(event){
event.preventDefault();
window.location.href = 'mycustproto:dealer ' + $('#DealerName').val();
});
URI Scheme will look like this:
You can create the URI Scheme manually in registry, or run the "mycustproto.reg" file (see below).
HKEY_CURRENT_USER\Software\Classes
mycustproto
(Default) = "URL:MyCustProto Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "myprogram.exe,1"
shell
open
command
(Default) = "C:\Program Files\MyProgram\myprogram.exe" "%1"
mycustproto.reg example:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Classes\mycustproto]
"URL Protocol"="\"\""
#="\"URL:MyCustProto Protocol\""
[HKEY_CURRENT_USER\Software\Classes\mycustproto\DefaultIcon]
#="\"mycustproto.exe,1\""
[HKEY_CURRENT_USER\Software\Classes\mycustproto\shell]
[HKEY_CURRENT_USER\Software\Classes\mycustproto\shell\open]
[HKEY_CURRENT_USER\Software\Classes\mycustproto\shell\open\command]
#="\"C:\\Program Files\\MyProgram\\myprogram.exe\" \"%1\""
C# console application - myprogram.exe:
using System;
using System.Collections.Generic;
using System.Text;
namespace myprogram
{
class Program
{
static string ProcessInput(string s)
{
// TODO Verify and validate the input
// string as appropriate for your application.
return s;
}
static void Main(string[] args)
{
Console.WriteLine("Raw command-line: \n\t" + Environment.CommandLine);
Console.WriteLine("\n\nArguments:\n");
foreach (string s in args)
{
Console.WriteLine("\t" + ProcessInput(s));
}
Console.WriteLine("\nPress any key to continue...");
Console.ReadKey();
}
}
}
Try to run the program first to make sure the program has been placed in the correct path:
cmd> "C:\Program Files\MyProgram\myprogram.exe" "mycustproto:Hello World"
Click the link on your HTML page:
You will see a warning window popup for the first time.
To reset the external protocol handler setting in Chrome:
If you have ever accepted the custom protocol in Chrome and would like to reset the setting, do this (currently, there is no UI in Chrome to change the setting):
Edit "Local State" this file under this path:
C:\Users\Username\AppData\Local\Google\Chrome\User Data\
or Simply go to:
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\
Then, search for this string: protocol_handler
You will see the custom protocol from there.
Note: Please close your Google Chrome before editing the file. Otherwise, the change you have made will be overwritten by Chrome.
Reference:
https://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx
Chrome 13 now supports the navigator.registerProtocolHandler API. For example,
navigator.registerProtocolHandler(
'web+custom', 'http://example.com/rph?q=%s', 'My App');
Note that your protocol name has to start with web+, with a few exceptions for common ones (like mailto, etc). For more details, see: http://updates.html5rocks.com/2011/06/Registering-a-custom-protocol-handler
This question is old now, but there's been a recent update to Chrome (at least where packaged apps are concerned)...
http://developer.chrome.com/apps/manifest/url_handlers
and
https://github.com/GoogleChrome/chrome-extensions-samples/blob/e716678b67fd30a5876a552b9665e9f847d6d84b/apps/samples/url-handler/README.md
It allows you to register a handler for a URL (as long as you own it). Sadly no myprotocol:// but at least you can do http://myprotocol.mysite.com and can create a webpage there that points people to the app in the app store.
This is how I did it. Your app would need to install a few reg keys on installation, then in any browser you can just link to foo:\anythingHere.txt and it will open your app and pass it that value.
This is not my code, just something I found on the web when searching the same question. Just change all "foo" in the text below to the protocol name you want and change the path to your exe as well.
(put this in to a text file as save as foo.reg on your desktop, then double click it to install the keys)
-----Below this line goes into the .reg file (NOT including this line)------
REGEDIT4
[HKEY_CLASSES_ROOT\foo]
#="URL:foo Protocol"
"URL Protocol"=""
[HKEY_CLASSES_ROOT\foo\shell]
[HKEY_CLASSES_ROOT\foo\shell\open]
[HKEY_CLASSES_ROOT\foo\shell\open\command]
#="\"C:\\Program Files (x86)\\Notepad++\\notepad++.exe\" \"%1\""
Not sure whether this is the right place for my answer, but as I found very few helpful threads and this was one of them, I am posting my solution here.
Problem: I wanted Linux Mint 19.2 Cinnamon to open Evolution when clicking on mailto links in Chromium. Gmail was registered as default handler in chrome://settings/handlers and I could not choose any other handler.
Solution:
Use the xdg-settings in the console
xdg-settings set default-url-scheme-handler mailto org.gnome.Evolution.desktop
Solution was found here https://alt.os.linux.ubuntu.narkive.com/U3Gy7inF/kubuntu-mailto-links-in-chrome-doesn-t-open-evolution and adapted for my case.
I've found the solution by Jun Hsieh and MuffinMan generally works when it comes to clicking links on pages in Chrome or pasting into the URL bar, but it doesn't seem to work in a specific case of passing the string on the command line.
For example, both of the following commands open a blank Chrome window which then does nothing.
"c:\Program Files (x86)\Google\Chrome\Application\chrome.exe" "foo://C:/test.txt"
"c:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --new-window "foo://C:/test.txt"
For comparison, feeding Chrome an http or https URL with either of these commands causes the web page to be opened.
This became apparent because one of our customers reported that clicking links for our product from a PDF being displayed within Adobe Reader fails to invoke our product when Chrome is the default browser. (It works fine with MSIE and Firefox as default, but not when either Chrome or Edge are default.)
I'm guessing that instead of just telling Windows to invoke the URL and letting Windows figure things out, the Adobe product is finding the default browser, which is Chrome in this case, and then passing the URL on the command line.
I'd be interested if anyone knows of Chrome security or other settings which might be relevant here so that Chrome will fully handle a protocol handler, even if it's provided via the command line. I've been looking but so far haven't found anything.
I've been testing this against Chrome 88.0.4324.182.
open
C:\Users\<Username>\AppData\Local\Google\Chrome\User Data\Default
open Preferences then search for excluded_schemes you will find it in 'protocol_handler' delete this excluded scheme(s) to reset chrome to open url with default application
I am creating a small javascript simulation of a java-based (JSF) server. The bootstrap javascript file will download and parse a bunch of files using AJAX, and then generate a large HTML string. This HTML string is a full HTML document - it has a doctype, head, script includes, inline scripts, body, etc.
The reason I do not want to use the real JSF back-end is because I would like to be able to have a pure UI environment to test my code without any java/oracle server slowing me down.
I want to share my code (in a .zip file for example) with anyone and they should be able to open the page (with a small loading screen while the AJAX calls are made) in any browser without some server already installed on their machine.
The answer to that question led me to explore more - now I've run into a different error but I cannot seem to explain it.
Fiddle #1 : This one attempts to put the HTML into an iframe using the iframe's document.write. In this HTML there is a script that pushes a new history state history.pushState(null, null, hash)
Fiddle #2 : This one attempts to put the HTML into the iframe, but this time it just uses location.hash = hash
Both fiddles seem to work fine in Chrome and Safari and IE 9 - but Firefox gives the following error:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHistory.pushState]
I don't understand this error - if you do this same code history.pushState(null,null,"#test") on any page in firefox using the javascript console in FireBug it works fine - but in this particular situation it doesn't work.
I also tried to perform document.open(); document.write(html); document.close() on the document in the current page (instead of creating an iframe), but the same problem happened - only this time if I put break points in firebug into javascript code inserted in the HTML fragment, the breakpoints don't work which would mean I could no longer debug anything in firefox. At least with the iframe approach, the breakpoints work.
Can anyone shed some light into this problem?
Here is another related question that I asked yesterday which lead to finding this error: Firefox Fail - After using document.write and update to location.hash causes page refresh
You can put this code
history.pushState(null,null,"#test")
before
document.open();
document.write(html);
document.close();
I have run into a similar issue trying to open an Ember app using history.pushState (Ember Router location: 'history' method of routing) inside an iframe. It appears the issue only occurs when doing a hard refresh (cmd + shift + r on Mac or ctrl + f5 on Windows) in Firefox. The issue only occurs for me in FireFox, works fine in Chrome and Safari with similar hard refresh.
The issue does not occur for me when navigating to the page for the first time or when normally refreshing the page (cmd + r Mac, f5 Windows). I have found many seemingly related on Bugzilla for Mozilla but many are close. This one seems to represent the same issue I am having and is still open as of current versions of Firefox (v37.0.1 at time of writing).
https://bugzilla.mozilla.org/show_bug.cgi?id=1003100