Clean up after mutationevents

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: sicking, Assigned: sicking)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 534954 [details] [diff] [review]
Cleanup

Bug 650493 simplified our mutationevents a bunch. In particular it got rid of removable script-blockers which means that we can now depend on scripts not executing while there are scriptblockers (gasp!)

As promised, here's the patch to get rid of crufty code that we no longer need because of this.
Attachment #534954 - Flags: review?(Olli.Pettay)

Updated

6 years ago
Assignee: nobody → jonas
Status: NEW → ASSIGNED

Comment 1

6 years ago
Comment on attachment 534954 [details] [diff] [review]
Cleanup

.
>-    nsCOMArray<nsIContent> fragChildren;
>-    if (!fragChildren.SetCapacity(count)) {
>-      return NS_ERROR_OUT_OF_MEMORY;
>-    }
>-    PRUint32 i;
>-    for (i = 0; i < count; i++) {
>+    nsAutoTArray<nsCOMPtr<nsIContent>, 50> fragChildren;
>+    fragChildren.SetCapacity(count);
>+    for (PRUint32 i = 0; i < count; i++) {
Nothing to do with this bug, but ok.




We should rename the removeChild* methods which may fire mutation events.
The name should somehow indicate that event may be dispatched.
And for consistency, same for insertchild* methods.
Right now I need to every time look at the source code to see which version of
removeChild is doing what.
Please file a followup bug for this issue.
Attachment #534954 - Flags: review?(Olli.Pettay) → review+
Checked in!

http://hg.mozilla.org/mozilla-central/rev/d000e25ae7f9

Thanks for the quick review.

I filed bug 659706 on the renames.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Depends on: 665387
You need to log in before you can comment on or make changes to this bug.