I am using a standard tinymce ui listbox (basically a button with a dropdown) with a few options.
I would like to make it work on mobile devices. But i do not seem to be able to achieve this.
I can access the control element of the listbox, but i am not able to find the dom elements that hold the options using the control element. If i would be able to get to them i could bind a touchstart handler and trigger the necessary function.
Does anyone know a solution to this problem or has a workaround?
Thx in advance
Found out it seems to work out of the box, but what i am trying to do onselect causes a problem.
Here is working a tinymce fiddle example just in case someone needs help.
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.
Is it possible to disable an item from a FilteringSelect using a store?
The documentation shows an example of disabling an item, but only if HTML markup is used, and nothing is mentioned about select widgets using a datastore.
Looking at the source doesn't give any clues either.
If it matters the version of dojo used is 1.9
After viewing at the source code I notice that dijit/form/Select extends from dijit/form/_FormSelectWidget which in fact makes it possible to retrieve and disable options in a select.
dijit/form/FilteringSelect however does not extend from the same widget but rather from a normal dijit/form/MappedTextBox (because of the typing abilities). Because of this, I'm quite sure it's impossible to do it out of the box, using a store or not (I wasn't able to get it to work without a store and didn't find such an example at the reference guide).
If you really need such a feature, I would suggest looking at the code of dijit/form/FilteringSelect, dijit/form/Select and dijit/form/_FormSelectWidget and trying to extend from one (ore multiple ones) and implement these features by yourself. The only question I ask myself is that, if this functionality isn't implemented by default, there might be a reason behind it.
I have an HTML <select> in many places in my application, and I want to replace it with a custom drop down. I have created the custom control which will replace the HTML <select> on DOM ready.
Now, I want to implement something that will disable/re-enable my new control if there is a Javascript disabling/enabling the original control without doing any changes in the application elsewhere except within the control.
How is it that I can capture the event of the HTML select control being disabled or enabled and attach some code to that? Is there any other way to do it?
UPDATE:
I got this thing working in IE7, Safari/Chrome but its not working in mozilla. Sample code in here http://jsfiddle.net/M73Wg/3/
This is a tricky one. Unfortunately (I believe) there is no straight answer. It comes down to: Yes you can do so by using JavaScripts DOMAttrModified event listener, but it's not cross-browser compatible.
Here are a few resources that might help you:
Detect Attribute Changes with jQuery (possible solution)
Is it possible to listen for changes to an object's attributes in JavaScript?
Listen for changes of checked/disabled in jQuery
Finally used timeout only http://jsfiddle.net/8EtJK/6/
DOMAttrModified is not working in mozilla
Regards,
SJ
I have made few changes on this huge JSF page, which is full of Javascript as well. I dont know which change make the problem happen.
The problem is: after some Javascript is executed, all the text fields in the page become readonly. The problem is not occurring in IE7 nor in Firefox. I have debugged all the javascript, there is no errors thrown! And there is nothing telling the fields to become readonly, since its working correctly in IE7.
Not sure what the problem is, could be CSS related? or Javascript? And why is it happening on IE6 only?
Note: "Don't support IE6 is not an option"
While IE may be buggy make trouble in some situations, I'm quite sure this is not an IE bug.
How do you tell the fields are read only? Do you get any optical confirmation or is it just that you can't click them any more? In that case, I'll bet you a beer that is's some invisible DIV or other layout element that, due to some CSS setting, squeezes itself above the input fields.
Try the IE developer toolbar to find out whether it's a layout problem.
If they are really disabled as in <input disabled> you need to show some JavaScript or (better) a link.
Still not sure what happened with that build, but what i was sure about is all the Ajax modifications i did was responsible for the problem.
The scenario was like:
Fill textfield1 (hit getValues1 , then hit a validate Ajax)
Fill textfield2 (hit getValues2 , then hit validate on both values together)
Fill textfield3 (hit getValues3 , then hit validate on all three values)
And a forth time again the same scenario. The page was built by a new to JSF guy, and it was very huge. I took long time refactoring it. But now its much better, each text field still have a getValues Ajax, but instead of validating them after getting all the values, i filter the allowed values on the server by sending the chosen criteria
The scenario now:
Fill textfield1 (hit getValues1 Ajax)
Fill textfield2 (hit getValues2 Ajax with value of 1, and get only allowed values)
... etc
The problem seems to be an Ajax racing conditions and at some moment IE6 was hanging or stuck in a deadlock, im not sure.
Lesson learned, "Refactoring once may take a week, but without every single issue will take longer"
um... don't support IE6??? ;)
Suggest disabling your CSS and seeing if the problem goes away. I'm not aware of any CSS tags that can disable a field, though.
Other than that, debugging is your only option. Remove all your .js and add it back in line-by-line until something breaks.
It will probably be hard for us to help you without seeing some code.
See if the HTML for the page has the 'disabled' attribute set on those INPUT elements. If so, then javascript is being used to enable the elements after the page has loaded. This is a not-uncommon technique to keep users from prematurely trying to interact with a page before all scripts have loaded.
If that's what is happening, then what you've probably done is break the way the script recognizes which elements need to be enabled. Since this is only happening on IE6, it sounds like the script might be doing some esoteric DOM navigation, which broke as a result of changes to the markup or CSS.
Unfortunately this is something you'll have to debug by reverting back to previous versions until you identify the change you made that broke the page.
Based on the other answers here, and some of your comments to them, it seems there is a JavaScript function in your page that sets elements to be enabled or disabled.
In order to help, we would have to see your code. Here is something you can do yourself, though, that would solve your problem:
Find that function (or ANY function) that sets elements in your page to disabled or enabled.
Depending on your development environment, there are different ways to do this, but somehow add a breakpoint there at the function.
Load the page.
Whenever that function is called, code execution will stop at that function. Whenever it stops, make sure that it was supposed to be called (and watch the call stack).
Eventually, you'll hit that breakpoint at a point where you weren't supposed to. Look at the call stack to see what caused it (which function resulted in a call to this function).