I have iframe on my page. In firefox, when I tab into the iframe the control goes to html tag in the iframe. (I could see this with document.activeElement.contentWindow.document.activeElement on console.) The next tab gets me to the first control in the iframe.
In IE and chrome it works fine.
Can you please help me, what I am doing wrong?
Thanks
You're doing nothing wrong. Firefox is focusing the root element so that a user who's just using the keyboard can scroll the iframe if he wants to. If the focus went directly to the first text input, for example, the user wouldn't be able to scroll the frame.
And indeed, that's what happens in Chrome. If the subframe happens to not have any text controls in it, the user can scroll it fine after tabbing to it. If it has text controls, the user is screwed if he wants to scroll.
For what it's worth, I just reported this as https://bugs.webkit.org/show_bug.cgi?id=79558 because it seems like a clear accessibility bug...
Related
While trying to tweak some scrolling script to perform "jump to" links on some pages, I noticed that if you have a page with contains a hash tag in the URL, the behavior is different depending on the browsers when you press enter on the address bar, after the page is loaded.
For example, if you load a page with an has in the URL and then scroll away from the target element, I noticed that on Firefox and IE, if you put your cursor on the address bar and press enter, the page will move back to the HTML element having the same id attribute as the hashtag but the page will not be reloaded.
I also noticed that neither popstate nor hashchange events are triggered in such scenario. The scroll event will most likely be triggered but how can we know this is not the user scrolling but the browser reseting back its position?
Is there any was to detect this type of event in the browsers? Given this is outside the viewport I'm a bit curious. But I have a scenario where I would like to reposition the menu depending is the page is scrolling up or down.
To try to explain what I'm looking for:
Page with hashtag #test and element <div id="test">
Press F5, the page posisition itself right where the <div> is
Scroll up or down
Go on the address bar and press enter
---- Looking for an event to detect the previous action ---
the page posisition itself
right where the <div> is
Example in JSBin (open in Firefox):
http://jsbin.com/rifikereze/1/edit?html,js,output
Output:
http://output.jsbin.com/rifikereze/1#test2
Open your console in Firefox
Make sure in the Firefox setting you enable "persistent logs" to keep logs after page reloads
Press F5 (you should see a console message "reloaded")
Now try to move the page, put your cursor in the address bar and press enter
You will see the page does not reload
How can we detect these events (other than scroll events)?
Make sure to use Firefox on Windows if trying to reproduce. It looks like other OSes have other behaviors.
Given the lack of answer, my presumed answer is No.
There is no way to detect re-positioning of browsers using fragment identifiers (aka hash) in URLs and the address bar.
On top of this, browsers seems to have inconsistent behaviors:
Firefox on Linux behave differently than on Windows (it reloads the page).
Chrome seems to be ignoring re-positioning unless the page's position is set back to the top position before unloading.
There seems to be no standard across browsers on whether the normal behavior is to reload or re-position.
The only safe way to detect fragment identifiers repositioning is when loading the page.
When an <a> element is clicked on, normally it changes it's color or something to indicate it has been clicked. I just noticed that in iPhone's Safari, the CSS attribute change of a link upon click doesn't take place and the page just seems to not be responding, then it redirects to the link's URL properly, but the user will think that the link is broken because of this. Has anyone seen this problem? Have you been able to workaround it?
I have compared my website to others and it's kind of common. I have also tried a couple of things with javascript, but seems that the CSS changes are ignored and the link redirects before changing the CSS in the link. This doesn't happen on other browsers like Chrome in Android. Any help will be appreciated.
I am facing issue with the way back button works in Chrome.
I have a application where I am displaying a form in iframe inside the parents window.
So when the user clicks on back button the behavior on IE and Mozilla is that page in iFrame loads up again.
This iFrame page refresh when the user clicks browser back button is important in my case is because we need to keep a track of users who have logged in the application and accessed that iFrame content.
Now in Chrome the behavior of back button is different. When the user clicks on browser back button the user is taken back to previous page.
I need to alter this behavior for chrome and need to refresh the content in iFrame instead of moving back to previous page.
Anyone kindly who have idea on this help me out.
PS: I cant use jQuery in application.
Regards,
Well the short answer is you can't and you shouldn't. becoz this behavior is inconsistent across different browsers and even future versions of mozilla and ie may also change it's behavior.
Still you have some alternatives to achieve this kind of behavior.
You can use HTML5's history.pushState where on hashchange event you can refresh you frame whenever you want.
I have trouble with this page for example: http://www.last.cz/exotika.html. If you open it in FF or chrome, you start at the top of page. But when you try in IE8, it loads scrolled past the header. Compatibility mode does not help. I think the filter details that get filled by onload function cause it. Does anyone who ran into the same problem know how to fix it? A css hack would work I guess.
Thanks for suggestions. Mike
This will be executed onload(placed in core.js):
$('#item0').focus()
That's what happens, the element #item0 gets the focus and the page scrolls down to fully show the element(it will scroll until the bottom-border of the first "hotel-box"--thats what #item0 actually is-- occurs inside the viewport).
Other browsers may ignore the instruction because the element is a <div/> and can not be focused.
I'm working on a project at the moment where I've come up against a rather frustrating problem in Internet Explorer. I have a series of pop ups on a particular page that are opened with JavaScript when help links are clicked. The JavaScript for them is:
function openHelpPopUp(url) {
newwindow=window.open(url,'name','width=620,height=440');
if (window.focus) {newwindow.focus()}
return false;
}
The HTML used is:
Help
Now, the pop up works perfectly in every browser except Internet Explorer. The main priority at the moment is making it work in IE7.
What happens is that, it pops up fine, but the text is not visible. If you click and drag the cursor over it and highlight it though, it becomes visible. Once you click away from the highlighted area to deselect it, it stays visible. Any area that wasn't highlighted stays invisible. When you refresh the pop up though, it sometimes becomes visible without any highlighting, it sometimes doesn't.
Also peculiar is that some text within an unordered list is visible, but when I use the same list encompass the rest of the text, it stays invisible bar the bit that was already visible.
Have you come across this or anything like it before? Have you got any tips or suggestions? I'm running out of things to try so any feedback or help on this is greatly appreciated!
By adding a z-index of 100 to every P tag for IE, I seem to have gotten it visible now. Weird. I haven't used any z-index's elsewhere and the structure of the HTML should put the P's on the top anyway.
Sounds like a browser bug.
What happens if you open the URL directly? Perhaps it's not popup related?
it pops up fine, but the text is not visible. If you click and drag the cursor over it and highlight it though, it becomes visible
Sounds like it might be an IE7 variant Peekaboo bug, an IE rendering problem which is nothing to do with being opened in a pop-up. You'd have to show us the page that's being popped up to be sure though.
Whilst we're here:
if (window.focus) {newwindow.focus()}
Probably should be ‘if (newwindow.focus)’ assuming the aim is to avoid focusing a blocked ‘window.open()=null’.