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.
Related
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
My webapp opens a popup window and then, after an AJAX request in the main window, it updates the URL of the popup window.
As I found out, on iOS devices, Javascript doesn't run in the main window when it's in the background (because the popup opened).
This seems to be a reasonable decision for the engineers who designed the mobile Safari to conserve battery power, so I can imagine other devices out there doing the same. (Are there?)
Now I could open the popup URL in the main window instead. However, since this provides worse user experience for browsers that can run Javascript in the background, I would like to detect this behavior beforehand. What would be the best way to do that?
I am working in vb.net 2005. I am in a position to start a new browser with process.start().
Now I have to open that browser in a specific size(say height:300 width:500)
Process.Start("firefox.exe", "abc.html")
and I have written this following code on load of abc.html
var myRef = window.open('abc.html','','left=20,top=20,width=300,height=500');
but it does not resize.
If I add 1 button on this page and click on it (by writing same code on its click event), a new window with expected size opens.
Am I going wrong somewhere?
Thanx.
Firefox doesn't let pages resize the window by default. Also note, if you already have Firefox running then browser preferences will dictate whether you get a new window or a tab. You can force a separate instance of Firefox by using the -no-remote command line flag, but then you won't be able to use the default profile (only one Firefox instance per profile).
My questions for you are:
Why are you launching Firefox from another executable at all instead of just having users click on a link and have it open in their default browser?
If you do need to launch Firefox from an executable, why spend all this effort overriding the user's preferences and settings?
If you' re launching from an executable and are keen to annoy your users whatever the cost, why not just find and resize the Firefox window using the normal Windows APIs?
I'm creating an extension where I'd like to be able to figure out whether Chrome (as an application) has the user's focus, i.e. is it not minimized or in the background?
I believe there are javascript functions that check if a tab has focus, would injecting that code into every tab and seeing if any of the tabs return false work? That sounds like terrible peformance though, maybe just inject it into the "active" window using chrome.tabs.onUpdated?
Or would this be do-able relatively easily using NPAPI? Would it require different code for different OSes?
Thanks!
Is there a way I can maximize a currently minimized window from Javascript? Here's my situation:
I have a series of links that all target the same external window (e.g. "MyNewWindow"). When I click a link, a new window pops up. If I click another link, the page pops up in the same window as expected. If I minimize the "MyNewWindow" popup, I'd like to be able to click another link and have that window maximize.
My approach was to put something on the onLoad part of the body so that when the page is refreshed it will automatically "maximize" if it is minimized. Note: Using window.MoveTo() and window.resizeTo() doesnt seem to do the trick (the window stays minimized).
Thanks!
For all of you know-it-alls, there are perfectly good reasons to want to know how to do this. Here's the reason I needed this:
I'm deploying SCORM modules to a variety of Learning Management Systems (LMSs)
One LMS that a client is using launches the module in a small (600x400) window, with the user controls to maximize or resize said window DISABLED
The client doesn't know how to change this launch behavior
My only option is to try to maximize via javascript, because the idiots who made the LMS took away the user's ability to manage their own windows.
window.moveTo(0, 0);
window.resizeTo(screen.availWidth, screen.availHeight);
This may not work in IE depending on the security zone your page is falling under, and it may not work in Chrome at all. But for a corporate environment in an intranet, it has a good chance of working.
Don't do this, you are not allowed to do this by most modern browsers for a reason.
In a tabbed environment you're not messing with only the window you may have created, but all of my tabs, that's unacceptable. It's the user's computer, user's browser, it's the user who chose to go to your site...let them size the window the way they want it, doing anything else breaks their experience...and their trust in your site.
The behavior you're looking to emulate is what your run-of-the-mill malware does...re-think your approach, please. For example focusing that window is appropriate for what you want, let the default behavior of the browser take over from there, like this:
var thatWindow = window.open(url, "linkWindow");
thatWindow.focus();
try to use window.open(url,fullscreen=yes);
if you out fullscreen=yes than while clinking on link automatically