I am experiencing an issue with opening a Microsoft Office Document, using IT Hit WebDAV AJAX library, in latest Chrome 39.0. running on Windows OS. It is a sporadic issue that occurs only in Chrome, and it happens when one opens a document multiple times. Word instance won't start, the page freezes and browser becomes unresponsive, and Chrome suggests killing the page. The only solution is restarting the browser, which solves the issue.
I have tried opening a document in Chrome on Mac OS X, and it is working fine. So are Mozilla and Safari on all operating systems. It seems to be a Chrome + Windows issue only.
Has anyone experienced this issue and is there a fix?
The Microsoft Office plug-in that opens the document displays a warning popup "Some files can harm your computer.", which is a modeless dialog:
If you quickly click on a link that opens the document more than one time the dialog will hide behind the main web browser window. As a result the web browser window is blocked.
You need to switch to that dialog and confirm or reject document opening, otherwise after some time Chrome will ask you if to kill the page or wait.
Note that there is no way to avoid that dialog, this is a built-in MS Office functionality as far as I know.
Chrome will only work good with ITHitWebDAV if the user has got Office 2013 or superior.
Google is blocking all Java applets and NPAPIs now, so good luck with that. I just detect the browser of the user that wants to edit a document, and if it's chrome, I warn him to change to another browser like Firefox with a modal, and that's all.
Very poor support between Chrome and ITHitWebDAV, and no much you can do about it.
Related
If I visit a site, I want to close the Chrome Web Browser. Is it possible to write such a program?
Under normal operation, this should not be possible. However, there have been cases where browsers have had well known bugs that could be exploited. To be clear though, I'm referring to crashing the browser. There is no supported API or method of asking the browser to close.
For instance, a simple line of CSS could crash Internet Explorer 6. Something like this on Chrome would probably not work anyways, since Chrome runs each tab in its own process.
There is a way to close a browser window (tab) via script if your script opened the window, simply by calling window.close() (where window is the child window). Please see https://developer.mozilla.org/en-US/docs/Web/API/Window/close for more information.
I have a web application which supports two click once applications. The web application works well under IE11 and both click once application launch under IE11. However I was recently trying to get my web application to operate under Chrome version 65. I installed the following ClickOnce extension under Chrome:
Meta4 ClickOnce Launcher
Now the above extension would not launch the supporting Click Once application in Chrome. The Click Once applications were developed in VS 2010.
I use php to call the Click Once application
header( 'Location: http://sanplic02.corp.mycompany.com/LaunchCatia/LaunchCatiaPWBSTART.application?licence=DP2&computername='.DisplayComputerName());
Does anybody have any ideas as to why this is so.
Any help much appreciated.
Now I eventually got my web application to work in Chrome. All of the above is correct. The extension I used was the Meta4 Click Once Launcher. The line of php code above is also correct this is how I launch the click once application supported by the web application.
So what was the underlying problem. Well essentially I was disabling my submit buttons in code. Even though the submit buttons were programmatically disabled they operated correctly under IE11 another words the submit buttons appeared enabled in IE11. However in chrome on the other hand they were disabled, hence Chrome would not execute the script that launched the click once application script. So once I removed the code to disable the submit button all went well.
The joys of cross browser compatibility.
When Chrome stops WebGL and gives you the following error (in a yellow banner on top of the screen): "Rats! WebGL hit a snag...", and reloading does not work (WebGL is still not re-enabled), is it possible to re-enable WebGL without restarting Chrome?
Context:
Chrome disables WebGL probably because it requires too many resources: I ask it to display 400,000 billboards on Cesium, for those who know what this is.
I know how I could reduce the resources my app asks for, but actually I am exploring its limits for testing purposes. So I am going to make Chrome disable WebGL a lot of times, and I do not want to restart it everytime it disables WebGL.
My configuration:
Chrome 35.0.1916.114 m
Windows 7 Pro 64 bit.
Solutions explored:
I already tried to open a new Chrome window, it does not work. For the moment all I can do is close all Chrome windows and restart it.
I already tried to put --ignore-gpu-blacklist in the Chrome shortcut (even if I understood this is for Windows XP, right?).
Hope I was clear enough.
Thank you for your help.
I was having the same problem and I just found a solution. It sounds like this didn't work back when this question was posted but, it works now!
Refreshing the page doesn't work. If you clicked a link from a different tab to open the tab the crashed, clicking that link again doesn't work. You have to open a new tab and paste in the URL of the page that you want to reload.
I'm guessing this is due to chrome threading... by opening a brand new tab, you create a new thread instead of using the existing one.
In your application you should properly handle webglcontextlost and webglcontextrestored events. In particular, you should prevent default event action in webglcontextlost handler thus telling the browser that you can restore proper functioning of your app when webglcontextrestored will be fired.
With Chrome 32.0.1700.77 the new emulator tab is handy except it's the default tab when I refresh my page.
During my standard development workflow, I constantly refresh the page when I make changes. I usually have the console window open at the bottom of the network or source views. But every single time I refresh the page, the Emulators tab takes focus and I can't see the console.
This is truly annoying since the app will fail because of a simple JavaScript typo, but I can't see the console without clicking one more time (to focus the console tab).
Has anyone found a workaround for this?
Combined with the Chrome Developer Tools unresponsive since update 32.0.1700.76 m issue, I would have to say Google really tripped up this release.
Unfortunately there doesn't seem to be a workaround yet. It looks like there has been a bug reported to Google as found on this thread, but no fix has come about yet.
I think the only way (right now) to prevent the console tab from being hidden when needed is to avoid using the emulator or revert to a previous version of Chrome.
Hopefully a fix comes soon!
It's been a while since this post was made, but I came across the same issue recently. When you have the developer toolbar open, the phone icon beside the "Elements" tab should be blue. Clicking that will disable Emulation.
source: https://groups.google.com/d/msg/google-chrome-developer-tools/g_93_bKmaiA/SdHk0aXdEo4J
When I open a separate Chrome developer tools window in order to look at a page's JavaScript code I get this window in regular intervals:
When I click "wait" the window goes away but comes back soon after.
How can I get rid of this annoying message?
This happens on Chrome 32 on Windows, and on different websites (e.g. http://spiegel.de).
it does seem that the issue is with the 32.0.1700.102 version of Google Chrome.
I've got several users who are experiencing the problem. It only seems to happen when you are working with sites that open popups (the kind you want) such as opening and email in a new window in Google Mail.
Its seams like the latest update may have helped fix the issue(32.0.1700.102 m), or some users are reporting that the v33 beta does not have the issue. https://productforums.google.com/forum/#!msg/chrome/1PgURxP9_-k/It9TupoPEgQJ
Bug report here:
https://code.google.com/p/chromium/issues/detail?id=335248