I have a very, very weird issue that only seems to be an issue in Chrome.
When a user comes on the website, the user cannot focus any element (via mouse click, if they focus it via tabbing, the elements don't get the 'focused' state either) and that's only an issue in Chrome. That is, until the user resizes the window, minimizes the window, opens a new tab, opens developer tools, etc. Reloading the page does nothing. However, as soon as focus is "enabled", the user can navigate/refresh with purging cache, etc., close the browser and open it again, and everything works normally - the elements get the 'focused' state normally.
This behaviour can only be reproduced in Chrome and not on localhost.
The difference between localhost and beta environment is:
beta env requires authentication (basic http auth)
files in development env are concated in a single JS and single CSS file and both are minimized
beta env includes hotjar, while there's no hotjar on localhost
There are no custom event listeners that would listen for the 'resize' event. There are no errors in console and all javascript that doesn't depend on focused element state gets executed correctly. Hover events and all CSS styling that depends on hovered state all work correctly.
The main issue is, that a form which has to be filled out and includes a datepicker, cannot be filled out and thus the users can't really interact with the page. Datepicker doesn't open and, as the input elements don't get the focused state, they don't visually change (CSS :focused selector isn't working either) and thus give the impression to the user that they cannot type in the normal text inputs (which works, after clicking on the input, it is possible to type in the input).
I have tried removing hotjar and the problem persisted. The only thing that made the problem go away was removing the basic auth, however, that is not an option in this stage (it's a closed beta test, so we need to limit the access only to the users with password).
I also find it extremely odd that basic auth would interfere with the focused state of elements, especially as the error persists after you refresh and only goes away as soon as you interact with browser itself (minimize, open new tab, do anything that resizes your browser window or document), after that it works correctly and there are no errors whatsoever.
The problem only started to appear recently, but I do not believe it's an issue with the app itself, as I tried rolling back to a couple months old build and the problem persists. All of that makes me believe it's a bug in Chrome, but what can be done to fix it?
EDIT: I also tried to add autofocus property to an input element and, in beta environment, it doesn't get focused.
So it seems it indeed is a Chrome bug that's present both on mobile (Android and iOS) Chrome browsers, as well as desktop Chrome browser (tested both on a Windows and a Mac). I submitted an official bug report. In the bug report, a fellow user made a website that's accessible only through basic auth and only has 2 basic inputs, the input should get a red border on focus. As expected, after opening the webpage in Chrome (for ease of use - incognito mode), the input doesn't get focus and the border doesn't change.
For those who are also affected by this bug in Chrome, you can track the bug progress here: https://bugs.chromium.org/p/chromium/issues/detail?id=740652
Meanwhile, here's a hacky solution for those interested:
$(document).on("ready", function() {
var $inputs = $("input");
$inputs.off("click.trick");
if (!sessionStorage.fixedChromeFocus) {
sessionStorage.fixedChromeFocus = "true";
$inputs.on("click.trick", function() {
var win = window.open("/", "_blank");
setTimeout(function() {win.close()}, 1);
$inputs.off("click.trick");
});
}
});
The goal is to, somehow, interact with the browser outside of the current page, to make it somehow lose focus. You cannot use JS to minimize browser, cannot resize it, cannot open dev tools. What you can do, though, is open a new window. Of course, if you open a new window immediately, a pop-up blocker (as most people have it) will block it and the window itself (or rather your current tab) won't lose focus. Opening a new window can only be done as a reaction to a user event (without triggering potential pop-up blocker).
I also use some browser detection so the code will only be executed for Chrome and, using server-side conditioning, only for builds that include basic auth.
What the code does, quite self evidently, is that as soon as a user clicks on an input, it opens a new tab and quickly closes it, 1ms later. To prevent this from happening all the time, on every page load, sessionStorage, which gets cleared automatically after tabs from that domain are closed, is used (and we've already established that once focus starts working correctly, it will work as long as you keep your browser open).
The effect of this code is that the user will see a quick white flash the first time he clicks on the input, but everything will work correctly
Related
I open a new window to point at a page in a manual with var manual_win = window.open("", "manual");
I then set the location (after a bit of async code that tests the existence of the page) with manual_win.location = url;
This works and opens the manual page in a new named tab. I can later run the same code with a different URL and it works fine.
If the user edits the URL manually on the named tab to be some other site such as google.co.uk then the code no longer works on Chrome 76. It just brings the tab to the foreground and doesn't change the location. There is no issue with Firefox. I presume this is due to some sort of popup blocking logic in Chrome.
Is there any way to get around this?
It seems like a bug in Chrome that it blocks me from changing the location yet still brings it to the foreground. It would have made more sense for it to have cleared the name from the tab when it took control way from me so I end up opening a new tab instead.
I am in the process of developing a data visualization; however, I have run in to a problem that appears (seemingly randomly). When the page is first loaded, sometimes chrome will 'lock up'; The chrome toolbar will disable all command keys (ie copy, paste, select all...) and events will be incorrectly triggered (mouseover events get triggered on click, click events are triggered on double click, etc...)
I have already tried opening and closing the inspector window, searching for a memory leak, and trying to identify any infinite loops in my code.
I'm running a local http server via python 3, accessing the page via google chrome on macOSX, but I'm not sure if any of that may be related.
Edit: I found that clicking on another application other than chrome and then clicking back on chrome fixes the issue; however, I'd ideally want our user to not have to do that.
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 have a problem when I am trying to check the source of an interesting page which keeps refreshing automatically every 3-5 seconds (presumably due to some js script) which resets my Inspect Element Inspector window every time the page is refreshed.
Is there any other way other to stop that page from refreshing or perhaps the Inspector window from resetting itself other than turning on NoScript to stop the page from refreshing automatically?
Usually I just open DevTools, switch to the appropriate panel if necessary, and hit pause.
Opening DevTools: Via menus, or by press F12, Ctrl+Shift+I, or Cmd+Shift+I depending on browser and OS.
Switching panels: Pick the panel from the tabs at the top of DevTools. It'll be called "Debugger" (Firefox, IE) or "Sources" (Chrome) or similar.
Pausing: In the Debugger/Sources panel, click the pause button (usually looks like the pause button on a television remote control, ||) or press the keyboard equivalent. Keyboard equivalents are
Firefox & Chrome: F8
IE: Ctrl+Shift+B
(Updated 2020-03-30)
In Firefox 74 this option is in Options -> Privacy & Security -> Permissions
(Original reply)
Firefox has the option to prevent refresh natively, the option is in Advanced->General->Warn me when websites try to redirect or reload the page
The most popular solution for this problem is to trap the beforeunload event. The browser will ask the user for confirmation to leave the page. The code, in its simplest form, looks like this:
window.onbeforeunload = function() { return true }
You can enter this code in console. Alternately, you can simply paste the following URL in the browser address bar (console not required). You can even bookmark it.
javascript:window.onbeforeunload = function() { return true }
Be advised that modern browsers might chop off the javascript: part when you paste it inside the address bar; make sure you type it back.
To determine the cause of redirect in Firefox, try the following:
Open Web Developer Tools (CTRL + SHIFT + I), open "Toolbox Options" and check the "Enable persistent logs" option. This makes the logs persist across page loads (logs are cleared otherwise).
Now switch to "Network Monitor" tab.
Open the URL and let it refresh.
Inside the Network Monitor > Cause column you will find out why the page reloads.
The cause column is pretty ambiguous (Chrome does a much better job). However, if JavaScript was used to trigger page (re)load then it at least shows you the filename and line number of that script.
When the page is still loading, you can press the Esc key. While the page is still white, press it. When you stop the page from loading at this point, this usually stops all the auto loaded javascript. Any scripts that run on actions are usually not effected. Each page is different, try different timings.
When I use a site called NovelUpdates there is javascript that can make certain elements hidden, and when I press Esc on page load all the elements that would be hidden after page load are visible. Then when I click a button that would execute javascript that operates with no problems. NoScript isn't going to solve your issue I believe.
Another example of this are those websites with annoying boxes that pop out after 10 seconds that says you aren't a member and can't view any more of this site without logging in, like some news article websites.
What you could do is use the command exit(), which is the equivalent to die in php and simply stops the script.
If you don't know what's causing it and you don't want to look for the "bad boy", then you might as well stop the entire script at the very bottom of the page.
I'm trying to make Mozilla FireFox plugin showing notification. Notifications are visible for Windows and even Mac I want the user to click the notification and open the web page, it sounds pretty simple.
But when adding observer and making window.open or gBroswer.addTab window is opened and tab is opened but in case FireFox is minimized when the notification is shown windows are opened in background and not visible to the user.
Tried to use Components.interfaces.nsIAlertsService and chrome://global/content/alerts/alert.xul they work the same from this perspective.
Is there a way to tell the browser to be top most and be visible to the user?
It doesn't look like this can be done. Firefox generally only supports switching focus between different browser windows when one of them is already focused (via window.focus()). To handle notifications the way you want it (and the way Thunderbird does it) one would need to call SetForegroundWindow() on Windows - there are only two occasions in the Firefox code where this function is called. One is when a new Firefox process is started, the other is when one Firefox window is being minimized. Unfortunately, in this case neither can really be used and Thunderbird indeed uses custom code rather than existing XPCOM APIs to bring itself into foreground.