Closed
Bug 1070015
Opened 10 years ago
Closed 9 years ago
When we try pass to removeAttributeNode() attr object, which belongs to the different element, "NotFoundError" exception is not thrown.
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
mozilla38
People
(Reporter: anujagarwal464, Assigned: egorov, Mentored)
References
Details
(Whiteboard: [lang=c++])
Attachments
(1 file, 1 obsolete file)
4.11 KB,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
No description provided.
Assignee | ||
Comment 1•10 years ago
|
||
Can I take this one? I created a test in content/base/test from a similar one in the same directory. It triggers a bug and fails in two places now: 1. When removeAttributeNode() not throws exception when it called with 'foreign' attr object as argument. 2. When node was deleted after such call. Test checks removing of attribute with a same name in two elements. Would it be useful to check removing with different names? I can't find sources for removeAttributeNode() for now. I used ack/ag since 'hg grep' search through all commits. There are idl files dom/interfaces/core/nsIDOMElement.idl and dom/webidl/Element.webidl with metioned function, but it is just interface descriptions. Where can I find it?
Assignee | ||
Comment 2•10 years ago
|
||
RemoveAttributeNode is implemented at http://mxr.mozilla.org/mozilla-central/source/content/base/src/Element.cpp#1027.
Reporter | ||
Comment 4•10 years ago
|
||
@Boris: Use http://dxr.mozilla.org/mozilla-central/source/ to search for source.
Assignee | ||
Comment 5•9 years ago
|
||
So I made some investigation. Element::RemoveAttributeNode() takes Attr, use its NodeInfo to extract namespaceURI and LocalName, and pass this two nsAString's to nsDomAttributeMap::RemoveNamedItemNS(). Later calls do not use any other information about attribute except its name. I can't found any way to check if specific attribute belongs to element. Is there any method for this?
Assignee | ||
Comment 6•9 years ago
|
||
With help of the user Ms2ger in IRC I found needed method and a way to throw error. Looks like this patch fixes problem.
Attachment #8496439 -
Attachment is obsolete: true
Attachment #8554265 -
Flags: review?(jst)
Assignee | ||
Updated•9 years ago
|
Attachment #8554265 -
Flags: review?(jst) → review?(bzbarsky)
Assignee | ||
Comment 7•9 years ago
|
||
@bz is a mentor for this bug, so I probably should set him as a reviewer from the beginning..
Comment 8•9 years ago
|
||
Comment on attachment 8554265 [details] [diff] [review] Patch to solve bug + mochitest This looks great, thanks!
Attachment #8554265 -
Flags: review?(bzbarsky) → review+
Comment 9•9 years ago
|
||
Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=7efccf4361b7
Comment 10•9 years ago
|
||
Looks good, apart from things that were also broken on inbound on the parent of that push.
Keywords: checkin-needed
Comment 11•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ba0b46b1b3b5
Assignee: nobody → egorov
Keywords: checkin-needed
Comment 12•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/ba0b46b1b3b5
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in
before you can comment on or make changes to this bug.
Description
•