So there are 3 of us. We all have JAWS 2018
I have IE 11 11.557.17763.0 and my two coworkers have IE 11.885.17134.0
So I on the web page in question, there is a drop down menu with a checkbox immediately in the tab order after that. I can drop down that menu, make a choice, the page will load and my focus will move to that checkbox
But my two coworkers, when the page loads for them, focus moved to the URL bar of the IE 11 web browser.
We think that because I am still using an older version of IE, there must have been some kind of IE update that is causing their browsers to perform that action, but I cannot duplicate it on my computer.
Related
I have a Kendo UI panelbar on a website I'm developing, with a large number of panels (dynamic, but it can be up to 12). On mobile devices, I've found that clicking a panel bar to expand or collapse it will also cause the page to jump to the top. Since the panels are a bit further down the page, we're finding this to be really annoying. It does not happen on a desktop screen though, even if I shrink the window down to about a mobile size (it does happen when I use Chrome's mobile emulation setting, however). Is there a way that I can prevent this from happening?
EDIT: This behavior only occurs with panels that have a Kendo Grid within them, which is most of them; it does NOT occur with panels that just have text.
I have manually implemented the Flattr button to my site.
In Firefox (Windows) the "popout" covers the button so one can't press it.
Any other browser renders the popout in the correct place. Can someone confirm this? Or is it a conflict on my site?
Since you don't mention which site is yours I'm left to speculate on the reasons for this and if I do then I think it is that your body-element doesn't start at the top left of your browser and that therefor positioning of the popout fails due to browsers inability to correctly account for offset body elements.
We've had reports of people experiencing this problem in eg. WordPress where the admin-bar that's showed when a user is logged in pushes the entire site down 20 pixels or something and makes the position of the popout be of by 20 pixels. Could it be something similar for you - that you're logged in in Firefox and not in other browsers?
As far as I know there's no workaround for this limitation - eg. jQuery can't account for it either.
Good thing though: If your layout has a body with an offset or something else that makes the popout not work for you you can disable it by setting popout 0 in the settings of the button.
I have C# MVC web app that has some textboxes that in IE9 you can enter in text, but you can't highlight via the mouse or via holding shift and the arrow keys.
I've looked around on the web and i've found other people experiencing this, with no solution.
One site i found claimed it was an issue with IE9 on pages that make multiple AJAX calls, which my site has but, removing AJAX really isn't a solution.
Is there a way via code or via settings in IE9 so that users can highlight text in a textbox? Or is this an outstanding bug in IE9?
Edit:
The website works perfectly fine in chrome
Turns out it was a rogue jquery statement that was
(.someClass).disableSelected()
that was disabling selection on every single textbox in my site. The kicker being that IE and Chrome handled it one way and Firefox a different way making it seem like a different bug
I had the same issue.
Select Tools on the IE bar / F12 developer tools. under the tab ( Document Mode IE9 standards ) check marked Alt+9. Closed the developer box. Closed IE9 opened it back up and everything worked as it should.
Hope this helps.
I have a custom tabbed style control, and internally it works by showing or hiding the relevant page when you click on a tab.
The basic order of things that happen when you click a tab is
Bring relevant page to front
Show relevant page (by calling SetWindowPos with the appropriate flags)
Hide the old page that we just covered up
Repaint the window
Some of my tabs are rendered with DirectX. Under Windows XP everything works fine and there's no flicker when you switch between tabs. Under Windows 7 though (or Vista), the call to SetWindowPos in step 2 redraws the window, and there's a flash of uninitialized pixels before step 4, usually whatever was on the desktop before my app started running.
This only happens with the DirectX pages, but I'm not sure what it is about DirectX that would cause this, if anything - there are other differences between the pages as well, that was just the obvious pattern. I'm not sure if this is a real clue or a red herring.
The GDI pages don't repaint until step 4. I stepped through the code and checked - it's not just that the DWM uses a correctly cached bitmap in step 2 - it really doesn't repaint at all until step 4.
That's the background info, but at the moment I'm not sure how to tackle this specific problem, so my question is more general:
What are all the things that can affect SetWindowPos's decision to repaint or not?
I have a dot net nuke site that I have written a custom module for. It a form that users fill out to submit information - no big deal.
On the form, I use the Ajax and the Ajaxoolkit for validation, and a calendar popup. I enable/disable controls based on form data.
Everthing works well in every browser/OS combo that I have tested EXCEPT IE7/Vista.
The page renders with most of the lables and conrols invisible. The controls are there and you can even enter data, you just can see them.
Here is a link: http://www.gpusbc.com/test/tabid/76/Default.aspx
I develop on a Win XP machine with IE7 and FireFox and there are no problems.
FireFox on Vista has no problems.
FYI this doesn't work in IE8 on Vista in regular or in compatiblity mode. This is incredibly weird because the controls are there you can click in them but your textboxes for example if you type you don't see the data.
What I've found is that if you remove the float:left style which is inherited from the .aaInput class that all of your inputs become visible. I also removed your display of
block. Do this on both the labels and your inputs and you should be good.
I tested this with IE8's developer tools in both IE8 mode and compatibility mode.