I'm producing a page which will most often be opened via an anchor with target="_blank".
Progressive enhancement AJAXes in the page and places it within a modal, in which case the close button removes the modal node from the tree — in these situations a 'pop out' link will feature, allowing the user to open the page in a separate window (as above). It's easy enough to figure out whether this should be displayed or not based on the tree structure:
.modal a.pop-out {
display: none;
}
In both these situations, a close link is also appropriate in the same context: because the user journey has taken a momentary detour, it's expected that the user will sooner or later want to close the window and return to the opening window. However, I can't work out what feature detection to use to determine whether or not the link should be displayed. Obviously javascript support is necessary, but if the link was opened independently and javascript is supported, the close button is not appropriate (window.close() will have no effect).
My question the, is how I can work out, without executing it, whether window.close is possible in the current context.
Check if the window has an opener. The modal won't; the new window will.
https://developer.mozilla.org/en-US/docs/Web/API/window.opener
Related
I want to make a left-click menu. How can I make it on my Chrome extension?
This is my right-click menu:
chrome.runtime.onInstalled.addListener(function() {
chrome.contextMenus.create({
title: 'Dolar',
id: 'dolar',
contexts: ['all'],
});
});
chrome.contextMenus.onClicked.addListener(function(info, tab) {
if (info.menuItemId === "dolar") {
alert("Hello");
}
});
For making it left-click, how do I change it?
There is no special Chrome extension API to create a menu that opens on left-click. To make a menu that opens on left-click, you will need to inject a content script in any page in which you desire to have it used. In that content script you will need to listen for the click event with the left button. You will then need to insert into the DOM the elements that make up your menu. You will need to do all of this manually, or find a library which will abstract the problem.
In general, this will be inconsistent with the user interface which is used on most machines. This will be counter to most user's expectations and may cause user confusion. In addition, web pages will expect to be able to use left-click for whatever purpose they desire, if any, beyond the normal clicks on links (e.g. activating drop-down/pop-out menus, etc.). Your use of it will conflict with using left-click for any interaction within the page. Unless you have a specific use case, having a left-click menu that is generally available is probably a bad idea.
Having a UI element which opens a menu when the user left-clicks on it is a different situation. In such case, the user is clicking on a UI element which is expected to do something. However, you should consider carefully if loading a UI into every page is appropriate. Sometimes it is. Doing so can place a heavy burden on pages where your add-on is completely unused. You can minimize this impact by loading just the minimal amount into the page to show the beginning of the UI. Then, loading the rest of your code/libraries/UI only when the user begins interacting with your extension's UI. Needing a UI in the page is much more likely to be the case when your extension is for a limited set of pages (i.e. modifying the UI on a particular domain/page). However, for most extensions, general interaction with your add-on will begin with a browser/page action button click, a hotkey, a context menu entry, or your add-on detecting something and opening a UI for the user (i.e. not through adding a full UI to every page).
I am trying to detect whether the current page is already opened in a different tab or not.
I tried using window.open(), but I get as return the current window itself, not the supposedly other window of same address. It will always return true.
So say, if 'mysite.com' is already opened, when the user opens a new window with 'mysite.com', I shall detect that, focus the other window and close the current one.
Would love to hear any ideas, or whether this is possible. I'm trying to capture all links into a single tab.
You can use localStorage events to communicate between different tabs and therefore detect if a page is already opened. Check this answer: https://stackoverflow.com/a/14792159/60745
Even when you're only concerned with a tab in the same browser on the same machine, the problem with trying to accomplish this through pure javascript is that although you could set a cookie on each of your sites pages (window.onload) to record the user has initially visited your site, there's no safe way to ensure you remove this cookie when they leave.
Although you have the onunload & onbeforeunload events, these are not fired when you leave a site over a link, uses a browsers back button or closes the browser.
I'm having an issue with a our main application's window activating itself when the mouse is hovered over it.
I'm opening the new window in a javascript function using the line below:
window.open(URL, 'Requests', 'location=no,toolbar=no,status=yes,scrollbars=yes,resizable=yes');
I have noticed that if I open a new IE window through Explorer, hovering over our main application's window does not reactivate itself. Even in this case though, the main window does make itself be "on top" of the pop-up window created by the window.open command above.
The question is this: Is there any way, when opening a "child" window in javascript, to detach the child window from the parent?
Further info: I am using an Infragistics WebDataMenu with ActivateOnHover set to true so users don't need to click on main menu items to see sub-menu choices. Unfortunately, that setting sensitizes the whole menu bar so that sliding the mouse through it activates the menu (and sadly the window when a popup is active). This is the root behavior I'm trying to fix.
The window.open(); method will create a popup window that really only shares a relationship through JavaScript via the return value of the call, and the window.opener property on the popup window.
What you want is the behavior of a modal window that locks out interaction from the 'parent' page while you work on the 'child' popup.
You can try to fight with JavaScript (and your users) by forcing a focus on the popup and blocking any blurring but this will drive users nuts when they want to go read their email etc. (eg not recommended)
You can also use the not so standard showModalDialog(); method but support is far from fully cross browser and there are a whole bunch of new problems if you try to use this (no right click in IE, zoom issues in IE, and no grandchildren popups to name a few) (again not recommended)
What you can do is make an "overlay" popup similar to many online photo viewers where you first overlay a mask (typically semi transparent) that blocks mouse/focus on the entire page content below and then overlay that with your "popup content". Just be sure that you provide a close option that removes the mask when the overlay is closed/done.
Note if you need to support IE6 you'll also need an iframe shim (Google if needed)
Many UI frameworks will provide a "dialog" just like this for you. (Eg jQueryUI)
Ultimately, I gave up on making this work. I found that what I had to do was turn off ActivateOnHover from the WebDataMenu, which didn't answer this question and requires users to click on the menu to make it drop down, but it became a work-around.
I have a document that can not be quit without saving changes. I use onbeforeunload to ask user if he really wants to quit. It works fine if the "quitting" scenario is clicking on a link and reloading page. but i have also JS menu that moves user from document editor to settings and it's done without website redirect but is handled wholly by JS by replacing "document view" and showing "edit settings view". But moving to edit settings view makes the changes in document unsaved like a normal reload does. So how to invoke browser to ask if user really wants to move to edit settings view like it does when page reload occurs in this scenario?
You can't, without navigating away from the page. But you can ask them with a much nicer, more friendly modal dialog of your own (an absolutely positioned div with a zIndex greater than any other, possibly with an iframe shim under it to eat all clicks, etc.). You can roll your own, but there are lots of modal dialog libraries out there which would save you time.
Or if you like, you can use confirm, which doesn't have a very good user experience (but then, neither does onbeforeunload) but is dead easy to code and entirely cross-browser compatible (despite the link being to a Mozilla page).
I have this link in my left navigation:
dashboard
That javascript opens a link based on the passed parameters.
All works fine, but I would like to be able to use the browser capabilities of opening the links in a tab (when user is using middle click or selects 'Open link in new tag' from right click menu). Though, this is not working for links handled with javascript code.
There are many reasons why this is not the default behaviour of the browser (e.g. javascript function might only do some validation and stay in the page ... browser can't know what the js might do or if a new window/dialog will result from that action so would make no sense to open new tag as a result of a middle click ...). But hopefully there is a workaround for the default behaviour.
Any idea how this could be done?
Cheers,
Stef.
Javascript links execute in context of the page where they are called. If you "open" the link in a new tab/window, the javascript code will be executed in the new window, i.e., empty, and will most probably fail.
A browser could try to add the feature you are asking for by cloning the page which contains the link, and executing the javascript code in the context of the cloned page. But this would most likely break some critical sites (imagine for example that your online banking site works with javascript, so when you open a link in a new tab/window, cloning the original window might lead to a duplicate transaction).