I've been working on this project (website, ASP.NET, VB.NET, IE8 [no choice on that]) for almost 2 years with no problems with the back button. I use mostly SQLDataSources, GridViews, and DetailsViews. All of a sudden, two weeks ago, the browser's back button becomes grayed out when I click on a link or button; it seems to be happening to any buttons or links. And of course, it doesn't happen in Chrome. Too bad I can't change the browser the company defaults to.
Any ideas?
Related
The strangest behaviour occured and I can't handle it myself.
I have ASP .NET MVC application with Jqgrid version 5.1.0. Everything works fine, beside one dialog window.
In my grid I use default deletion method. There is delete button defined by $(tableHtmlId).navGrid( ... ) function. After clicking delete button, confirmation dialog window appears. This dialog has misplaced cancel button (the one on top-right corner), as shown on following screen:
I thought about editing css styles, so I hit the console button, and as soon as develpers tool window appeard, look what happened:
Everything look fine. However, when I put cursor over cancel button, it goes back to wrong:
This behaviour occurs on Chrome, Firefox and IE. This bug is too atomic for me to solve. Please help. :)
I need to find what key the user pressed on a keyboard using xamarin.forms, ideally inside an AbsoluteLayout. I've come up with a few ways myself, but can't get any of them working.
As there isn't an event for this on the AbsoluteLayout control, i tried a little cheat, which was putting an entry field (textbox) on the screen, but hiding it above, so it can't be seen and using the result from that, but it loses focus when someone presses the screen or a button on the screen. so i tried adding an event to each button which refocuses the textbox once i've handled the press and this seemed ok at first, however, if they press anywhere else on the screen, it also loses focus.
I also tried adding a TapGestureRecognizer to the screen, and focusing the button when they press anywhere on the screen, however, there were 2 issues with this, the first being that it appears to only fire when something inside it is touched, and secondly, when i call the focus method for the second time (if they click the screen twice) it un-focuses the entry field, even if i check "isfocused" first (think this is a bug).
I'm only concerned about windows 8 and android apps so far. iOS may come later, but for now im just trying to get it working for these OS's. so maybe i could code it in the windows and android projects (inside my shared project solution), however, i have absolutely no idea where to even begin doing that. I mean, if this is the best way, how can i pass my AbsoluteLayout to the windows project and get it to know what it is, and convert it into a control which i can then add the event to.
Any help or advice, or ideas would be much appreciated. I cant find anything in NuGet which will help me with this. Any ideas?
Many thanks
James
I maintain a J2EE app written with the STRUTS framework. Recently my company upgraded Internet Explorer and the application now loses focus on the STRUTS Velocity menu tabs in the application.
I am not experienced with STRUTS, but googling is not giving me any options.
In IE8, a user would log into the application and the application tabs would automatically focus on the leftmost tab, and if there are sub tabs, the leftmost sub tab would be in focus. In IE11, this doesn't happen so the user gets confused when they can't access dialog boxes until they click on the tab. Clicking on the tab is not an acceptible workaround or using a different browser.
How do I force the leftmost tab in focus in Struts? Is there an undocumented option for the "Item" element in the config.xml? Or can I do this with CSS?
Thanks,
Tim
I went into the menu building JavaScript and noticed that the previous developer had missing ";". I guess IE8 is forgiving with missing ";" than IE11.
Anyhow, problem solved.
Tim
Background: for Windows users on Chrome and IE, dropdowns that reload or change the page are no good for accessibility. As soon as a user presses the down arrow button, the page reloads. This means that the user can only access the very first menu option. Here is an example: http://html.cita.illinois.edu/script/onchange/onchange-example.php
This is covered in the WCAG rule:
“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”
EXCEPT the user can very easily open up the dropdown and explore all the options without triggering an onchange event. The user does this with a space bar press. This is a very commonly known keyboard trick that I've seen all tested users to already be aware of or be able to figure out quickly.
In my system, we are using a dropdown for pagination in long directories.
EG: "you are on page [1^] of 16" (with the [1^] being a browser default dropdown menu). The designers will not allow any kind of visual [go] button. This happens across thousands of pages, javascript fixes I've seen need to account for every dropdown, and this is impossible on our case.
Using space bar, the user can see all the options and make a selection from anywhere on the list using only the keyboard. So why are dropdown page menus that automatically reload onchange still considered inaccessible? And would they be considered accessible if we included screen-reader only text which said "press space bar to open this menu, making a selection will load your next page"
Well except that in Firefox, the keyboard command is actually F4, you are correct - this is not a WCAG 2 violation but rather a best practice
Here is a page where you can test this: http://dylanb.github.io/onchange_select.html
I've run into a strange problem with an HTML form. I've built a dynamic table that adds a new row when you enter data into an existing blank row; because there are some server requirements in adding a row, I make an AJAX call to do this in the onblur event. It took a while to make this work for all browsers, but eventually all was happy with the world ... until IE8. Now, what happens is that, when the call returns from AJAX, the cursor shows in the next textbox (correctly), but the keyboard no longer works. I have to close the modal window (actually an IFRAME), then the keyboard starts to work again. If I put IE8 into compatibility mode, it works fine.
Has anybody seen behavior like this, or have any ideas for a workaround?
Thanks, Jim
I had problems with DIVs placed above an INPUT, that cloacked the cursor... and once the DIV was not above it, the cursor appeared back again.
Just an idea: Maybe your IFRAME captured the focus (and/or the keyboard).