As this answer suggested, I want to modify a little bit office.js.
So I copied the content of https://appsforoffice.microsoft.com/lib/1/hosted/office.js to local, such that https://localhost:3000/static/office.js shows well the content.
Then, I make a very simple file test.html:
<html>
<head>
<!--<script src="https://appsforoffice.microsoft.com/lib/1/hosted/office.js"></script>-->
<script type="text/javascript" src="https://localhost:3000/static/office.js"></script>
</head>
<body>
haha
</body>
</html>
Loading https://localhost:3000/static/test.html with remote office.js in a browser shows Warning: Office.js is loaded outside of Office client
o15apptofilemappingtable.js:11, and loading it in an Office add-in works well.
However, loading https://localhost:3000/static/test.html with local office.js in a browser shows Uncaught SyntaxError: Unexpected token <
o15apptofilemappingtable.js:1, and loading it in an Office add-in gives an error Add-in Error Something went wrong and we couldn't start this add-in. Please try again later or contact your system administrator.
So does anyone know what's wrong here? Is it possible to make our own local version of office.js?
See my answer in the linked question. Essentially, no, you should not be making your own local copy of "office.js". But if you did want a local copy -- which we already offer on NuGet and, more recently, on NPM (https://www.npmjs.com/package/#microsoft/office-js) -- you would need all the associated files in that directory as well, not just Office.js itself.
See https://unpkg.com/#microsoft/office-js#1.1.1/dist/ for a listing of the files and folders that make up Office.js. Not all (in fact, not most) are used in any given session, but you do want the whole set of files since different ones are loaded in different circumstances.
Related
See the error on my website here
I have embedded a blazor app in my jekyll site. It runs perfectly locally, but when I publish it on github pages, I am getting this error:
Failed to find a valid digest in the 'integrity' attribute for resource 'https://chrisevans9629.github.io/blazor/xt/_framework/wasm/dotnet.3.2.0-rc1.20222.2.js' with computed SHA-256 integrity 'yVt8FYsTQDifOGsifIkmEXwe+7ML0jZ1dMi2xluiDXQ='. The resource has been blocked.
This is something that I think blazor generates when the page is ran. this is what my page looks like that starts blazor:
<script src="js/index.js"></script>
<app>Loading...</app>
Built with <3 using Blazor
<script src="_framework/blazor.webassembly.js"></script>
This is what the page looks like on github pages:
<script src="js/index.js"></script>
<app>Loading...</app>
<p>Built with <3 using Blazor
<script src="_framework/blazor.webassembly.js"></script></p>
<script type="text/javascript">var Module; window.__wasmmodulecallback__(); delete window.__wasmmodulecallback__;</script><script src="_framework/wasm/dotnet.3.2.0-rc1.20222.2.js" defer="" integrity="sha256-iZCHkFXJWYNxCUFwhj+4oqR4fkEJc5YGjfTTvdIuX84=" crossorigin="anonymous"></script></body>
Why is this error happening and how can I fix this? I've thought about create a script that would remove the integrity attribute, but I don't think that would be a good solution.
I found an answer here
Cause
Because I am using github pages to host my blazor app, it's using git to push up the code. Git by default will try to normalize line endings when committing code, which was causing the integrity of the blazor app to fail due to the files changing.
Solution
To fix this, I added a .gitattributes file to my blazor folder with * binary as the contents.
This tells git to treat all files as binary and therefore not to normalize the line endings. After I did that, I had to delete my _framework folder in my blazor app and rebuild it. After doing this, the blazor app worked.
In case someone else ends up here with the issue I had today..
I also got this error on a Blazor Wasm app locally after simple modification, and then still appeared after reverting changes.
The solution for me was to do a clean and rebuild.
In my case, it was a wrong target framework in the publish profile - I should not have selected win-x64.
I'm not sure of the exact reason, but the server interferes in some way with the response, based on the target framework. Just select browser-wasm and redeploy; it should be fine.
I spent too much time on this issue. Clean and Rebuild does not work for me.
What worked for me is deleting bin and obj folders from the Client(Blazor WASM) Project.
Environment
.Net 5 and 6
Visual Studio 2019 and 2022
Just to leave here a note on something I came across while trying to figure out what was going on.
If for some reason you removed the service worker from your app and the resources were actually cached in the common http cache, there is a possibility that once you re-enable the service worker you will get this error, because the service worker will pick up the http cached version and not the server's.
What I did was to add cache: "no-cache" to the Request's init.
So my onInstall now looks something like this
async function onInstall(event) {
console.info('Service worker: Install');
// Fetch and cache all matching items from the assets manifest
const assetsRequests = self.assetsManifest.assets
.filter(asset => offlineAssetsInclude.some(pattern => pattern.test(asset.url)))
.filter(asset => !offlineAssetsExclude.some(pattern => pattern.test(asset.url)))
.map(asset => new Request(asset.url, { integrity: asset.hash, cache: "no-cache" }));
// Also cache authentication configuration
assetsRequests.push(new Request('_configuration/TestApp.Client'));
await caches.open(cacheName).then(cache => cache.addAll(assetsRequests));
}
It looks like hash generated inside ServiceWorkerAssetsManifest for all the files and on the client side don't match. It looks like ServiceWorkerAssetsManifest is not generating hash again when the file is modified, specially the static files.
Had the same problem today, in my case the error came with a css file.
The problem was that I had two versions of my application deployed to local folders.
At first I started the old version, closed it and then opened up the new version.
It seems that the old css file was cached in the browser which caused the error to appear.
The fix was simply pressing CTRL + U to open up the index.html file, clicking on the css file which caused the error and press F5 to reload the file. This solved the error for me.
A better solution!
Open service-worker.js
change
.map(asset => new Request(asset.url, { integrity: asset.hash }));
to :
.map(asset => new Request(asset.url));
Now it works!
I Had this same issue and none of these solutions worked for me, but they set me on the right path. I am deploying mine to my local machine and using IIS for testing purposes, and I found that in the publish profile that I have created in Visual Studio 2022, the check box to "Remove additional files at destination" was not checked and as soon as I checked this and republished it, everything worked fine. I must have removed a file that was being published in a previous build and it was still there since it wasn't being deleted by any subsequent builds/publishes. But this solved it for me, it might
I'm trying to set up a HikVision IP-based camera for some work I'm doing and it refuses to log in to the camera (the login button appears to do nothing).
The reason for this, when I break out the Chrome debugger console and investigate a bit deeper, is that the inbuilt login.js file (the one supplied by the camera) contains the code:
function document.onkeydown()
{
and the browser is complaining that the . is an invalid token in this context.
So my first question is simple: is this valid or invalid Javascript?
If it's invalid, I just have to track down the developer for a good talking to :-)
If it's valid, how do I get Chrome to stop complaining so that it can continue to process the rest of the file (including the definition of login function which is what would normally be called when I click on the login button)?
And, if it's not invalid and I don't want to wait around for a vendor fix, is it viable to just replace the login page and the Javascript file with local ones?
In other words, have those two files on my desktop (using 127.0.0.1) but have them reference all the other ones on the camera itself (192.0.0.whatever).
So, rather than accessing http://camera.com/page/login.asp which contains:
<script type="text/javascript" src="../script/login.js" />
<script type="text/javascript" src="../script/other.js" />
<script type="text/javascript" src="../script/again.js" />
I'd instead access file://login.htm, which would contain:
<script type="text/javascript" src="my_good_login.js" />
<script type="text/javascript" src="http://camera.com/script/other.js" />
<script type="text/javascript" src="http://camera.com/script/again.js" />
There is a problem with the firmware for some early HikVision cameras, in version 4.x.
The best solution is to upgrade the firmware to 5.2 where the Javascript code in the firmware is fixed.
This can be done with the SPD tool from HikVision itself.
However, if that's not an option, the scheme suggested should work. You just have to ensure that you correctly copy the errant firmware files off the camera onto your local box. That means:
Making an exact copy of the top-level page and errant login Javascript file locally (meaning on your host machine rather than the camera). This is probably as simple as just cut'n'pasting the browser source for both into new files(a).
Fixing the local copy of the errant login Javascript file, replacing document.onkeydown with the correct onkeydown.
Ensuring that you use the local top-level page from your browser rather than the on-camera one: this will ensure it uses the local login Javascript file.
Having that top-level page use your fixed login Javascript file: given it is a relative URL, that should work without change.
Ensuring the local top-level page accesses the other files on the camera: this will entail replacing the relative URLs with absolute ones.
(a) The only worrying possibility is the fact your current top-level page is an ASP one, whereas this process gets its HTML output fro creating the local top-level file. If the ASP file on the camera simply generates the same HTML each time, you'll be file.
However, if it's more complicated than that, you may have to do something tricky like extract the HTML from the camera each time with a script and massage it to change the URL accesses within a local page. Then access that local page from the browser. This could be automated but it's starting to get a little more difficult.
So, all in all, an upgrade to later fixed firmware is probably still the best option.
I cloned an existing magento 1.7.2 installation on the same server with a test subdomain. The frontend seems to work, and I can login to the admin. The admin menu doesn't work however, no dropdowns, and copying url paths doesn't work either. I've searched online, and most answers date back to 2008 and suggest that it's a rights issue. So I've changed the rights of folders and files to 755 and 644, but still no working menus. The cache (var/cache) is empty.
These menus are javascript generated. The following error message is from the console:
Error: TypeError: Element.addClassName is not a function
To be clear - the solution is not in javascript, but it's something on the server. This install works on the same server in another directory with another domain.
Any ideas how to fix this?
The error
Error: TypeError: Element.addClassName is not a function
indicates some javascript on your page can't call the addClassName method.
The addClassName method is added to element via the prototype javascript framework.
That means its very likely your browser can't download the prototype.js file. Since it can't download this file, the addClassName method is never defined, and you get the error you're seeing.
Look at the source code of your admin pages and find the script tag that includes the version of prototpye shipped with your version of Magento.
<script type="text/javascript" src="http://magento.example.com/js/prototype/prototype.js"></script>
Take the URL from this script tag and load it in your browser.
My guess is you'll get a 404 because the file is missing, or a forbidden error because the file has incorrect permissions, or some other web server error that prevents the file from being shown. It's also possible that the link is pointing to an older domain name that's based on a value configured or cached in Magento.
Track down the source of that problem, and you'll be good to go.
Another reason could be that the skin and CSS rules are not correct for your environment.
I've just moved a site from live to local, and the skin/css/media were configured to a subdomain so I looked in the core_config_data table and updated the URLs
Please check if you have set merge js or css to yes, you can update this via db if you cant do it via menu:
SELECT * FROM core_config_data WHERE path LIKE 'dev%'
Change from 1 to 0 merge_css and merge_js
In my case I have changed the permissions of folder and its recurring files and folder and it started working. Try it once.
Background
I'm attempting to upgrade an iOS app built on Cordova 2.0 to version 2.7.
It's basically a welcome screen that points to a remote search engine (please withhold comments about app validity and likely approval, as we're past that), and we were using the ChildBrowser plugin to enable opening links in a sub browser so as not to trap the user in the Cordova webview.
Cordova 2.7 has a feature called InAppBrowser I am hoping to use instead of ChildBrowser. InAppBrowser does essentially the same thing, aside from missing a button to open in Safari.
Problem
The existing app's remote webpages include the Cordova JS (as well as that for the ChildBrowser plugin) and it works fine for opening links in the sub browser.
My test Cordova 2.7 app doesn't seem to load the Cordova JS correctly when it's being loaded from a remote web page.
I tried using this exact same HTML on the embedded start page and a remote start page:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<script type="text/javascript" src="http://mydomain.com/mobile/cordova-2.7.0.js"></script>
</head>
<body>
<script>
document.addEventListener("deviceready", onDeviceReady, false);
function onDeviceReady() {
alert("Ready!!");
}
</script>
</body>
</html>
To test this as the embedded start page, I put this line in config.xml:
<content src="index.html" />
When I run the app, I promptly get the "Ready!" alert.
To test this as the remote start page (I'm aiming to link to the remote page in the final app, I am just using it as the start page for testing. The result is the same if I link from the embedded page.), I put this line in config.xml:
<content src="http://mydomain.com/mobile/index.php" />
When I run the app, I just get the blank screen and no alert.
Further, in cordova-2.7.0.js L. 6255, I changed
console.log('deviceready has not fired after 5 seconds.');
to
alert('deviceready has not fired after 5 seconds.');
With that change, running the app using the remote start page causes the blank page, and then after five seconds, I get the alert "deviceready has not fired after 5 seconds.". So this tells me Cordova JS is not starting correctly. Needless to say, I can't get InAppBrowser to launch links in the sub browser on the remote site, but I can get it working just fine on the embedded start page.
Anyone have any ideas of where to go from here? This is a pretty simplistic example, so I'm assuming this is a Cordova settings problem or a change in the functionality. I appreciate any thoughts, thanks!
Yes, something broke in 2.7 - related to our cordova-cli work. See: https://issues.apache.org/jira/browse/CB-3029
The fix is to add an empty file called "cordova_plugins.json" in your root folder.
I had a similar problem relating to upgrading to Cordova 2.7. However my problem was all my console.logs stopped firing when running the app. I couldn't figure out why for the life of me this was happening. I thought it was because I upgraded jquery.mobile. That wasn't it. I then thought it was an .htaccess issue, that wasn't it either. It turns out, it was Cordova 2.7 that was causing this problem.
I did try adding the .json file on my server, that did not fix the issue.
The fix was going into the 2.7 source and commenting out the following code:
/*comment out this as it is breaking console.logs
var xhr = new context.XMLHttpRequest();
xhr.onload = function() {
// If the response is a JSON string which composes an array, call handlePluginsObject.
// If the request fails, or the response is not a JSON array, just call finishPluginLoading.
var obj = this.responseText && JSON.parse(this.responseText);
if (obj && obj instanceof Array && obj.length > 0) {
handlePluginsObject(obj);
} else {
finishPluginLoading();
}
};
xhr.onerror = function() {
finishPluginLoading();
};
xhr.open('GET', 'cordova_plugins.json', true); // Async
xhr.send();
*/
Replace entire block with a call to the following function:
finishPluginLoading();
My logs are now working again. Only took me 3 days scratching my head.
Hope this helps someone with a similar problem.
If you embed Cordova in the external web page, there will be no way to open the InAppBrowser from within your hybrid app, so Cordova will not be able to load. This is because the InAppBrowser requires Cordova to be fully loaded and initialized before it can be used to fetch a remote page. You need to use your HTML page that you have, with the <script type="text/javascript" src="http://mydomain.com/mobile/cordova-2.7.0.js"></script> as the main entry point for your app. Then you can use the InAppBrowser to open up your remote page. (You could probably do this in the onDeviceReady(), not sure if it would "flash" the page first though.) I don't think the remote page should have any Cordova code in it at all. I'm not sure if it would be possible to even interact with Cordova from the remote page due to the Same Origin Policy (probably you could use features of the InAppBrowser to inject "bridge" code though to get around this.)
As Shazron mentioned the problem is the issue with the file"cordova_plugins.json".
To solve the problem not changing the code you can create the "cordova_plugins.json" file in the root folder and insert a content between quotation marks inside this file.
Mine for example has the following content:
"Just a dummy file required since Cordova 2.6.0"
create a file cordova_plugins.json that contains {}. then go to cordova-2.7.0.js and comment this line require('cordova/channel').onNativeReady.fire(); then when development done, add it back
Like me if you are using Cordova 5.1.1 and want to access native functionality after redirect then copy cordova.js, cordova_plugins.js and plugins folder which is at \platforms\platform_name\assets\www\ and put them on server, finally reference cordova.js inside your html. After every plugin add make sure to update these files and folder.
I'm getting a "Resource interpreted as Script but transferred with MIME type text/plain" warning in Google Chrome when including a local script file.
I know the problem appears when loading a file from a server or through ajax which most often depends on wrong headers being set.
The weird thing is that I get this warning even though it is run from a local folder: file:///C:/test/foo.html
This happens only in Chrome with the most basic html there is:
<!DOCTYPE html>
<html>
<head>
<script type="text/javascript" src="bar.js"></script>
</head>
<body>
</body>
</html>
bar.js is also as simple as it can get:
function hello() {}
I've tried adding a meta tag:
<meta http-equiv="content-script-type" content="text/javascript">
and tested with other doctypes but nothing seems to help.
This obviously isn't a real issue since the scripts still work fine, but I'm working on a large project and currently have around 150 scripts included. It therefore makes it difficult to see when an actual warning occurs in between them.
Everything works fine when I run the file on a server, locally or remote.
Any ideas on why chrome is annoying me with this?
I figured it out!
The Visual Studio installer must have added an errant line to the registry.
open up regedit and take a look at this registry key:
See that key? The Content Type key? change its value from text/plain to text/javascript.
Finally chrome can breathe easy again.
I should note that neither Content Type nor PercievedType are there by default on Windows 7, so you could probably safely delete them both, but the minimum you need to do is that edit.
Anyway I hope this fixes it for you too!
I tried fixing this problem using this method but it didn't work for me.
My problem was that IIS manager didn't have MIME types in HTTP Features.
I was able to turn it on by enabling Static Context via...
--> Control Panel
--> Programs
--> Turn Windows features on or off
--> Internet Information Services
--> World Wide Web Services
--> Common HTTP features
--> [X] Static Content.
After this, MIME types appeared and everything started working again.
The accepted answer is a great one! However, just to post an answer for those who encounter problem like me, who use a department/college computer sometimes, where I do not have the permission to change any key value in regedit.
Change
<script type="text/javascript" src="main.js"></script>
to
<script src="main.js"></script>
Although the error message still exist, the page loaded correctly.