This issue drove me nuts for 2 days. I made a simple chrome extension which calls a server-side program that returns HTML that I then stuff into a div in the popup. It was all fine, except for the simple anchor link containing a "mailto:xxx#yyy.com" href. An email message composition window would not pop up.
Workaround: Add target="_blank" attribute
I would like to know why this is necessary.
It might have something to do with extensions running in separate processors from the browser, and therefore a target attribute is needed so that a new tab/window can be opened... there are some websites that don't work when displayed inside extension popups for this reason, because the extension frame won't navigate to certain pages...
I know this is an old question, but I ran into a similar situation. I had to send an email, but I had to do it with a button instead of a link and had to finagle this:
function sendEmail(){
var mail = 'mailto:xxx#yyy.com?subject=Subject&body=Body';
var newWin = window.open(mail);
setTimeout(function(){newWin.close()}, 100);
}
It's not ideal, because it opens a new window that's visible to the user instead of doing it instantly. In fact, my first attempt was this (which works in an HTML file, but doesn't work in my extension):
function sendEmail(){
var mail = 'mailto:xxx#yyy.com?subject=Subject&body=Body';
window.open(mail).close();
}
Not sure why adding a timer makes it work in this instance as opposed to just doing it like in a regular HTML file, but that worked for me so I thought I'd share.
Related
I have just read some concept about window.location property and method.
And I know that
1. window.location.href = "http://google.com"
2. window.location.assign("http://google.com")
3. window.location.replace("http://google.com")
are all can redirect our page to the target url, the only difference is that window.location.replace doesn't record the history, so we cannot get back to the previous page directly.
Now I just wondering, what's is the difference between window.location.href and Google, the <a> tag also records the history.
And for what situation do we use them respectively?
I think the main difference is what's happening behind the scene but on the surface they are pretty much giving the same effect.
window.location.href is only triggerable by JavaScript, or in JS context. Whereas a <a> tag defines hyperlink in HTML. It really depends on how you want to trigger this new page. You can either have a hyperlink a user can click/tap on, or you can trigger the page load by some JS functions that are triggered by certain actions.
To be more specific, a tag is common in webpages because browsers understand it and can apply CSS style to it to look nicer. As for window.location.href, there's no UI aspect for it, it simply is a line of JS code that you can trigger to either (1) get the current webpage URL or (2) set a value to it to redirect the user to some other URLs.
The difference is in how they are likely to be used (duh, bear with me.)
Setting window.location.href is a way to programmatically set the URL. For instance, window.location.href = 'https://www.google.com' will navigate the user to Google's search page. There is no way for your user to make use of this knowledge, unless they open the developer console.
Using an anchor tag of Google will show a hyperlink that the user can click, navigating them to Google's search page. This tag is also more likely to be interpreted by a screen reader more appropriately than a button with an onclick that navigates them to Google by setting window.location.href manually in Javascript.
I have a weird situation. One of my users is using functionality of Chrome (current version, 49, 50), that he drags and drops a file from his folder on local computer to normal input type=file button in a form on the webpage. Once again, let me stress it even more, its normal html input, no fancy javascript, no drag&drop events and handlers, nothing like this. It just takes the name of the dragged file and puts it into the input field, as like he selected it via "normal" way, opening the file select window, locating file on harddrive, selecting the file and confirming.
In some specific situation, this stops working (while doing some edits in the page via javascript / ajax), and I need to "reenable" it.
But, and that is my question, I haven't found any documentation of this "feature" in Google Chrome (or maybe some other browsers as well, I don't know). Why it works, how it works, how it should work and what to do if it stops working :) Does anyone has any experience with this ? The only way how to "fix" it now is to reload the page. I'd love to solve it ... :)
EDIT 1 : I just did a quick test, it works and bugs the same way in Firefox on Win. It doesn't show any error in dev console or any message, it just doesn't add the file as expected.
I've found it. The previous discussion with deceze pointed me to test the javascripts I have on the page, that do not "interfere" with the input type=file ... they weren't any such scripts, but I've found that after doubleclick on the table (that I'm using for editing) this script is being called
$(document).bind('drop dragover', function (e) {
e.preventDefault();
});
and there wasn't any unbind action when table is saved ... this caused the drag and drop everywhere on the page to stop working after the edit.
I am developing a web site where users can change settings which they have to confirm before taking effect.
The confirmation is done by a link I send them via E-Mail. In the HTML of the website I use this little snippet:
<script type="text/javascript">window.name="mysite";</script>
And in the HTML emails I use
Click me
But Chrome is always opening new tabs instead of opening them all in one.
Is this even possible or is it forbidden for some reasons?
Webmail platforms such as Gmail tend to modify some of the HTML code of an email due to security reasons.
They obviously remove any javascript code the email could have. But they also change (or add if none) the target property of every anchor element and set them to target="_blank" in order to avoid the user to be taken out of Gmail (in this case).
Unfortunately every webmail platform has their own behavior, therefore, what you want to do is not gonna work on every webmail platform.
If what you want to do is prevent the user from having multiple tabs of the same page opened, (*please refer to Update 1) it comes to mind you could use web sockets to close the previous tab once the user enters in the URL sent by email. Have a look at socket.io for example.
Update 1
There's no way to do this using WebSockets. There's no possible way to close a window that wasn't opened using javascript, and it can only be closed by it's parents.
That is a very interesting idea. I like it. Alas, it appears that, in modern browsers, you can no longer close a window you didn't open through javascript. So if you aren't allowed to run javascript in the email, the best you can do is to redirect the original page to a "thank you" page and leave it hanging around in the browser's tab (but no longer waiting on conformation). Like this:
PleaseConfirm.html:
window.name="need_redirected";
Confirm.html:
var w = window.open("", "need_redirected");
if (w)
w.location="ThankYou.html";
Of course, for old IE, I'd still try to close the old window in ThankYou.html:
window.top.close();
You can still try to set the target, of course, just in case it works, and you can always try putting an onclick attribute on your tag for the same reason:
click here
But that seems to be the best you can do. Bummer.
Neither of the other two answers work, but this one probably will:
In the initial tab, listen for an onstorage event, with a certain key being created, e.g. "userHasConfirmedEmail". When the event occurs, window.top.close().
In the new tab, create that key.
Credit goes to Tomas and his answer.
I wrote a user script for the latest Chrome browser. It seems the script can't get the changed content of the page after loaded (for example, after the page loaded, I clicked ¿sth? and an embedded window popped up).
Even if I used window.setTimeout(), I still can't the get updated content in the timer callback through document.getElementById(). I inspected the page and found that the popup element existed in the DOM.
Is this a limitation of user script? Or some other methods could be used to get the update in user script?
Update:
I tried DOMSubtreemodified event as suggested. But the behavior is still strange.
I added only one one line of JavaScript to the userscript for my.safaribooksonline.com,
document.addEventListener("DOMSubtreeModified", function () {
alert(eval('typeof OpenSignInPopup')); });
But the alert box shows "undefined" as the evaluate result of OpenSignInPopup. But I can run the alert statement in the script console in the same page at the same time, and shows the result as "function".
This function was not loaded when the user script is running at first. So how can I use it in the user script?
You need to provide details, like the relevant code snippet(s) and the pages targeted.
In general, you can fire off the DOMSubtreeModified event in chrome. That should get you access to the changed DOM.
Also, are you sure the new content is not in an iframe?
Update for new OP info:
But the alert box shows "undefined" as the evaluate result of OpenSignInPopup.
In Chrome, Greasemonkey code cannot interact with the page's JS functions like that. You'll need to inject your code into the page. See this SO answer for more information.
We have some code where the user clicks a link which launches a pop up window. The code that creates the window then does an HTTP post to the window. Once the post has succeeded, the page is redirected (as a javascript location) to a PDF that was created during the post.
One person is getting an error where the posted data is not getting posted. In fact, the request is coming across as a GET.
Originally I thought this may be some kind of bookmark to the original page issue. But it happens in two different places that use the same concept in a different manner. And, since the post is triggered through JavaScript and the result is immediately relocated it would be no trivial matter to actually get a link to the original page.
So, the question is, are there any "pop-up" blocker like security tools that would allow pop-up's but convert all POSTS on them to GETS?
Example Call:
function LoadPDF(File){
document.forms[0].PDF.value = File;
win = "Window" + Math.round(Math.random()*100000);
open("",win,'toolbar=no');
function SubmitForm(){
document.forms[0].action = 'CreatePDF.cfm';
document.forms[0].target = win;
document.forms[0].submit();
}
//Give window time to open.
setTimeout(SubmitForm,550);
}
The code that creates the window then does an HTTP post to the window.
Popup blockers block popups as they are opening, which is pretty much the point of their existence. It would have to be a pretty lame popup blocker that allowed the popup to open and then translated the POST to a GET. It's possible a GreaseMonkey script or extension could translate it maybe.
Tell the user to disable any plugins/extensions and try again.