On http://megsmoxie.com/2012/12/enter-to-win-a-fijit-friend-willa/ (or any single post) the search, subscribe, and comment forms do not work in Ineternet Explorer.
You can click in them and see the cursor for a second, then it seems to lose the focus, so I assume it's not an overlapping div issue. If you press a key as soon you click, you can enter one letter, but then it loses focus. It works fine in chrome and ff.
Oddly enough, the problem does not occur in ie on http://megsmoxie.com/contact/ or the homepage (sidebar forms work fine as well as contact form), the issue is only on single posts. Any help would be much appreciated.
You'll note that if you click and hold your mouse down, you can type into the field without interruption. It's only when you release your mouse button that the focus is stolen, and you can no longer type. With this behavioral observation, I took to Chrome to see what events are being handled:
I found that the document has a handler for the mouseup event, and that this code was coming from icx-ez-excerpt.js. Tracking this back through your document, you can find the relevant references below (removing these, sure enough, resolved the issue):
<script type="text/javascript">
var icx_publication_id = 10591;
var icx_copyright_notice = 'Copyright 2012 Meg's Moxie';
var icx_content_id = '30168';
</script>
<script type="text/javascript"
src="http://license.icopyright.net/rights/js/copyright-notice.js">
</script>
Remove that, and the code works as expected in IE. I'll dig a bit further to find out what, in their code, is breaking the experience for your users.
I looked over this page and found a lot going on. This is most likely due to some contention with the onfocus events being fired all over the place. IE is notoriously bad at handling the onfocus event in particular.
In addition there seems to be some third party scripts and controls that are firing. Its very possible that one of those is stealing focus from the text boxes in IE only.
Not much more I can tell you beyond that. If you are the developer of this site you are going to need to do some more in depth debugging. Try eliminating some of the stuff going on and adding it back one by one until it breaks again or debugging some of the javascript.
Related
I have developed a webapp which we usually run on an ipads browser, usually Chrome. There is a problem for a older users when they need to press on a button. They usually press hard and longer than average users, thus the click never gets registered.
The app is an angular app and I've tried to bind a (mousedown) event in hopes of making it fire the event when first touch it. But it seems like that when you hold it down longer on an ipad, it just starts to focus on the text.
Any ideas on how to improve the UX in this case? A lot of older users gets frustrated because to them it does not work.
When you hold your finger on the button you may never reach the mouse events, especially if you move your finger a little. You may check the order of events here https://patrickhlauke.github.io/touch/tests/event-listener_all-no-timings.html
To handle your issue you may handle either pointerdown or touchstart event.
I have a weird situation. One of my users is using functionality of Chrome (current version, 49, 50), that he drags and drops a file from his folder on local computer to normal input type=file button in a form on the webpage. Once again, let me stress it even more, its normal html input, no fancy javascript, no drag&drop events and handlers, nothing like this. It just takes the name of the dragged file and puts it into the input field, as like he selected it via "normal" way, opening the file select window, locating file on harddrive, selecting the file and confirming.
In some specific situation, this stops working (while doing some edits in the page via javascript / ajax), and I need to "reenable" it.
But, and that is my question, I haven't found any documentation of this "feature" in Google Chrome (or maybe some other browsers as well, I don't know). Why it works, how it works, how it should work and what to do if it stops working :) Does anyone has any experience with this ? The only way how to "fix" it now is to reload the page. I'd love to solve it ... :)
EDIT 1 : I just did a quick test, it works and bugs the same way in Firefox on Win. It doesn't show any error in dev console or any message, it just doesn't add the file as expected.
I've found it. The previous discussion with deceze pointed me to test the javascripts I have on the page, that do not "interfere" with the input type=file ... they weren't any such scripts, but I've found that after doubleclick on the table (that I'm using for editing) this script is being called
$(document).bind('drop dragover', function (e) {
e.preventDefault();
});
and there wasn't any unbind action when table is saved ... this caused the drag and drop everywhere on the page to stop working after the edit.
I have a page with a pretty big table. Any text input on the same page responds really slowly to typing.
Anybody have any idea what would be the exact cause for this?
Occurs in Chrome (41~), but not in IE 10 or Firefox (30~).
Reducing the number of rows (to 20, for instance) makes the problem disappear.
Chrome's timeline shows ~500ms gaps between keypress/keydown events:
Could the long ng-class, ng-click, and other attributes be hogging Chrome's internal dom event handling?
Testable in this plunker.
(I've got angular all over the place in the original code, but the plunker is stripped of it.)
Thanks!
I'm working with a contenteditable iframe that is being using for basic WYSIWYG editing. I've noticed a strange difference in the way that a Tab keypress event is handled between Chrome and Firefox.
When the document of the iframe has been configured using designMode = 'On', a tab pressed inside the document will skip to the next control in Firefox (expected) but create the following pre white-spaced span in Chrome
<span class="Apple-tab-span" style="white-space:pre"> </span>
Here's an example.
Interestingly, when the body of the iframe is setup instead using body.setAttribute("contenteditable", "true"), which I assumed was the same approach done in a different way, both browsers work as i would expect; moving the focus to the next tab index.
Can anyone explain why?
I'm afraid that the only answer is "just because". Don't expect that there's a reason behind how something works in contenteditable. I experienced hundreds of times that no one really cared or had time to care about that. When you've got bugs like https://code.google.com/p/chromium/issues/detail?id=226941 which make contenteditable totally irritating for users on Chrome & Opera and which hasn't been even confirmed by developers throughout entire year, then a small difference in Tab's behaviour is a detail which you have to fix and forget ;).
Use:
document.designMode = 'on';
Insted of
body.setAttribute("contenteditable", "true")
this is insanely annoying problem:
AS3 full screen application based on ADOBE FLEX 4, text field. User types something in text field, and then starts clicking backspace many many times to remove what he just wrote, and for some reason, instead of removing characters from text field it tells browser to GO BACK and user navigates away. Why?! Please, please help, this is so terrible. My users are losing important unsaved this is data while using my application!
i am using safari browser
PLEASE HELP.
Wow, this is terrible, I am so irritated, it happens every single time
It is possible that the focus is lost from your text field when hitting the backspace multiple times (check if you are firing some events on the text field that may cause this), which causes the main window to take focus and trigger 'Back' on the browser.
The root of the problem is that the browser carries out keyboard shortcuts REGARDLESS of the flash app having the focus or not. From what I heard this problem does not exist on Safari's for Mac, only Safari for Windows.
I would check to see what browser you are in and then create a popup saying you this app does NOT work on Safari browser ON windows.
Scratching head*
Well maybe if HAD to solve this, I would use the ExternalInterface to interact with Safari or javascript to PREVENT the history back button from getting applied. So it won't go back to an old page. That is what I would look into.