I'm trying to copy the behavior of Gmail with the checkboxes, selecting a whole range click on one and then shift-clicking another, the checkboxes in between these will change.
However, I'm having a compatibility issue between Firefox and Chrome as clicking the checkboxes works just fine, but clicking the labels somehow it's handled very differently, as Firefox will apparently not trigger the change when shift-clicking.
You can check and test my code here.
Obviously there's a trouble with Firefox and the label, I've tried triggering the checkbox's change(), but it works backwards the behavior of the checkbox, I've tried 'resetting' the label events with preventDefault() and then triggering the change() event and the issue seems to be the same, but now Chrome has this bug (which I think it's somehow the correct way, first homologizing).
The easy way is detecting browsers, but every web developer guru tells us that it's better to identify the problem rather than the browser, so what would be a good fix for this? Also, it doesn't work in IE because it doesn't support indexOf().
Thanks!
For some reason the tag is working differently when highlighting text in Firefox. I think the reason it is failing is because when you hold down shift and click on the label, it doesn't check the box and thus doesn't fire the labeled event.
Check out this: http://jsfiddle.net/xerf/Prxdn/10/
This works both in webkit and FireFox. I changed the labels to span tags. With a bit of CSS, you can fix the padding.
Related
I am probably wasting my time with this question but here goes.
Chrome and Opera do not handle events in option elements IE and Firefox do.
So I am wondering I some knows a workaround other than using onchange in the select element, as I have tried to work with that event and pull errors of null value.
onchange="side_nav(this.getAttibute('id'))"
The code I am using is simple id change that works sweet in anything but option elements in chrome and opera, This is the function.
function side_nav(id)
{
document.getElementById("selectedS").setAttribute("id","");
id.setAttribute("id","selectedS");
}
Like I said it works with this in the option element but only in IE and FireFox
onclick="side_nav(this)"
The function works sweet in buttons and I suspect every other element also, just not the one I am set up to use.
I suspect I will have rewrite the nav panel to fix the problem, but thought I would ask someone else there thoughts.
This is What I believe is the answer. not well written but addresses the issue with an answer.
This is a response to Chrome bug reporting. The actual post
Fist I must say after further evaluation I believe that this is not as much a bug or defect but is in how the browser handles the select and option elements. As I see this the browser sees the option element/tag more as an attribute of the select element rather than than an individual element. The select element/tag is just a multidimensional array in HTML and the option tags become attributes of the select element which is why events do not fire and is also why it is impossible to style the option element/tag. I see now that this is deep in source code and seems to be split up equally between the top four browsers. I'll put the basic select code that I have been working with but it will be of no help as it is just the norm, and as I said, it's not a bug but program design.
Thanks for the response.
I am working on a custom application for the iPad that runs as a homescreen app, but is made in all CSS/HTML/Javascript. (not using the SDK here)
I have run into an issue with a calculator I have built into my page not hiding the keyboard. No matter what I do, the keyboard stays up. I have searched this extensively and tried everything I can think of, but the keyboard stays up no matter what I do.
Explanation of what I have tried to hide the keyboard:
I have tried to blur all input fields to remove focus. I have tried setting focus onto non-text field items.
There were several threads on Stackoverflow from earlier this year/last year that suggested both of those options, but they do not appear to be working anymore.
To test further, I put a blank a href="#" on an img that was above the calculator, so that I could set focus on a non-entry and see if that would auto-minimize the keyboard. When I tap that item above the keyboard the focus changes and I am no longer in input mode, but the keyboard stays up.
Did Apple break this functionality with the latest update? If so, is there a work around?
Here is some example code that doesn't work:
$('input').blur(function(e) {
// Keyboard disappeared
window.scrollTo(0, 1);
});
That code successfully removes focus from the inputs, but the keyboard stays up. I have also attempted the inverse of that by just .focus ing on a non-text element. And additionally, as stated previously, I have straight-up just added a non-text element on the page and that still doesn't hide the keyboard.
Thanks so much for any help, and feel free to link/abuse me if I have mistakenly reposted. :)
you should be able to blur it just by using something like this
$('input').blur();
you should put this inside the function/procedure that happens when you want it to disappear, unless your looking to disable it completely?
document.activeElement.blur() inside a try catch block works for me. (Possibly you also need a setTimeout? I didn't need a timeout, and it is important to avoid timeouts wherever possible because they can easily cause nasty heisen-bugs!)
Also double check that you are not calling focus() somewhere within a mousedown or click event (which causes the keyboard to show). You can use a console.log(document.activeElement.tagName); or similar to help find what has current focus.
However if you don't find a solution then I am very interested in seeing how you get the keyboard to stay up... I have a use for that :-)
I have somewaht of a strange problem. I am not sure if I am screwing up or if this maybe even is a bug in webkit.
What I am doing is using some more or less complex CSS tricks (:after and content, sibling selector, etc) and custom data-attributes to indicate if the input fields of a form are valid or not.
I have a data attribute "data-valid" on each input field together with an attribute "data-validate", which contains a regular expression. On keyup I run the regular expression against the value of the input and set data-valid accordingly.
I then have a small div next to the input, that is styled using a data-valid sensitive attribute selector. The background will show an ok symbol if the sibling's input data-valid attribute is true and will show a fail symbol if it is set to false.
Because this might be hard to understand, I stitched together this jsfiddle, so you can look at it yourself.
All this works perfectly fine in Firefox 6 and IE9. However, in both Webkit based browsers (Chrome + Safari) this will not work 100% correctly. Allthough the data-valid attribute changes correctly, the styled div will not change it's appearance until I either input additional characters or unfocus the input field. It nearly looks like the Webkit browsers fail to repaint / restyle that particular div.
I really don't know what's going on, I am rather confident, that this should work as I expect it to. I hope someone can come up with some insight or even explaination and maybe a fix/workaround.
Thanks alot!
It's all a bit complicated, so I'm not completely sure, but with selectors like this:
input[data-valid="true"]+div.indicator
I think you're suffering from the same bug as discussed in this question:
CSS attribute selector + descendant gives a bug in Webkit?
#DADU, the owner of that question, has already filed a bug report, but nothing seems to have come of it yet.
I came up with a (clunky) workaround. I noticed, that the indicator div would update if the focus state of it's corresponding input changes. So I added some input.blur().focus() magic to automatically unfocus and refocus the inputs after each keyup event. This isn't very nice, but it works and makes Webkit repaint the sibling divs.
I have a really nasty problem with focus in Internet Explorer.
I have a textarea for inputting text. This textarea is not visible for the user and is only used to provide robust text input for a more advanced view.
As the textarea isn't visible and shouldn't be I use textarea.focus() in the JavaScript to activate text-input. This has worked fine until now where I get really weird results.
For the textinput I basically use this event plus an exact copy for onkeypress.
textarea.onkeyup = function (e) {
//textarea.value contains the full text
//Update the view with this value
};
The problem is that sometimes textarea.value is not updated. I can even see the button in e.keyCode on the keyup event above but the value isn't changed.
This seems to happen after I have clicked somewhere on the page, but this does not trigger a blur-event. I'm logging the onfocus- and onblur-events so I can see when the textarea loses focus but it doesn't. And i still receive the keyup/press/down events.
If I try to refocus the textarea with textarea.focus() the problem remains. A workaround I found though is to focus the window with window.focus() and right after call textarea.focus().
The problem with this is that focus is a really expensive operation in IE (no kidding) and since I cannot detect when this problem will happen I have to keep doing it with certain interval which seriously affects the performance of my application (involves animation etc).
I use the exact same code for other browsers and do not have this problem there.
Change the identifier to something less generic like "textAreaAdv", IE sometimes get confused with this word.
I have a series of select elements in a form on a mobile site. These select elements are inside a scrolling pane handled through JS and CSS3 transforms, so getting a touch/click/whatever event to register on the selects was enough of a pain in the first place. However, I'm now finding, on android only, that even though the selects are getting clicked, and are getting focus- they simply refuse to open. I'm 100% sure that the selects are getting their focus event (through debug), so honestly, I am completely stumped. Without the debug, there are no other focus/blur events on the selects. It works fine on iPhone... any ideas?
I've been banging my head against the wall with this same issue. It seems to be isolated to Android 2.1/2.2 (and maybe 2.0?). The selects work fine in Android 1.5/1.6. I even created a simple page that just changes the select's display style from none to block and the select still doesn't open consistently. Oddly, sometimes after page refresh it might work, then after another refresh it might be broken again. As you stated, focus and click/touch events do fire from the element, so I'm at a loss as to what the issue is.
Sometimes if I zoom the page I can get the select to open, but even then the value selected isn't represented in the select element on the page.
I submitted a bug report to the Android dev team, but even if it's fixed in future builds the problem will still exist in 2.1/2.2.
Anyone find a workaround for this yet?
//---- Update ------
If you use a webkit-transition to show/hide the element, attaching the following event to the element appears to fix the select inside of it:
.addEventListener("webkitTransitionEnd",function(e){
this.innerHTML = this.innerHTML;
},false);
I'm not entirely sure why this works, but re-writing the element to the DOM seems to help for some reason. Tested in Android 2.1/2.2 simulator, EVO4G and MyTouch.
I found the solution in this answer by a.meservy. Here is the answer, copied for everyone's convenience.
In this case the problem was actually caused by jQTouch. To fix it, just comment out these 4 lines in jqtouch.css
Under "body"
/*-webkit-perspective: 800;*/
/*-webkit-transform-style: preserve-3d;*/
Under "body > * "
/*-webkit-backface-visibility: hidden;*/
/*-webkit-transform: translate3d(0,0,0) rotate(0) scale(1);*/