I'm trying to control the size and position of newly spawned Google Chrome windows via the command line (through C#.)
My command line ends up looking like:
--new-window --window-position=100,100 --window-size=800,600 www.UrlToOpen.com
However, the new window just opens over top of where the last Chrome window was started.
The end result I'm looking for is to be able to start multiple instances of Google Chrome, in separate windows, with a specific location and size. The only way I've been able to do this so far is by specifying that each instance is to have it's own --user-data-dir. However, this is not ideal given how many extensions a user may have installed, and it would not be the best user experience.
Does anyone have any suggestions?
If Chrome is not programmed to allow this, you only have one option.
Create the process and keep the process object.
Use Process.MainWindowHandle to get the newly created window (you might need to use a loop and Process.Refresh, or Process.WaitForInputIdle)
Use the SetWindowPos native function to position the window wherever you want it.
Native hooks could be used to detect creation of the window, but that requires you to create an unmanaged DLL.
I have another idea for you, why not use a chrome extension for handling the positioning.
Background: We had related difficulties. Internal webapp that opens multiple documents in windows, and need to be placed in other monitors.
The javascript does not support this, for security reasons and only a native extension can properly work with the tabs/windows objects.
Therefore, we have created an open source chrome extension for doing exactly that: flexible windows position across multi-monitor setups.
Perhaps more interest to you would be the feature to use predefine templates. The template file is located in any webserver you like and therefore can be easily share across different users.
The chrome extension is called "MultiWindow Positioner" and its complete free. You can get it at the chrome store here
The actual source code you find in github in the project chrome-multiwindow-positioner
Disclaimer: I am the maintainer of the open source (MIT) github project. If there any interesting idea, or comments feel free to share them here.
Related
I have a personal chrome extension that always runs in development mode. I need it to communicate with a public extension (execute one of its function to be more specific).
Is there any way to get background page of the other extension so I can do this?
I also tried modifying source code of the other extension manually but then chrome show it as corrupted and ask me to reinstall it
Not really, no.
You cannot inject scripts into chrome-extension:// origin of a different extension, and attaching a debugger there (without whitelisted, private APIs) is going to be tricky (custom launch flags), if at all possible. Note that there's a feature request to allow that.
As suggested by wOxxOm, your best bet is to create a personal copy of the other extension (if at all possible); perhaps adding hooks for External Messaging or merging your code in.
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
I am building an extension for Chrome which gives the user a basic API. I would like for other developers to have the ability to add functions of their own to my API. For example, some developers offer a new "plugin" (which is only JavaScript code), and I want users to be able to download that plugin into their extension.
The main problem I'm facing is this:
How do you load new code into an extension permanently?
Ideally I would like to add code into the extension's JavaScript, but I have no way to write to the file; I am under the impression that I am restricted by JavaScript - is this true?
While I could perhaps load new code dynamically (by downloading some script), that code will only hold for the current run, and is not added permanently. Rather, it is gone once the user reloads the extension.
The only solution I can see so far is to create a login system where I save each user's downloaded plugins and give him the mandatory option to load them every time he opens the extension.
This method is very messy and impractical, because I don't want to make a user login every time. In fact, I would very much like to refrain from using any login system whatsoever.
What I desire is something similar to what the GreaseMonkey extension does, which is the ability to let users write scripts and allow other users to be able to download them.
I'm obviously looking to create an extension which is much smaller and simpler than GreaseMonkey, but something like GreaseMonkey is more or less what I am looking for.
Any thoughts or suggestions?
All of the "plugins" will be independent chrome extensions. You can then use Message Passing to send a message to every installed extension and the ones that are plugins should have code that goes something like:
if recieve "some identifying key"
then respond "information about this plugin"
Now your main extension knows what plugins are installed and can load their JS files using chrome-extension://[extensionID]/file.js".
That should get you started :)
I would like to develop a browser plugin/extension (I'm not sure how they differ) for a particular (possibly new) file type. To be very explicit, I would like to visit a file, "foo.org", using my browser in something like Drop Box or Google Drive and have the browser treat the file as Emacs would treat an org-mode file. Eventually I would like to develop a full Emacs plugin/extension and be able to configure the browser to handle files with this plugin/extension based on the file extension or a file grokking heuristic.
Any solution that I develop will allow the editing to take place directly in the browser's tab area, i.e. a seamless solution (as opposed the useful but seamy Edit with Emacs solution referenced below). In the same way that Chrome recognizes a spreadsheet or word document and invokes the appropriate Google Docs tool, I would like to get an Emacs-lite editor handle the foo.org file. Another way to ask the question is: how do Google Docs tools get invoked within Chrome and perform the associated editing task. And are these tools open source?
You should consider building on Ymacs which is an Emacs-like editor in the browser.
For browser extensions, there is an experimental downloads api. However, it doesn't let you monitor downloads at the moment. This is planned for the future:
In the future, you will also be able to monitor and manipulate downloads.
However, you can probably just use some JavaScript and replace all links to *.org files with links that open in a tab running Ymacs. This should have the same effect--clicking a *.org link will open it in a new tab.
Take a look at content scripts and the tab api for documentation on how to inject a script into every page and how to open new tabs.
Take a look at Edit with Emacs , it should help you get (at least) part of the way there.
I'd like to try my hand at some Chrome Extension Development. The most I have done with extensions is writing some small Greasemonkey scripts in the past.
I would like to use localStorage to store some data and then reveal the data on a extension button click later on. (Its seems like this would be done with a popup page)
How do I run a script everytime a page from lets say http://www.facebook.com/* is loaded?
How do I get access to the page? I think based off my localStorage requirement I would have to go down the background_page route (correct?) Can the background page and popup page communicate across the localStorage?
UPDATE:
I'm actually looking to learn the "Chrome way". I'm not really looking to run an existing Greasemonkey script
Google actually has some pretty good documentation on creating extensions. I recommend thoroughly reading the following two articles if you haven't already done so:
http://code.google.com/chrome/extensions/getstarted.html
http://code.google.com/chrome/extensions/overview.html
If you want to give your extension access when the user browses to Facebook, you'll need to declare that in the extension's manifest.
Unless you're wanting to save data beyond the life of the browser process, you probably don't need to use local storage. In-memory data can just be stored as part of the background page.
Content scripts (which run when you load a page) and background pages (which exist for the duration of the browser process) can communicate via message passing, which is described here:
http://code.google.com/chrome/extensions/messaging.html
Overall, I'd suggest spending some time browsing the Developer's Guide and becoming familiar with the concepts and examples.
Chrome has a feature to automatically convert greasemonkey scripts to extensions!