In Opera, on some sites, pressing both mouse buttons simultaneously leads you to some other page,
for example, to the separate comments page, when watching a Youtube video.
Or to the sitemap on some other websites.
May be it is related to Mouse chording ? or is it something different ?
How to control this event (disable it or change the destination page) ?
This is one of Opera's shortcuts for quick back/forward navigation. Holding left button and clicking right takes you forward, holding right and clicking left takes you back.
Opera also uses some heuristics to try to guess what the best 'next' link is if a user tries to go 'forward' but there is no page in the navigation history to go forward to. To control this, you can for example use a rel=next LINK tag to point to the next page. This is most convenient if you have, say, an article split across several pages. On the first page you could put
<link rel="next" href="secondPageOfArticle.htm">
To indicate to the browsers (and search engines) what the next part of the article is.
Related
I'm having a bit of a problem with mobile safari's swipe animation:
I've created a popup window of sorts, for the search functionality (with a similar purpose and look to ebay's mobile site. Go to ebay on mobile, and focus on the search field and it will overlay a sort of popup over the entire site)
The difference, however, is that I've added a pushstate command so that when you open the search popup, it advances the browser history. That way, if a user wants hits "back" on the browser, it'll just close the popup instead of going to whatever previous page the user came from.
Another thing is that I've created an animation for the window's appearance and disappearance. So when you focus on the search field, the popup appears by sliding from right to left, and also goes away in a similar fashion.
Here's the problem, though: iPhone's swiping navigation functionality destroys the sliding effect -
when you open the popup, it advances you forward in the browser's history. Now, if you try to go back by using the swiping functionality, it shows the sliding animation of the previous page into view (iPhone's default), but then, as it's done, my code kicks in (because ultimately, it triggers the popstate event) and also does the sliding animation, so it looks broken. So, as a result, the way it looks is: you swipe to go back to the previous page which shows the search popup being pushed out of the view (just like my animation), and then when you're done, boom, the animation reappears, and plays again.
Ideally, I'd like to be able to detect the swipe functionality somehow. That is, some event, or something in the popstate event to indicate that a swipe navigation is, or has just occurred?
Or perhaps, being able to disable safari's default effect? (to which the answer, I suspect, is a big fat NO)
Is there anything I could do about any of that stuff short of disabling my custom animation when I detect safari, or doing away with the pushstate functionality?
Any advice towards a solution would be highly appreciated.
Right now Tab is disabled in Impress.js and just moves to the next slide.
Even if I delete that code and let it behave normally and focus on links it kinda crashes impress.js
Has anyone found a solution to this?
Thank you!
(I maintain a current fork of impress.js, as bartaz has not worked on it for years now, so I'm familiar with the keybindings code as well.)
The answer is that making Tab move to the next slide is the solution, not the problem :-)
More specifically, the problem is that in a browser, the tab key will jump to the "next" link or form field. If the link is outside the current slide, the browser will scroll to wherever the link is, completely breaking the presentation flow. So impress.js needs to disable the tab key.
Instead of disabling it, bartaz then just tied it to the next() function. If you don't want the Tab key to move to the next slide, you can of course remove that code, but you would still have to call event.preventDefault() to avoid the browser from receiving the Tab key.
In my fork of impress.js, I improved the support for using form fields, so that for example if the cursor is in a text input field, and you press left arrow, the presentation will not move to the next slide, rather it will move the cursor in your text field, as normal. But even in this case I've preserved the functionality of the Tab field: it will move to the next slide rather than next form field (or link).
It would be possible, but hard to try to figure out whether the next form field is still on the same slide or not, and then try to decide whether moving to that form field is the right thing to do.
UPDATE: This is the impress.js issue where Tab key is discussed.
I have the following scenario, a user is scrolled some wheres down a search page. They click on an item and after they are done viewing the item they hit the back button. The back button brings the user back to their exact location within the search page as it's suppose to. After a second, the page auto scrolls to the top of the search results. You can see this behavior in action cardaddy.com/forsale
I've spent a couple hours trying to figure this out with no success. I'm not aware of any js causing this issue either. Please feel free to take a look. Any suggestions would be great since this is destroying my ux
I though maybe the forward from my root domain to www.domain.com with godaddy.com may of been the cause, so i changed that behavior around to use amazons name server eliminating the forwarding. I thought I repaired the issue as it seem repaired on the desktop, but it still seems to happen on mobile.
As far as I know, this behaviour depends on your browser.
The back button brings you to the last site you visited and loads this site new. So the effect to stay at the possition is caused by the browser engine.
1 way of doing it would be to save the location of the page and restore to that location when back button is clicked
on click : var position = $(window).scrollTop();
On back button : $(window).scrollTop(position);
Suppose I have a link, which would fade out the entire page when link is clicked. The reason I fade out the page is because a next page is about to load, but it is not loaded yet. I can use pointer-events: none which will disable any mouse events until the next page is loaded.
Suppose it was done with the keyboard, I could use the following to prevent double-enter, or to cleanly disable all elements within, for example tab-enter would be disabled this way as well.
parent.onkeydown = fals
parent.onkeyup = fals
parent.onkeypress = fals
function fals() {return false}
This works well for short loads, but if it takes a long time to load, the user may notice the following difficulties.
Cannot tab away from the a tag.
Cannot use several of the keyboard shortcuts which would control the browser.
Able to tab into the disabled area from the address bar.
Is there a modern and slick way to prevent these 3 problems, other than setting an onfocus=blur for all of the child elements? I do not care about IE today.
I think the commonly accepted way of dealing with things like what you're talking about is to use Modal's, which is to say when they click that link, you pop up a box that says 'Processing' or something like that, and you create a fullscreen div with a z-index above everything else so the user can't click / interact with anything else on the screen until you're done doing whatever it is you are doing.
See http://twitter.github.com/bootstrap/javascript.html#modals for an example of what i'm talking about.
I've been dealing with a bane-of-my-existence Javascript problem involving tracking when a user clicks on a link (in case you're curious, here it is: Why does using target="_blank" cause Javascript to fail?).
I've figured out that I can solve the problem by tracking an onMousedown event rather than an onClick event.
I'm curious about the downsides of this approach. The ones I can think of:
If a user clicked down on a link and then moved the mouse off the link before releasing it, then the event would be recorded even though the user hadn't visited the link
If a user used the tab key to move the browser focus to the link and then hit enter, the click would not be recorded
Neither of these are common, so I'm not terribly worried about them.
Are there any other downsides I'm missing?
One more: mousedown captures right / middle clicks too.
But for your two reasons, I would stick to onclick. I know quite a few people who use keyboard nav. Especially search-and-gotolink in FF.(/ to search followed by enter to go to the link).
But if these two are not a problem for you, I think right / middle clicks wouldn't be too.
I think the way to track all the users who follow the link is quite tricky -- the user could right click and click on new tab / new window...