In a non-trivial number of cases, esp. after I've had my browser open for a while, Chrome will fail to display a PDF document, showing the error "Couldn't load plugin."
I'm on OSX. I know the NPAPI and PPAPI issue is not relevant here. The Disable PDF Isolation flag these users describe has been removed.
Others suggest as workarounds changing the way you browse, either restarting Chrome more frequently and opening fewer tabs. I would prefer a solution.
The solution I ultimately came to was to use an alternative to that in-browser PDF viewer provided via an extension in the Chrome web store.
Related
When i using devtools in chrome the devtools console log things by him self, The devtools console.log exactly what i have on Local storage.
every single time when i open the devtools it is display automatically, I would love to disable this issue, I add image to clarify my problem.
[1]
[1]: https://i.stack.imgur.com/N8rBK.png
it was checked on all folder and file in my project and there is nothing about it.
as you can see it's came from contentscript.js.
I think contentscript.js is part of the Chrome extensions library which gets loaded everytime an extension loads. Most likely you have an extension installed that is logging those statements.
Try disabling extensions one at a time, to find the extension causing those log statements.
The filesystem API cannot be used by unpacked extensions, which is awfully great for development.
But then the real surprise came when I realized I can't use it also with my extension packed, because Chrome tells me it cannot find it in the store and is thus greyed out.
Is there any way to actually develop with the filesystem API then?
My goal, in case this is the wrong direction in the first place, is to write some text to a file when some events in the browser happen. The file should be rewritten, rather than creating a new file, which is why I can't use the downloads API.
Is there any way out of this conundrum?
For anyone stumbling on the same issue - a decent solution is to use the chrome.downloads API to download the file in overwrite and incognito mode.
Overwrite will stop the automatic indices added to downloaded file names, and incognito makes the download invisible in the browser except for incognito windows.
The main shortcoming is that it is of course constrained to the user's downloads folder.
I am trying to use MSAA (on Win7) to get the addressbar in chrome browser and replace it with a different url. When chrome is launched normally (as the loggedon user), I am able to find the addressbar using the IAccessible interface by traversing through the UI tree of the window classes owned by the process.
However, if I launch chrome as a different user (by using RunAs in windows), I see window with name, "chrome legacy window" when going through the classes owned by the "RunAs" process. The window hierarchy and the content within is vastly different from what I see if I scan the process that is running as the logged on user.
Although I can see (window classnames) Chrome_WidgetWin_0 & Chrome_WidgetWin_1 in both the browser instances, only the one running as the current user is giving access to the address bar.
Any idea on what is happening when chrome is launched as a different user? Is there any workaround or should I be looking at a different technology?
As Penn has noted this may have something to do with the PDF view which has caused peculiar problems in the strangest of places.
Looking at the bug tracker here it looks like sporadic behaviour with PDFs and the "legacy window" has been introduced in a recent build so perhaps try rolling back to an earlier version of Chrome.
Also I presume you are using chrome://accessibility with
Global accessibility mode: on
Show internal accessibility tree instead of native: on
or starting chrome with the flag --force-renderer-accessibility it seems to be a prerequisite for other automation programs like autoit as seen here.
If you can't get this method working I'd recommend trying the autoit script there.
Here is an autoit code example that shows grabbing the address bar and using it for general navigation, upon other things!
I have found that if a PDF file is open in the chrome viewer (in some versions of chrome) the window you referred to appears. Please confirm what URL is being used when you open chrome.
I have also read that a password request prompt can cause the same window to open. The PDF window only appears if the window is launched by certain processes/users
Basically what I need is a way to automatize the result of the following operations:
open a new tab;
open the Network tab in the developer tools;
load an URL;
select "Save All as HAR".
Often, proposed solutions involves the use of PhantomJS, browsermob-proxy, or pcap2har; those won't fit my case since I need to work with SPDY traffic.
I tried to dive into the Google Chrome Extensions API and indeed I managed to automatize some tasks, but still no luck for what concerns the HAR files generation. Now this method is particularly promising but I still can't figure out how would I use it.
In other words, I need something like this experiment from the Google guys. Note the following:
We used Chrome's remote debugging interface with a custom client that starts up the browser on the phone, clears its cache and other state, initiates a web page load, and receives the Chrome developer tools messages to determine the page load times and other performance metrics.
Any ideas?
Solution
For the curious, I ended up with a Node.js module that automates such kind of tests: chrome-har-capturer. This also gave me the opportunity to dig deeper into the Remote Debugging Protocol and to write a lower-level Node.js interface for general-purpose Chrome automation: chrome-remote-interface.
The short answer is, there is no way to get at the data you are after directly. The getHAR method is only applicable to extensions meant to extend DevTools itself. The good news is, you can construct the HAR file yourself without too much trouble - this is exactly what phantom.js does.
Start Chrome with remote debugging
Connect to Chrome on the debugging port with a websocket connection
Enable "Network" debugging, you can also clear cache, etc - see Network API.
Tell the browser to navigate to the page you want to capture, and Chrome will stream all the request meta-data back to you.
Massage the network data into HAR format, ala phantom.js
...
Profit.
For a head start, I have a post that with sample Ruby code that should you get started with steps 1-4: http://www.igvita.com/2012/04/09/driving-google-chrome-via-websocket-api/
By now there's a browser plugin to do that: https://github.com/devtools-html/har-export-trigger
It uses the WebExtensions DevTools API and I got it to work with both Firefox and Chrome.
See my code for Chrome here: https://github.com/theri/web-measurement-tools/blob/master/load/load_url_using_chrome.py#L175
Automatically installing the plugin in Chrome is a bit more complicated than in Firefox, but feasible - I extracted the plugin archive locally and then link to it in chrome_prefs.json (see same repository).
Not sure if it helps, HAR Recorder uses chrome debug protocol to record HAR and generate a har file (without opening devtools). If you want a variation, you can fork and make changes on it.
I have integrated the following page click here into expression engine. Only certain PDFs will download in chrome, as demonstrated in the link above, whereas with Firefox users are able to download all PDFs on the page. I've been searching through various expression engine forums and followed instruction such as disabling my XSS Filter and re uploading all my PDFs. I'm also running this latest version of EE and i've tried downloading PDFs logged out of the super-admin account.
I'm not sure whether this is a browser issue or an issue with expression engine, has anyone come across this problem before?
It looks like you're delivering those as type application/octet-stream. You'll want to start, then, by delivering them as application/pdf. Add this to your .htaccess (if you don't have access to you Apache config or can't reload your Apache config):
AddType application/pdf .pdf
This is an apparently common issue with chrome. But, since chrome is up to date with HTML5, we can use the shiny new download attribute!
Broken
Works