#7792 closed bug (worksforme)
.removeAttr("contentEditable")
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | undecided | Milestone: | 1.6 |
Component: | unfiled | Version: | 1.4.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
$("div").removeAttr("contentEditable");
FF 3.6.12 firebug 1.6.0: An invalid or illegal string was specified" code: "12
a.nodeTy...n(b=a.getAttributeNode("tabIndex"))&& |
I will add that there is no DIV to having Attr "contentEditable", but even as it is - the error is the same.
Change History (8)
comment:1 Changed 12 years ago by
Owner: | set to [email protected]… |
---|---|
Status: | new → pending |
comment:3 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Update: Testing your bug with jQuery 1.4.4 & FF 3.6.12 (and using 'div' as the selector of choice) everything seems to be working fine here without any errors being incurred.
Please see here for my second test case. Also, I've tested the fiddle you submitted - if you take a look at the selector, you are camel casing contenteditable in your selector, but not in the attribute reference being used. See here for a working version Live Test Case 3.
Closing this ticket as works for me but do let us know if you have further information or test cases which reproduce the issue submitted.
comment:4 follow-up: 5 Changed 12 years ago by
on IE 8.0.7600 have the same problem. screenshot from ff: http://www.freeimagehosting.net/uploads/e68c3e8923.png
Your case I run correctly. The error appears only with: $(document).ready(function()
$(document).ready(function() {$("div").removeAttr("contentEditable");alert("ok");}); On FF and IE alert "ok" don't pops up. http://jsfiddle.net/JYYY5/6/
comment:5 Changed 12 years ago by
Replying to anonymous:
on IE 8.0.7600 have the same problem.
Did you read the response of addyosmani? It has nothing to do with the ready-function but with
camel casing contenteditable in your selector, but not in the attribute reference being used
comment:6 Changed 12 years ago by
Reading, reading. I know where is the problem: .removeAttr("contenteditable") lowercase works, but if you insert a large "E "for FF and IE I get an error: .removeAttr("contentEditable").
comment:7 Changed 12 years ago by
I hit this also, with the code below. In short, it gets the name of the attribute from the element itself and then calls removeAttr on this name without modification. The documentation on removeAttr does not say that attribute names must be lower case.
The loop goes through many attributes fine before hitting contentEditable and throwing an exception. In the debugger I tried to change the attribute name to lower case before calling removeAttr and then it went well.
This happens on IE, but not on FF or Chrome for me, but I did not create the element so it might be it doesn't even have contentEditable on FF or Chrome.
(attributeWhitelists is a map from element names to arrays of attribute names)
function getAttributeNames(el) { var attrNames = []; for (var i = 0, attrs = el.attributes, l = attrs.length; i < l; i++) { attrNames.push(attrs.item(i).nodeName); } return attrNames; } function cleanAttributes(element, attributeWhitelists) { var domElement = element.get(0); var attributeNames = getAttributeNames(domElement); var elementName = domElement.nodeName.toLowerCase(); var validAttributes = attributeWhitelists[elementName]; for (var i = 0; i < attributeNames.length; i++) { if ($.inArray(attributeNames[i], validAttributes) === -1) { element.removeAttr(attributeNames[i]); } } }
comment:8 Changed 12 years ago by
OK, obviously I didn't follow the bug reporting guide lines. I'll post again with a reduced example in a jsfiddle if there is any interest.
Thank you for submitting a ticket to the jQuery Bug Tracker. In order for us to fully investigate the issue you are experiencing, please provide a reduced test case that reproduces the issue experienced on http://jsfiddle.net.
I have written a brief test case for this myself which you can find here Live Test Case. This is working fine on FF 3.6.10 and 3.6.11 but I'll verify behaviour with .12 and let you know if this is working fine for me across all recent versions too.