msapplication-starturl ignored in modern Windows UI - windows-8

Internet Explorer 10 and 11 on the desktop (“classic”) respect the msapplication-starturl meta tag. Allowing me to specify what URL to use when a user pins my site to their task bar in Windows.
In modern Windows UI (“Metro”), however, the meta tag is ignored. Whatever is the current page URL is used instead of the starturl.
I’ve used the msapplication-startpage URL to track how many users access my site using pinning. (By appending a campaign token to the URL.) Does anyone have a clever work around for tracking incoming users from the modern Windows UI?

Use JS in one of these two ways to track users pinning your site to the Start Screen.
SiteMode
http://msdn.microsoft.com/en-us/library/ie/gg491733(v=vs.85).aspx
This function will return true if the user has navigated to your site from the Start Screen. You can increment your counter every time it returns true
if (window.external.msIsSiteMode()) {
//Add 1 to your counter
}
mssitepinned
This will work with pinning on Immersive IE11 (but not on Immersive IE10).
You can use this event to track how many users are performing the pinning action to get yourself an absolute count of how many times your site has been pinned.
document.addEventListener('mssitepinned', IncrementCounter, false);
function IncrementCounter()
{
//Add 1 to your counter
}

Related

Headless Google Chrome: How to prevent sites to know whether their window is focused or not

Is there a way to prevent sites to know if they are visible or not?
Perhaps a command line flag? I checked here but I could not find anything suitable https://peter.sh/experiments/chromium-command-line-switches/.
I think they use the page visibility API: https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API
If your goal is to fool the visibility API, then inject this piece of script in the related page or frame:
await page.evaluate(`
Object.defineProperty(window.document,'hidden',{get:function(){return false;},configurable:true});
Object.defineProperty(window.document,'visibilityState',{get:function(){return 'visible';},configurable:true});
window.document.dispatchEvent(new Event('visibilitychange'));
`);
It first overwrites window.hidden to make it return false. Then, it fires the visibilitychange event to notify the document in case the page is already hidden.
Or to override the API as soon as the document is created:
await page.evaluateOnNewDocument(`
Object.defineProperty(window.document,'hidden',{get:function(){return false;},configurable:true});
Object.defineProperty(window.document,'visibilityState',{get:function(){return 'visible';},configurable:true});
`);
Page Visibility API
As per the documentation Page Visibility API comes handy when attempting to save resources and improving performance by letting a page avoid performing unnecessary tasks when the document isn't visible.
As per Page Visibility Level 2 W3C Editor's Draft:
The Page Visibility API defines a means to programmatically determine the visibility state of the top-level browsing context, and to be notified if the visibility state changes. Without knowing the visibility state of a page, web developers have been designing web pages as if they are always visible. This not only results in higher machine resource utilization, but it prevents web developers from making runtime decisions based on whether the web page is visible to the user. Designing web pages with knowledge of the page's visibility state can result in improved user experiences and power efficient sites.
With this API, web applications can choose to alter their behavior based on whether they are visible to the user or not. For example, this API can be used to scale back work when the page is no longer visible.
Visibility states
The Document of the top-level browsing context can be in either of the following visibility states:
hidden: The Document is not visible at all on any screen.
visible: The Document is at least partially visible on at least one screen.
The visibility states are reflected in the API via the VisibilityState enum as follows:
enum VisibilityState {
"hidden", "visible"
};
Extensions
This specification extends the Document interface as follows:
partial interface Document {
readonly attribute boolean hidden;
readonly attribute VisibilityState visibilityState;
attribute EventHandler onvisibilitychange;
};
An usage example
To improve the user experience and optimal CPU and power efficiency an application can autoplay a video when the application is visible, and automatically pause the playback when the application is hidden:
const videoElement = document.getElementById("videoElement");
// Autoplay the video if application is visible
if (document.visibilityState === "visible") {
videoElement.play();
}
// Handle page visibility change events
function handleVisibilityChange() {
if (document.visibilityState === "hidden") {
videoElement.pause();
} else {
videoElement.play();
}
}
document.addEventListener('visibilitychange', handleVisibilityChange);
Further, #MichaelMahemoff in this blog further states that, Multi-tab browsing being the current norm now, you can't assume the user is watching your app just because it's running and the new Page Visibility API lets your app discover if it's visible or not. You could use the API to cut down on unnecessary network activity and computation. If you are using any of the current Chrome or Chromium build you can try out in the console if the current page is hidden through document.webkitHidden. However, document.webkitVisibilityState will return a string indicating the current state, one of visible, hidden, and prerendered. A new webkitvisibilitychange event will fire when any of these changes, e.g. when the user opens you app's tab, or moves away from it.
Solution
All these interactions can be observed using the visibility.js which is a wrapper for the Page Visibility API and allows you to determine whether your web page is either visible to a user or hidden in background tab or prerendering. It also allows you to use the page visibility state in JavaScript logic and improve browser performance by disabling unnecessary timers and AJAX requests, or improve user interface experience (for example, by stopping video playback or slideshow when user switches to another browser tab).
Firefox specific solution: An alternative Firefox specific solution can be to use the Disable Page Visibility API extension for Firefox which disables the API for all pages.
Here you can find a detailed discussion on How to install extension permanently in geckodriver
Chrome specific solution: An alternative Chrome specific solution can be to use the Don't Make Me Watch extension from the Chrome Web Store.
Here you can find a detailed discussion on How to load extension within chrome driver in selenium with python

Managing session temporarily in ibm mobilefirst?

i have to develop a multipage application that includes invocation of several web services.
My first page has a login page. based on the user input i have to traverse to next page while calling the next web service simultaneously. so obviously this all depends on the login page information that has the userid and password and the response from the web service such as personId etc.
i need to store this information temporarily for a particular session but... how to do this?
There are two kinds of page:
There are the UI states as seen by the user. Your Login page and your Next page are examples of these. From the user's perspective they see a succession of pages.
However you are writing an App, a single controlling thing that is in charge of all those "UI pages". I suppose that you are using MobileFirst to create a hybrid application that is effectively executing in a browser. From that browser's perspective you have a single HTML page. This is important, MobileFirst only works with single-page applications.
Now the browser loads the HTML and JavaScript for your single application page and that JavaScript stays resident as the user moves between the different "UI Pages", so the JavaScript can have variables for keeping the state you are asking about. The actual UI navigation from "page" to "page" is usually done by hiding and revealing DIVs.
Hence your WebService call results will be delivered (asynchronously) to some JavaScript function you define, and in the meantime your code can hide the login page and reveal the next page as required. The login data being held in JavaScript variabes.
All of this is simplified by using a framework such as AngularJS which abstracts the messy details of hiding and revealing and dealing with asynch delivery.

SignalR inside _Layout.cshtml - persist connection

I decided to use SignalR for chat on my page. Chat page is opened when user clicks on "Enter Chat" link which is placed inside _Layout.cshtml. This works fine. However, what I would like to achieve is the following functionality:
On the left side of the page I would like to have some kind of
"online users" area and when one user logins, other users whose are
already logged in will be able to see that a new user just enters the
page.
Users who are online can chat with each other by simply
clicking on their names
I am using the following code to connect to the chat application:
$(function () {
//declare a proxy to reference the hub
var chatHub = $.connection.chatHub;
registerClientMethods(chatHub);
//Start Hub
$.connection.hub.start().done(function () {
registerEvents(chatHub);
chatHub.server.connect(#User.Identity.Name);
});
});
However when I place this code inside my _Layout.cshtml page, users are permanently logged off and connected again each time they navigate through pages (they are intended to be opened inside _Layout.cshtml).
Is there any way for persisting connection with the hub when navigating through page? What is the best practices when using this kind of functionality?
Whenever you navigate away from a page or in any way refresh the contents of the page you will need to start a fresh SignalR connection. There are two ways to handle this behavior when navigating through pages:
Create a single page application.
Handle users connecting/disconnecting on the server in such a way that they're not truly logged out until they leave the site.
Now to dive into a little more detail on #2. Users on your site may disconnect/connect every time they transition to a new page but you can control how they log out or appear disconnected via your server side logic. You can get this functionality by keeping a set of "online" users in your server side code and then only considering them offline after a specified timeout value.

Detecting Facebook canvas in Rails app

I'm using a before_filter to detect the signed_request query string Facebook generates when a user is referred to a canvas app.
Then, I set session[:canvas] = true and test for that when I need different app logic based on whether the user is in the canvas or on the native browser app. The problem is that if the user, for any reason, leaves the canvas and navigates to the browser-based app, the session[:canvas] variable is still set to true.
Is there a better way to detect the difference between the canvas and the native browser app?
I personally like to use an "alias" url for the Facebook app, e.g. use fb.mysite.com instead of www.mysite.com in the app settings and set things up so that the two domains point to the same place. Or something similar can be done with directories, e.g. www.mysite.com/fb/ pointing to the same place as www.mysite.com/ but giving an easy way for the code to determine if it's a direct access or from an app.
Using a session can work too, but you have to add an additional javascript check in the case you are currently in "app mode" (canvas==true). The javascript just checks to see if the page is inside an iframe, and if it is not then it redirects to something like www.mysite.com/thispage?app=0. Your pages should check for the app=0 parameter and clear the session if present (or set canvas=false). This way, if a user starts out inside Facebook but then visits your site directly, things automatically get adjusted correctly.
Instead of storing this information at the session, check for the existence of the signed_request parameter, if there is no parameter, it possibly means the user is not inside the facebook app anymore.
I might be completely wrong, but doesn't Facebook access your canvas content by a POST instead of a GET request? Wouldn't that be the easiest way to distinguish where the request came from?

How to detect if user has switched Rails 3

A user logs into my application in a tab in a browser
They get an email and click a link which opens a new tab in the same browser and logs them in under a different email say.
If they go back to the first tab they are no longer the same user and I want the page to automatically detect this and then reload or redirect them if they are unauthorized to view the page.
Anyway to do this?
Or, if you really want to know when user is switched the tab, try this library:
visibility.js
As stated by #Hck:
add javascript code to reload page periodically (for example once per 30 seconds) – Hck
JavaScript is pretty much the only way to make pages do stuff after they're loaded. Note that in pretty much any user authentication system, a given browser will only be logged in as one user at a time, so as soon as the second tab opens, that browser will be acting as the second user - they can still see the current content of the first tab, but links (for instance) will no longer work unless the second user was also authorized to use them.
There are some JQuery plugins that do this sort of thing, like PeriodicalUpdater, or you can write your own (an example).