Allow Firefox AddOn to focus window - javascript

I'm trying to write a Firefox AddOn that allows the user to quickly bring a specific open window to the front. While doing research on how to focus windows, I learned that browsers heavily restrict this to avoid misuse. Which I totally support if it is not intended by the user. In my case the user would install the AddOn to explicitly have this functionality, so focusing windows would be intended by the user.
The classic way to do this is Window.focus() but even the Mozilla docs say, that the success of this operation depends on the configuration of the user's browser.
Makes a request to bring the window to the front. It may fail due to user settings and the window isn't guaranteed to be frontmost before this method returns. - Source
In my browser (Firefox 94 on Ubuntu) it doesn't work.
I also read that setting dom.disable_window_flip to true in about:config will enable Window.focus() but it didn't - and it wouldn't be a feasible approach for an AddOn.
Firefox AddOns use a permission system and my expectation would be that there must be a permission that allows focusing windows for this specific AddOn. Unfortunately the permissions aren't very well documented and I couldn't find the right one via trial and error.
Most of the scarce information on focusing windows through AddOns that I found on the web was posted 5 to 10 years ago and doesn't work anymore.
I tried several approaches like calling browser.windows.update(tabId, { focused: true }) from the popup script (which I have a different issue with). I also tried to inject a content script that calls Window.focus() when asked to by a message from the popup script. None of those worked.
So my first question would be: is there any way today (2021, Firefox 94) to allow AddOns to bring a window to front?
And if so: can anyone please show me how?
Thanks in advance!

I think you need to name your window and then focus it.
const newWindow = window.open('http://....', 'NameOfTheWindow');
newWindow.focus();

Related

Chrome SuppressDifferentOriginSubframeJSDialogs setting override using JS?

The Chrome dev team apparently just rolled out a new "feature" called SuppressDifferentOriginSubframeJSDialogs, which makes it so alert+confirm boxes from an iFrame on a different domain than the parent does not show up, by default: https://www.chromestatus.com/feature/5148698084376576
This means if you have an embedded form, and you relied upon the standard JavaScript alert to inform the user of errors (or a confirm to ensure they want to make a change), it now does nothing, completely destroying the UX.
Obviously we can overwrite the built-in alert and confirms with custom ones, but moving away from what is built into the browser now introduces re-designs for every UI (mobile, tablet, laptop, desktop, etc.) instead of just relying upon proven, built-in technology.
Is there a way to change this cross-domain setting, or to whitelist specific domains to override this feature? We do have access to the parent site with an external JS include file (obviously, otherwise this would be a wide-open back door).
To Disable SuppressDifferentOriginSubframeJSDialogs , which block js Dialog box pop up
If you are single users ( Windows ) :
Right click on desktop and create a shortcut
Windows will pop up a screen and ask you "type the location of the item:"....now paste those value into the textbox
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-features=SuppressDifferentOriginSubframeJSDialogs
Click "next" then "finish" button to create the shortcut
Now you shall see a chrome shortcut created in your desktop .Close all active Chrome instance ( if exists ) then launch the shortcut and you will found Js pop up wont block anymore.
Tips :
If you want push this fix to all your cooperate domain users , you may consider use Domain group policy to update Chrome shortcut value or use custom domain logon script logic to do so
I found a setting in the latest Chrome GPO template that creates a reg entry that will deal with this and the same reg entry placed in the Edge location also resolves the error there. (at least it worked for the problem that came up for us yesterday FWIW)
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"SuppressDifferentOriginSubframeDialogs"=dword:00000000
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome]
"SuppressDifferentOriginSubframeDialogs"=dword:00000000
The latest Edge GPO templates do not have the setting yet, but I imagine it's only a matter of time.
Today I tried it again with Google Chrome Version 92.0.4515.131 and it suddenly worked again. Can anyone confirm this?
Add for Mac users.
If you use mac OS:
Quit all running instances of Chrome.
Run the terminal application.
In the terminal, run the command:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-features="SuppressDifferentOriginSubframeJSDialogs"
You can see more details here :
https://trailblazer.salesforce.com/issues_view?title=salesforce-functionality-impacted-in-[%E2%80%A6]oss-origin-iframe-javascript-dialogs&Id=a1p4V000002BRMX

Is Chrome extension Content Script scope shared when opening a new tab with window.open (since Chrome 45)?

I have an extension which used to work fine until the latest update to Chrome (45).
The problem is that the content scripts that used to load separately for each tab, now seem to share scope between an opened tab and its opener tab (when using window.open), as long as the new tab is on the same domain as the opener.
The interesting thing is that this wasn't the case until today, when my Chrome was updated to the latest stable version (45), yet I wasn't able to find anything in the release notes about this (could very well be I missed it).
My question is whether this is indeed a change with the new Chrome? And if it is, how can I prevent this from happening or work around it?
Depending on what your content scripts do there could be different ways to tackle the problem.
So far I've noticed that in Chrome 45 chrome.tabs.sendMessage(tabId, {message:"text"}) sent to tabId is received also by this tab's opener tab's content script and the workaround is (implying you want to send the message to the main frame's content script):
try {chrome.tabs.sendMessage(tabId, message, {frameId: 0})} // throws on Chrome prior to 41
catch(e) {chrome.tabs.sendMessage(tabId, message)}
I think this is a bug and evidently it was introduced in this fix of this bug.
You have not stated any information regarding the extensions other than a few of its functionalities. However, if you simply need the extension to work and require and looking for a stable environment, I suggest you stick to the version of the web browser you know best, and you are experienced with. No need to keep following the updates all the time. The change you are experiencing may be just a deprecated code that needs a patch.
Also, I have not had the time to inspect all changes in chrome 45, however,the major change I witnessed, is the tab loader standby(nothing new to firefox).

Unable to allow IE10 to run scripts

My IE10 has stopped execution of JavaScript for pages stored locally, infact it does not asks for permission to allow their execution.
I have Windows 8 x64 with IE 10 installed. A few days back whenever I used to open a file which used JavaScript IE10 used to display a message "IE restricted this webpage from running scripts or activex controls" with a button to allow blocked content.
Now, this dialog doesn't appear at all and I'm unable to test JavaScript programs in my local machine using IE. (On websites like gmail etc JS simply works).
I have tried changing security setting inside internet options to lowest but no use.
P.S.: On repeatedly clicking reload on realized that permission to allow blocked context dialog appears for fraction of a second and disappears.
I solved the issue by installing a cumulative security update for IE10 Windows 8 x64 from
this link
Don't know why this is related with the issue, but my friend suggested me try to update IE, and on googling I found this update.
I posted it here because when I searched internet for the solution, I was not able to find any case of this type.

Why IE8 blocking a pop-up window which appears in IE7?

I am working on a client server application,in which we open client on our pc by URL:http:\[ip of server]:[port no].
My application start by using the URL mentioned in IE, and one pop-up comes in which we perform every action of the apllication and original window we can close as they are only for starting. One of my customer is using IE8 and he is facing a problem in which after clicking on save to bookmark the pop-up is not coming and hence not able to save. In IE7 pop-up as an another window is coming and giving the option to save.
What is blocking the pop-up? Thanks in Advance...
For popups the same goes as for spam email - as the popup developers get smarter, so do the popup blocker developers. As such it makes sense that newer browser versions are stricter in the rules they evaluate to determine when a popup needs to be blocked.
All modern browsers follow the same rules, that all boil down to "popups are only allowed if the user directly initiated them". This means that they guard execution paths, and every call to window.open is caught by the popup blocker unless it can be directly traced to a user action. And as popup developers invented more inventive ways to make a browser think the user initiated it, popup blockers got more inventive in detecting them.
A quite plausible explanation is also that you are developing on a LAN, where IE applies lower security settings by default, allowing more user popups automatically. We cannot see that from your post though.

Is it possible to open Internet Explorer window from Firefox? [duplicate]

Our Web application is based on IE9, which means only IE9 can open the pages in our site. We'll prevent user to browse our site when their browser is not IE9.
But sometimes we had to send a link to user's email box to complete some actions and they will open the link directly with their default browser, the problem is here, if the default browser is not IE9 then they can't open the link, they have to copy the link to IE9. Our user don't want do this manually, they want open the link in IE9 directly no matter what the default browser is.
I have tried using ActiveXObject, but it only works in IE. I want have a script which can open IE browser in Firefox/Chrome page.
It sounds like you want to have a link in an email that activates a specific program on the user's computer rather than the program that they've identified should be used (e.g., their default browser). I don't believe you can do that.
You can install "protocol handlers" in both Chrome and Safari (I suspect Firefox as well), which would let you send a link like ie://example.com/path/to/app. Your protocol handler would launch IE and take you to the relevant site. (Apple does this with iTunes.) But your users would have to install the handler (and, of course, you'd have to write it).
An easier answer might be to have the users install any of the ubiquitous "open in IE" add-ons/extensions that exist for Chrome, Firefox, etc. They follow the link, then choose "open in IE" from some kind of menu. (If they're using webmail, they may even be able to right-click the link and choose that line item, depending on the extension.)
Side note: Obviously, though, barring it being impossible I'd recommend making your application compatible with Chrome and Firefox.
No you can't do it..
but there is some alternatives:
Install your users IE tab:
FireFox - http://lifehacker.com/135297/internet-explorer-in-a-firefox-tab?tag=softwarewebpublishing,
Chrome - https://chrome.google.com/webstore/detail/hehijbfgiekmjfkfjpbkbammjbdenadd
Use a batch file that will launch your link in explorer.
use this Firefox plugin makes it possible to use (host) ActiveX controls in Firefox - http://code.google.com/p/ff-activex-host/
instead of ActiveX try using Netscape Plugin Application Programming Interface (NPAPI) - a cross-platform plugin architecture used by many web browsers.
Similar as with a batch file, you may create a link file to the page you need using the ".website" file extension with IE, which is configured in windows by default to open with ie. Put it in your webserver public folder and then add a link to that file in your website
You don't have to write code to create a custom protocol handler in Windows. See this page for how to define one in the registry.
You can use User agent switcher for chrome or firefox
For Chrome :
https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg
For Firefox :
https://addons.mozilla.org/en-US/firefox/addon/uaswitcher/

Categories