For some interactive graphics we are using canvas in our HTML page. Inside the canvas we have "link-like" controls to link users to external resources.
Because of canvas, we do NOT use <a href=""> tag, but we are opening new browser tab via JS code, like this:
this.pixiLayout.App.renderer.view.addEventListener('click', () => {
if (this.pixiLayout.externalUrl) {
window.open(this.pixiLayout.externalUrl, '_blank');
}
});
The problem:
Google Analytics(front end) show us much more clicks than actual "page views" analytics from third party resources, up to 10-20 times.
It means that users clicked on the link(and it recorded by GA), but by some reason, link was not opened, or opened but not loaded in a new tab.
I know about ad/pop-ups blockers. It could be a case for some percentage of users. But it is not a case for 90% of users, like we have.
And we could not reproduce this behaviour on any device we own.
Question:
Could it be caused by normal browser policy or restriction that could cause a blocking of new tab like in our case?
Could it be like "new feature" of modern browsers I do not know about yet?
Ok, the issue was in our own code. Event firing of GA(we use custom events) was implemented in the different place of the code than an actual action - window.open(). They were supposed to be called on the same user action - user click. But it was not a case, specially for mobile devices. When user tapped on that interactive, link-like control and moved finger up or down(for scrolling), it fired custom event responsible for tracking "the click". But actual "click" event is not fired in this case.
Conclusion: never ever do an actual action in one place and "collect analytics of that action" in another place of the code.
Related
I've been refactoring some javascript.
Previously, I had an HTML element open to Fullscreen when the user clicked on another element.
Now clicking the latter element initiates a server-side verification, instead.
Once the server-side verification check passes, the page reloads with extra data confirming the user is verified.
N.B. When the page reloads, it does so with a non-negligible amount of extra markup, styles, scripts and vectors. The reason I am re-factoring in the first place is to avoid the need to download all these extra assets (and keep them in the background, on standby) unless and until the user authenticates themselves
The first thing I discovered is that I cannot have the page reload and then have the HTML element immediately open to Fullscreen, because - and this seems entirely reasonable from a UX perspective, Firefox reports:
Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler.
Essentially, unless the user pro-actively interacts with the page, the Fullscreen API will not run.
(In this scenario, the user pro-actively interacted with the page before reload, which is not the same thing.)
So, I thought about it and then added:
document.body.addEventListener('mousemove', () => myElement.requestFullscreen(), {once: true});
Nope. The Fullscreen API still doesn't activate.
To check that I wasn't making an elementary error somewhere else, I tried:
document.body.addEventListener('click', () => myElement.requestFullscreen(), {once: true});
Which does work.
So: some user-interactions will successfully fire the Fullscreen API and others won't.
I have searched through the WHAT-WG HTML Spec but I cannot find a list of events which represent explicit and pro-active user-interactions on a webpage.
Does such a list exist?
Which other events apart from click will successfully activate the Fullscreen API?
Which JS events apart from click will successfully activate the Fullscreen API?
A small number of events will successfully activate the Fullscreen API.
Almost all of these events either imply a user-click or directly reference one:
change
click
contextmenu
dblclick
mouseup
pointerup
reset
submit
touchend
Further to the list of click-based events above, the Fullscreen API may also be activated via:
ScreenOrientation.onchange
Source:
https://www.aworkinprogress.dev/request-fullscreen
Related to this question, the workaround to launching a custom protocol after starting a websocket (so as to keep the socket open and polling) is to use an iframe element and set the src to be the custom protocol. But, if a user clicks the button that sets the src too quickly (i.e. they trigger the custom protocol too frequently), FF logs this warning:
"Iframe with external protocol was blocked due to lack of user activation, or because not enough time has passed since the last such iframe was loaded."
I can't seem to find any documentation on:
What constitutes user activation
How much time "enough time has passed" actually is
Does anyone know what exactly that warning means or what either of those bullet points are and how we can get around the limitation to allow launching a custom protocol (without refreshing the page or causing a popup) from within FF?
I've tried both having the iframe exist on the page beforehand and dynamically setting the src, as well as, dynamically creating the iframe with the src at the same time, but both end with the same warning being logged.
User activation means an event triggered by the user, such as mouse or keyboard events. This is similar to the way popup blockers work.
I doubt you'll find the "enough time" limit documented -- the programmers don't want to tell malware writers how to work around the restriction.
You say you're doing this when the user clicks on a button, so that should fit the "user activation" requirement. Are you doing it in a callback function that runs asynchronously from the event listener? That disconnects it from the user interaction -- it has to be directly in the listener function.
I'm trying to create a simple JS function that will open a new window/tab when clicking a specific button, so the user will actually open 2 windows/tabs, however no matter what I do, one of the links gets blocked by Chrome as a "popup-blocked".
I'd like to do something like this:
$(document).ready(function(){
$("a").mousedown(function(){
window.open("https://stackoverflow.com/","_blank");
});
})
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
Click Me!
;
But when I do this, the button link doesn't work, but the JS does.
If I change the JS and add a setTimeout() to it, the button URL goes through but the JS gets blocked.
No matter what I do, I can't get both of them to go through.
Any help would be appreciated.
Navigating to two places at once, with one in a new window, is really popular with people who want to show the user a massive advert in a new window.
Massive adverts are unpopular with users, so browsers take steps to prevent this behaviour.
Sometimes legitimate uses get caught in the crossfire. Blame the blackhat end of the advertising industry.
You'll need to find some other way to display… whatever it is you want to display… to the user that doesn't involve navigating to multiple webpages at the same time in separate windows.
The problem is caused by the mousedown() event you are using which is a part of down+up sequence to trigger the click() event of the <a> tag.
so opening a new window "breaks" the flow and browser is not tracking for the mouse-up event anymore to follow the original url.
so the solution is to attach the click() event instead without stopping propagation. this will fire the attached and original events and none of them will be blocked.
$(document).ready(function(){
$("a").click(function(){
window.open("https://stackoverflow.com/","_blank");
});
})
you can try sample on this page as stackoverflow snippet is sandboxed and is blocking popups
Is there a cross browser event that can be used to show a message to the user returning to their web page?
For example, a user has ten applications or tabs open. They get a new notification from our app and I show a notification box. When they switch to our tab I want to begin our notification animation.
The activate event is common on desktop applications but so far, on the window, document and body, neither the "activate" or "DOMActivate" do anything when swapping between applications or tabs but the "focus" and "blur" do. This event works but the naming is different and the events that should be doing this are not.
So is the right event to use cross browser or is there another event?
You can test by adding this in the console or page and then swapping between applications or tabs:
window.addEventListener("focus", function(e) {console.log("focused at " + performance.now()) } )
window.addEventListener("blur", function(e) {console.log("blurred at " + performance.now()) } )
Update:
In the link to the possible duplicate is a link to the W3 Page Visibility doc here.
It says to use the visibilitychange event to check when the page is visible or hidden like so:
document.addEventListener('visibilitychange', handleVisibilityChange, false);
But there are issues:
The Document of the top level browsing context can be in one 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. This is the same condition under which the hidden attribute is set to
false.
So it explains why it's not firing when switching apps. But even when switching apps and the window is completely hidden the event does not trigger (in Firefox).
So at the end of the page is this note:
The Page Visibility API enables developers to know when a Document is
visible or in focus. Existing mechanisms, such as the focus and blur
events, when attached to the Window object already provide a mechanism
to detect when the Document is the active document.
So it would seem to suggest that it's accepted practice to use focus and blur to detect window activation or app switching.
I found this answer that is close to what would be needed to make a cross browser solution but needs focus and blur (at least for Firefox).
Observation:
StackOverflow has a policy against mentioning frameworks or libraries. The answers linked here have upvotes for the "best" answer.
But these can grow outdated. Since yesterday I found mention of two frameworks (polyfills) that attempt to solve this same problem here for visibly and isVis (not creating a link). If this is a question and answer site and a valid answer is, "here is some code that works for me" but "Here is the library I created using the same code that can be kept up to date and maintained on github" is not valid then in my opinion it's missing it's goal.
I know above should probably go to meta and I have but they resist changing the status quo for some reason. Mentioning it here since it's a relevant example.
The Page lifecycle API can be used to listen for visibilitychange events.
[This event triggers] when a user navigates to a new page, switches tabs, closes a tab, minimizes or closes the browser, or switches apps on mobile operating systems. Quote
Current browser support
Reference on MDN
I created a simple JavaScript function to display my pop-up window once it loads. But it keeps on being blocked by Firefox and Google Chrome and I have to somehow enable it on the Firefox and Chrome to display the pop-up.
Are there any alternatives for this?
I have a player on the pop-up window so I have to use a pop-up to let the player play automatically. The problem is that if I put it on the page itself, once the user clicks another page the entire page reloads and the player automatically stops for a few seconds until the whole page reloads and I have to prevent this from happening.
The general rule is that popup blockers will engage if window.open or similar is invoked from javascript that is not invoked by direct user action. That is, you can call window.open in response to a button click without getting hit by the popup blocker, but if you put the same code in a timer event it will be blocked. Depth of call chain is also a factor - some older browsers only look at the immediate caller, newer browsers can backtrack a little to see if the caller's caller was a mouse click etc. Keep it as shallow as you can to avoid the popup blockers.
Please take a look at dthorpe's answer here. It covers your question.
You could try putting the player on the original page, and using something like History.js to control page changes (you could have the main page body in one wrapper div that changes, and leave the player outside of it).
Otherwise, you could try (assuming you meant a HTML5 <video> or <audio> player) downloading the data to localStorage/cookie/[other persistent storage mechanism] and have it seek everytime you change a page.
It will be hard to stop browsers from blocking your pop up window, because any way to do so is inherently exploitable; however, if you call the function to open another window from an onclick event, you may be able to circumvent some popup blockers. Also, some popup blockers allow popups when using the https protocol, although not many have this feature, and https can be hard to implement for the average website, if you don't have physical access to the server.
One other option is to open the other page in another tab (like this w3c example; you can 'click' the link with javascript).
You might also want to look at this post, as it is somewhat similar.
I only just discovered you asked this question.
Here's the answer in full.
Basically, you can simply create the popup immediately as the user event is fired, then fill it with content (your player, for instance) as you have it available.