I have an element and a link. I want mouse interaction with the first element to behave exactly like it was the link. This means that
left-clicking should navigate to the href
ctrl+clicking should open in a new foreground tab
middle-clicking should open in a new background tab
shift+clicking should open in a new window.
See this fiddle for an example with a table row.
This works perfectly in Chrome but not in Firefox. This question is similar but doesn't ask about the non-left-click behavior and also doesn't work in Firefox.
Note that the MouseEvent works fine in Firefox for left-clicking (and should be supported since MDN documents it) since you can see the console.log. By the way, you can't even catch middle-click click events, but you can listen for mouseup (or mousedown, but that would be silly).
It's possible to simulate the first two behaviors instead of just dispatching the event to the link and I don't care so much about the shift+click case, but middle-click doesn't work in Firefox.
Related
http://nycweb.io/test.html
Its html is
click
In chrome's console, if you do
document.getElementsByTagName('a')[0].click()
It will open a new page of google.com. Surprisingly, in Safari, this doesn't work. I searched around and found this page saying there is a bug with Mobile Safari which prevents the click event from being triggered. Also it lists some workarounds. I was hoping it would help when I started reading it, but it actually makes me more confused.
First of all, it says the bug only happens with Mobile Safari, but anyone with a Macbook can test from the link above that it doesn't work with Safari either; second of all, it says it only happens with "elements that aren't typically interative", and the workaround includes adding "href" to <a> to make it interative. But my test above shows that it doesn't work with <a> at all, no matter it has href or not.
The actual problem I am trying to solve is this page "http://fbnydob.applinzi.com/test.php", where you can see a warning message pushed by the Hosting company, which can only be prevented by click the little 'x'. I was trying to click it programmatically but it is an <a> even without href, so my program fails to work on Apple devices and my users keep seeing this unpleasant message.
Any workaround for this that actually works?
Could you try firing the click event?
document.getElementsByTagName('a')[0].fire('click')
This will call the click handler and close the popup window.
In my Rails site, I have an element that I want to act as a link when clicked by a mouse (e.g. on a desktop), but not when touched on a touch-screen device (because there is also a hover behavior).
My understanding is that the JQuery .click event should not get triggered on a touch.
My coffeescript for setting the click handler is simply
...
$(this).click ->
location.href = url
...
(where "this" is the element in question)
I know this code works, because the click action works with the mouse. To ensure that it doesn't get triggered on a touch device, I use the device emulation in Chrome's Developer Tools to emulate a touch. However, when I do this, the method still fires and follows the link.
Is this a problem with the Chrome emulation or with my code? I want to know whether it will behave this way on real touch devices.
edit: Same thing happens with Firefox, so I'm thinking it's my code...
I realized that touch events trigger click events as well, later on in the event chain. To get the functionality I wanted, I kept the .click handler, but added a .touchstart handler where I called event.preventDefault() to short-circuit the rest of the event chain. This way, the .click handler fires for mouse clicks, but not for touches.
I have a script that writes an iFrame which loads a page. I created a JSFiddle to make things clear:
link JSFiddle loading CNN in a frame
This loads CNN in a frame. If you scroll down in the frame to the news and click on the new articles and then 'back' there is some strange behavior in both Safari and Google Chrome: clicking 'back' doesn't take the iframe 'back', it takes the entire parent frame 'back'. How can I prevent this from happening?
Also strange is that fact that this doesn't always happen. Try it out for yourself, click at least 5-10 links and you'll see that the fiddle will reset itself every now and then. And that shouldn't happen...
This is behavior that only seems to happen in Safari en Chrome, Opera and IE don't seem to have this problem...
Browser registers history events when you click different URLS, since iframe is part of the page u are on it will register the click inside the iframe as a history event of the parent page. Different browsers may have slightly diferent behavior - I expect FF and Chrome be one way and IE behave slightly different. However testing your example both Chrome and IE worked exactly the same and pretty much as expected.
So to clarify:
Loading JSFiddle is a historical event as far as browser is concerned.
Clicking the button to create and load an Iframe is NOT a historical event.
Clicking a URL link within the Iframe window is a historical event.
At this point u have 2 states that the browser remembers and you can go back and forth in history between them.
When clicking a link in google chrome the focus event fails to fire. All other browsers fire the focus event for links.
Link
I do not want to attach the event onmousedown, but onfocus.
Anyone have an idea for a workaround.
EDIT:
I would definitely consider this a bug because all other focusable elements trigger focus on click.
Even non focusable elements with a tabindex trigger focus on click in google chrome.
<div tabindex="-1" onfocus="console.log('focus')">div</div>
I can't attach to both click and focus because then onclick, other browsers would call the function twice. I can't detect this functionality because it requires user
interaction, and I won't do user agent string detection, because well its wrong.
Using this html:
Link
Is they any way to invalidate the second onmousedown call to prevent the function being called twice in non google browsers.
EDIT 2:
After some further testing <input type=radio> also fails to call focus in google chrome.
Why in the world is google chrome like this, while Opera, IE and firefox are all okay. What is crazy is that the mobile webkit browser even triggers focus on links when I tried it on my Android device.
That actually works just fine, except that the focus event isn't triggered simply by clicking on the link (try tabbing and you'll see the event firing). I don't think it's a bug, why not just safe guard and use both?
One work around you could do to avoid the double focus events from popping on the working browsers while still getting the focus event to pop on Chrome, is to on a click event check whether anything has focus on the page, and if not, then trigger the focus event.
With jQuery it could be done like this:
$('a').click(function(e){
if(!$('*:focus').length) $(this).trigger('focus');
});
example: http://jsfiddle.net/niklasvh/qmcUt/
You can use small hack:
Link
I came across an interesting bug feature tonight when writing a handler for window.onresize in Chrome (the latest version 6.0.472.55). First open two tabs, then in the first tab open this jsFiddle.
Resize the window at will and the dialog box works as expected. Now, try switching to the 2nd tab -_-. Why is resize firing when the tab is changed? Could someone provide insight/more details if I need to file a bug?
The bug has been filed with Google. For the time being, I've just ignored it since my actual onresize handler doesn't display alert boxes.
Well how about that? Sounds like a bug. I would guess that onresize is listened-for by a combination of behaviors, probably new data about the page size that, for whatever reason, is coming in when a tab is focused.
In the version I use on Windows, 5.0.375.127, it doesn't happen, but if I actually resize the window, the resize event fires twice.
Knowing it's there, you can take a step to defeat it (that Google ought to do for you eventually). Wrap an if statement around your handler that checks for an actual change in the clientHeight or clientWidth if you need something to happen only if the event (as we understand it) actually occurs.
From the bug report:
When using Dev Tools in splitview and switching to a Tab without Dev
Tools opened in split, the resize-Event will be fired.
So, if the next Tab doesn't have the same window size, resize() will
be fired.
Without a working knowledge of how Chrome handles tab switching and page rendering, my guess is as good (or bad, depending how you look at it) as the next guy's. I would guess that rerendering the page, or reloading the already rendered page if it caches it, triggers the onresize event. This is what happens when the tab is switched. Following my theory, I would guess that Chrome doesn't trigger the resize event on initial page view because it has been designed not to. But again, as I don't know how Chrome handles tab switching internally, this is just speculation (food for thought).