I am trying to build a web app (to learn about WebSockets and adaptive behavior) that polls different social media sites and shows all the latest updates in one place. I want to make the page stop updating while out of focus, and then update again when in focus.
Testing the out of focus behavior has been very difficult, since I have to rely on logs to ensure that my app is working properly, and cannot have the window open in one monitor and work on the code in another monitor.
My question is:
Is there a way to "force" the tab to think that it is in or out of focus, like force element state in DevTools, but for the entire tab.
I am running Chrome on Windows 10. I could not find a way to do this using DevTools, and do not want to setup a whole testing framework just for such a simple thing.
Thank you for your time.
Open the Command Menu.
Run the Emulate a focused page command.
If you create a Live Expression and set the expression to document.hasFocus() you'll see that the page always thinks it's in focus after you run the Emulate a focused page command.
Related
I have been using Clojure, ClojureScript, lein, shadow-cljs, re-frame, reagent, Emacs, and CIDER to work on a Clojure/ClojureScript dynamic web app project.
Usually, I build the project by executing the command cider-jack-in-cljs in Emacs, choosing shadow-cljs, then shadow for REPL type, and, finally, app for the building option.
The application loads in localhost:3005 with a debugging dashboard. Apparently, this UI is called "re-frame-10x":
After clicking on the up-right arrow icon on the top-right:
I managed to pop out the debugging dashboard into a new window in Google Chrome. It was injecting some CSS and hiding a button on the webpage. Hence, I decided to "remove it" by popping-it out.
But, I would like to move it back to the browser tab that has localhost on the address. How to do it?
As suggested by #eugene-pakhomov, it was just closing that window. I must highlight that I had tried that before, the only problem was that there were multiple windows of that type. And all of them need to be closed for the process to work!
Not sure why the program opens multiple windows...
I'm trying to test changes to our website, which is a dynamic application. When making edits to certain elements, the visual editor gives a warning:
"The number of elements selected changed after the page was initially loaded. Make sure that your changes appear as expected using preview mode." I've read all the official Google documentation on this specific warning. See the layout here
I've enabled activation events, set it to optimize.activate and made sure it is being pushed to dataLayer.
When I preview in debug mode, it says the experience was applied, the activation event was triggered on 'optimize.activate' and the url matches. Yet only one of the changes have been applied. See here
When I open the console and call dataLayer, optimize.activate is right there.
I'm honestly baffled. I read here that filters on the Analytics view linked to your Optimize container can stop events 'showing up'. We use filters to IP block our staff from showing up in our Analytics data.
Any help on this would be amazing.
p.s. I'm not a developer so go easy on me :)
Ok this maybe for a couple of reasons... I've had a few instances where I can view changes in preview mode:
First of all, if you're viewing changes in incognito mode, you need to make sure the following option is switched off in your browser - Block third-party cookies. If this is switched on, then in preview mode, your browser will block the Optimize 360 cookie and your experiment will not run. (This means you will not see your changes).
Secondly, if you have Audience Targeting set, these features do not work or show in preview mode.
Thirdly, your test may not be firing on the correct event trigger. EG pageload. So make sure the correct event is attached to your AB Test. As you will be able to see the changes in edit mode, but again not in preview mode.
Your issue is likely to be point 1 or 3.
On the iPhone's Instagram app browser(in app) if you open a website that includes html inputs of any type, something strange happens.
In the beginning everything is working, but once you tap an input and type something ( and the keyboard is opened), after you close the keyboard you can't click on anything anymore because all buttons/inputs/elements are clickable in a different location than where they showed ( button is showed in the original 100px location but click events are now on 50px).
It looks like after the keyboard opens the whole location calculation is shifted up(because the keyboard pushes the whole body up)
How to even begin to debug such thing ?
Honestly, I've been there. There is no way to debug the in-app browser (you can try on an iphone device mirroring with Chrome in MAC, but you will eventually fail), but I've tried without success.
It turned out that after digging around with similar issues, there was a caching issue and some disabled features with WP ENGINE from my client. They were able to fix it by allowing some parameters on nginx settings and then the In App browser wasn't stucked anymore.
I know every issue is different, but at this time, I haven't found a way to debug the In - App browser.
I can't speak to iOS specifically, but there definitely are ways to remote debug things.
My go-to for stuff like this (speaking from experience of browsers on gaming consoles) is Weinre: https://people.apache.org/~pmuellr/weinre/docs/latest/Home.html You get something similar to Chrome Developer Tools, but it works over a Socket.IO connection.
Another tool I like to use is Fiddler. While it won't help you with your DOM issues, if you ever need to debug network stuff on oddball devices, it's perfect. It serves as a proxy server and can intercept all your connections, including HTTPS. https://www.telerik.com/fiddler
Turns out, that it's a fixed position and it's not supported, which means when keyboard is closed, the system will push back the whole view but click events stay up (because it's being pushed up when you open a keyboard).
So instead of make it an absolute modal, which has it's own problem, we keep it fixed, BUT, we do the pushing up/down by our own.
We could just push the screen back down on input unfocused, but if user click the next field you get unwanted behavior, so we create a delay based machine like so :
var isfocused=0;
var focusTimer=0;
$("input").blur(function() {
isfocused=0;
focusTimer = setTimeout(focusDone, 150);
});
$("input").focus(function(){
isfocused=1;
});
function focusDone(){
if(isfocused===0)
$(window).scrollTop(0,0);
clearTimeout(focusTimer);
}
This works great on social browsers, with fixed positioned modals that has inputs inside them.
My web application is mimicing the UI of my desktop application, flow is as follows
Select Task in browser window
Change any Options and then start
Show Progress in same browser window, the progress bar goess back to server every 5 seconds checking progress.
When task has completed we show report in new tab
and go back to Select task Window,
this is done by running following Javascript in progress page
window.open('/start','_self'); window.open('/reporturl','_blank');
This works fine on my PC but when trying on Safari on OSX and on Android phone and iPad one of two things happen
The progress page becomes the start page but the report page is not opened in tab
The Progress page becomes the report page
My question is does opening window in new tab with _blank have all the problems of using popup windows. If so should I modify my prcoess so that at stage 3 it just displays report page, and then add a back button or navigable footer to the report to allow user to get back to start page ?
I can think of some options you could use instead of new tab.
Modal with Ajax
-- With jQuery it is posible to open modal
dialogs they can be populated with html (or other data) fetched with ajax (async). I am a big fan of these and use them all over my projects. Users will not be annoyed with pop-up warning messages, etc. Once the content is read (or whatever) the user can simply close the dialog. (If I had to make your app I would certainly implement this).
Besides the jQuery dialogs, other modal/dialog scripts are out there. Check out Bootstrap Modal if you like it modern.
Serve report as download
-- Depending on what the user can/will do with the report, it might be interesting to write the report page in a way that it sends back a .pdf file, or another type of file, as download. Loading the URL in a new tab will now always start a download. Triggering this from JS without user interaction might be a problem though (same as with pop-up / new tab). Adding a button to trigger the download on complete will solve this.
I know the question was about the use of tabs.. But try to avoid it. Browsers handle it all in their own way. And many users get confused when suddenly stuff is opening in tabs when they did not ask for it. In case of pop-ups, it is possible for users to turn them of or convert into opening a new tab from within the browser settings. If they have been fiddling with browser defaults, you'll have troubles of keeping the 'flow' of the app the same for all users (and cross browser).
I'm trying to see a POST request that my browser is making on a certain form.
My problem is that the form is opened in a popup window (js initiated) and when the form is submitted it automatically closes the popup. So when I'm trying to use the developer tools' networking tab I can see the post request but don't have enough time to look into it since the window is closing too fast.
Even if I choose 'preserve log on navigation' it doesn't appear anywhere since the entire window is closing on submit.
Is there a way of opening the developer tools in the context of the entire Chrome application instead of a certain tab?
I don't believe there is. The best two solutions I can think of (that don't actually answer your question but I think achieve your aim) are:
Use another tool like Fiddler - http://fiddler2.com/ It's really good but only available for windows :(
It's a messy workaround but you could just comment out the line that closes the window while you carry out your debugging and then reinstate it once the issue is fixed.