I'm attempting to set up Pinned Site features for my project. The trouble is that I'd like to have the tasks be javascript actions rather than loading a new page. The reason for this is that the site is designed to only ever work in a single window.
I tried adding the following META tag:
<meta name="msapplication-task" content="name=Test Action;
action-uri=javascript:ui('test',8);icon-uri=/img/icons/test.ico" />
However this causes the task to simply not appear. (Using a normal URL makes it show up just fine)
Is there any way to do this? The best I can think of is a hash and check for the hashchange event, but this doesn't work because it gets opened in a new tab of the window...
I'm afraid this is not supported, because action list is designed for launching an application, not for a navigation inside it.
If you really want implement it, you can open a new window, send a message to server via web sockets and let server to forward that message to application window also via web sockets. But this is very hacky approach and works only in IE10.
This issue can be resolved by using a hash. By setting the action-uri to something readable by JavaScript, the JS can then read it, process the instruction, and then clear the hash in preparation for the next task.
This has the advantage that it works even when the window isn't already open, since the JS will read the hash on the first load too.
The catch is to add window-type=self to the content.
Related
I am trying to code a javascript that runs throughout different web pages. The script should type something into a search bar, click search, click a result, then save each result text into an array. It looks something like:
function returnresults(queries){
arrayofcontent = [];
for each query {
type query in searchbar;
submit search;
result[0].click(); // go to first result
arrayofcontent.push(pagecontent.innertext);
}
return arrayofcontent;
}
The issue is that the script seems to be stopping after the script clicks search, which makes me think that the script is unloading itself when moving to another page, even though I'm typing the script directly into the javascript console in Google Chrome. Does anyone know how to tell Google Chrome to keep running the script even after moving between pages?
Short answer: No.
When you examine what's happening in a browser tab (including working with the console), you are only able to inspect what's loaded in that tab. If you navigate to another page in that tab, everything that was in memory from the last page is thrown out and the new page content is loaded.
What you need is to store the state of the script and then retrieve that state on the other page. Storing state can be done in many different ways (cookies, localStorage, sessionStorage, server-side databases) and you'll need to decide which is right for your architecture and use case.
if you want to inject your script to different web pages you can do that by developing a chrome extension . A extension enables to inject your script depending on your logic
here is the link to get started
https://developer.chrome.com/extensions/getstarted
I wonder how sites like SoundCloud work: you play a song and it keeps playing even if you move to another page without stopping
Any suggestions?
The only way I can think of is to build your app, or at least the parts of it that need to bo continuous, as a single page.
In practice, this means that only one HTML document is loaded. When, say, a link is pressed, the browser action is intercepted and prevented and the browser behaviour is faked by javascript.
Consider a website consisting of pages A and B. Normally, when a link pointing to B is activated, the URL is changed and the browser calls the server, requesting B. In a single-page application, however, this is interrupted by a javascript function, which changes the URL using the History API, and then displays B in a way that doesn't require a new document being synchronously fetched from the server.
There's a couple of ways to do it.
Navigate to a new page
If you do that, a whole new JS execution context is created for the new page, so you can't keep the function running. What you can do however is to "resume" execution in the new page. For this you need to save the state of the old page either on the server or in some client storage that persists between page changes (cookies, localStorage, etc).
Fake navigation
This is the most user friendly way - you turn your website into a web application. You no longer have multiple pages, so when user wants to change what he sees in the browser (like go to a new song), the app simply changes the appropriate area with the desired content. This is a complex topic that should probably be researched in itself, not explained in a SO answer. Go ahead and google "single page application" and you should find plenty of resources for it.
Technically you never change the page when you are using souncloud. You always stay on the same page and only the parts get changed which are actually changing, so you never reload the whole page. That's why they can keep the music playing: They just never remove or change the actual player. If you are wondering why the URL in your browser is changing if you never leave the page: They manipulate your history entries.
If you are interested in creating an application that behaves similar you should checkout frameworks like Ember.js or Angular.js. TodoMVC Gives a nice overview of those frameworks.
Can Javascript cause browsers generally (and Chrome for Mac in particular) to invoke an external helper application for a URI without opening a new tab/window, or navigating away from the current page?
The context is that I am developing an extension for Chrome that occasionally needs to invoke particular actions outside of the browser. Using the rather neat trick described here, the extension only need open particular URIs to invoke suitable AppleScript.
However, how should one open such URIs from a script running in an extension's background page? I don't think XMLHttpRequest will help, as Chrome won't (shouldn't?) attempt to use an external helper application for XHR; nor does it appear that setting window.location.href has any effect on such a background page (it is not a problem if the background page is unloaded).
My current solution is to open a new window, but it's unnecessary and rather distracting for the user.
There are a few options here:
You could write an NPAPI plugin.
You can use a WebSocket client in the browser, and run a local server on your desktop. That way you establish a tunnel to your local machine to do pretty much anything you want there.
I did this for relaying global media key presses to control web-based music players and wrote it up. Source here.
I just realised I can do this with an <iframe/> in the background page. Très simple!
I'm writing an in-browser Chrome app that will allow users to edit HTML and JS code and then be able to test their changes live.
My current method of doing this is to create a new window with JavaScript, create an IFrame in that window, and then inject the user's HTML or JS code into the IFrame. The problem with this though, is that the page load events of the IFrame can't be used by the script being live-tested. My app could manually call testWindow.iframe.contentWindow.onload, but that wouldn't work with the various events and methods used by the different JS libraries for their "domready"-style events.
Perhaps this is not possible, and I'll just have to send the code to the server and have the server output it. I noticed apps like jsfiddle actually just ask what library and event you want.
Any ideas on how I can have live-testing in my app and still fire page loading events for the JS being tested?
You could use dispatchEvent on the iframe, which you know will be supported since you are making a Chrome app. Alternatively, for absolutely certain cross-browser compatibility (or some other reason) you could also send the script to your server (using Ajax) to be stored in a database, then linked to in the new window.
Just heard a lightening talk on http://vowsjs.org/ this evening. Haven't used it yet but I plan to explore this for testing web apps.
We have a product that has both a winforms and a web client, and are providing the users a way to launch into another company asset (a web application). We need to make sure that the user only ever has one instance of the other web application open in a browser (or at least that we've opened for them). We accomplished this (sort of) by doing the following...
In the winforms client, we have a hidden WebBrowser control that, when the user clicks the button to launch the other app, we write a small HTML page into the DocumentText property that contains:
window.open('http://othersiteurl', '**sitename**').focus();
In our web client when the user clicks on the same button we do something similar:
window.open('http://othersiteurl', '**sitename**');
From only one client or the other this works surprisingly well. Where things get sticky and weird is when you try accessing it from both clients. If you launch the other product from the winforms app first, it launches a new window, and any subsequent launches of the product from either client load in the instance that's already open. But if you do it the other way around, and start from the web client, the first instance launches in a new tab in the same window, but then every launch from the winforms client goes to a new window!
I'm using the same value for the 'name' parameter of the window.open in both clients. It's bizarre to see it work so horribly different. Can anyone explain how the 'name' parameter is scoped in IE? (yes, this is IE-only...the WebBrowser control hosts IE, and our product is IE-only) When launching from the winforms client first it seems to be global to all open instances, but the other way around makes it seem very much the opposite.
Any ideas?
Have you tried window.createPopup? Dunno if it would work any better, but if you don't need the "chrome" it might be worth a shot. For more info check out the MSDN:
http://msdn.microsoft.com/en-us/library/ms537638(VS.85).aspx
Under IE7, and prior versions as well to my knowledge, the name parameters is scoped to a particular instance of the IE process. Typically, starting IE manually creates a new process. Any windows that are created via js or even clicking the "New Window" button within IE, creates a new window that is still running under the current process. Under this condition, the name is in scope across these windows.
When you have a desktop application spawn an instance in the way you mention, it is opened under a new process. Depending on the framework (.NET, etc) it may reuse the process once it has a handle to the first, or it may create a new process for each call. It sounds like, from your initial testing, that the first is the case, where the application will reuse the process.
That being said, I am not sure what kind of process you may have to implement to check for the name "cross-process". One option, depending on what kind of control you have over the web application they are accessing, could be to have the server keep track of a list of user to session ids and when a second entry shows up for a user, that means they have a second browser open, and handle appropriately from there.