본 사이트는 여러분의 사용자 경험을 개선하기 위해 유지 보수를 진행하는 동안 기능이 제한됩니다. 도움말로 문제가 해결되지 않고 질문을 하고 싶다면 Twitter의 @FirefoxSupport 및 Reddit의 /r/firefox 채널을 활용하세요.

Mozilla 도움말 검색

고객 지원 사기를 피하세요. 저희는 여러분께 절대로 전화를 걸거나 문자를 보내거나 개인 정보를 공유하도록 요청하지 않습니다. "악용 사례 신고"옵션을 사용하여 의심스러운 활동을 신고해 주세요.

자세히 살펴보기

DOM corrupted after innerHTML (using <input id='id' …)

  • 7 답장
  • 3 이 문제를 만남
  • 1 보기
  • 최종 답변자: cor-el

more options

I'm on a success function (in javascript) after an ajax call.

1 myFunctionOnSucces(transport){
2 var sDoc = transport.responseText;
3 var oDummy = document.createElement('div');
4 oDummy.innerHTML = sDoc;
5 var here = 'breakpoint';
6 }

Debugging on line 5 I have this on javascript: sDoc: "<form name='form_edit' method='post' action='my-web'> <input type='hidden' name='id' value=> </form> " oDummy: type div.

When looking on his FirstChild property I have: form#[object HTMLInputElement] my-web

If I remove the hidden input on the response text from server, the object FirstChild of oDummy is: form my-web

So in case I have some input with id='id' then the DOM elements added by oDummy corrupt the form element (it puts [object HTMLInputElement] as the form id atribute).

Is there any restriction on the id's attribute value I can use?

It happens on firefox 26 (not in 17). It happens both, linux and windows client.

Thanks a lot.

Jordi

I'm on a success function (in javascript) after an ajax call. 1 myFunctionOnSucces(transport){<br /> 2 var sDoc = transport.responseText;<br /> 3 var oDummy = document.createElement('div');<br /> 4 oDummy.innerHTML = sDoc;<br /> 5 var here = 'breakpoint';<br /> 6 } Debugging on line 5 I have this on javascript: sDoc: "&lt;form name='form_edit' method='post' action='my-web'&gt; &lt;input type='hidden' name='id' value=''&gt; &lt;/form&gt; " oDummy: type div. When looking on his FirstChild property I have: form#[object HTMLInputElement] my-web If I remove the hidden input on the response text from server, the object FirstChild of oDummy is: form my-web So in case I have some input with id='id' then the DOM elements added by oDummy corrupt the form element (it puts [object HTMLInputElement] as the form id atribute). Is there any restriction on the id's attribute value I can use? It happens on firefox 26 (not in 17). It happens both, linux and windows client. Thanks a lot. Jordi

글쓴이 cor-el 수정일시

모든 댓글 (7)

more options

Hi Jordi, as you can see, the forum software doesn't handle code excerpts very well...

Is there any restriction on the id's attribute value I can use?

form_edit is a valid character string for an ID attribute, according to the traditional rules. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#id

If you want to post code or a list of strings for consideration, and you don't have a demo page online, you may want to use one of these sites:

more options

Thanks jscher2000 for your tip and for your answer.

The problem I have is not related to form id value (form_edit) but with input name value (id).

Is "id" an allowed value for atribute name (or id atribute)?

I have DOM correupted just when I use "id" as a value for name atribute. And I have a lot of code using it (and working until few weeks ago) :-(

more options

Oh, I thought id="id" was just a placeholder for the actual string...

A few versions ago, there was a major change under the covers in how element properties are handled. This could explain why using a global attribute name like id as a value for some other attribute has become a problem in your application.

more options

Thanks a lot jscher2000.

I read the standard and I can't see any restriction about use "id" as a value for atribute name.

So, may be this is a bug for firefox on later versions?

more options

If you feel motivated, you could file a bug for this here: https://bugzilla.mozilla.org/

more options

Thanks a lot!

I'm goning to do it.

more options

Note that you need to test this in a clean profile without using any extensions and possibly only use the built-in web developer tools.

See "Creating a profile":

You may also check this out in a Beta and Aurora nightly build to see if this still happens.