Dirty parent when removing a child node.

[asajeffrey]

In Node::remove_child, dirty both the child and the parent. Fixes #8135

[highfive]

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @larsbergstrom (or someone else) soon.

[larsbergstrom]

r? @Ms2ger or @Manishearth

[Manishearth]

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

---

^{components/script/dom/node.rs, line 337 [r1] (raw file):}
Minor nit: The owner_docs of the two will be the same, and self.owner_doc() roots, so we should use the local variable to avoid rooting twice

---

Comments from the review on Reviewable.io

[Manishearth]

r=me with that nit

[Ms2ger]

r? @pcwalton
I have no idea how the dirtying stuff works.

[asajeffrey]

Review status: all files reviewed at latest revision, 1 unresolved discussion, all commit checks successful.

---

^{components/script/dom/node.rs, line 337 [r1] (raw file):}
I rooted twice in case we're in the middle of a DOM mutation that's caused the parent and child to be in different document. AFAICT there's no such case at the moment, so this may be over-cautious future-proofing.

---

Comments from the review on Reviewable.io

[pcwalton]

@bors-servo: r+

[bors-servo]

📌 Commit c1ab8a0 has been approved by pcwalton

[bors-servo]

⌛ Testing commit c1ab8a0 with merge 23a0f6c...

[frewsxcv]

Sorry for the reopen noise. For whatever the reason, the builders keep getting stuck on this PR and for the sake of keeping them working on other things, reopening this allows them to do so

[eefriedman]

@bors-servo r-

If there's something wrong with this PR, we should just take it out of the queue.

[frewsxcv]

Easier said than done :-/

http://build.servo.org/homu/queue/servo

[frewsxcv]

@bors-servo r- force

[Ms2ger]

@bors-servo r- force

[Manishearth]

@barosl is this a homu bug?

[barosl]

Uh, I'm not sure. Did Homu refuse to remove this PR from the queue? That's quite odd. Were there any exceptions raised?

[Manishearth]

Yes, and no exceptions. This isn't the first time it's happened either. Not sure what the reason is though.

[barosl]

It seems that the build results for the linux-rel, mac-rel-css, mac-rel-wpt builders are somehow still regarded as "running", even though they are not shown in the builder status. I guess this confused Homu? Considering all the other builders were OK at the time, there might have been some temporal error on the release mode builders.

But it is still strange that r- didn't remove the PR from the queue. Could we try that again? Close #8315, reopen #8139, and r- this. Let's see if the error happens again. (Sorry for the noise!)

[Manishearth]

I think this only occurs when there's a running build and we r- it

[barosl]

By "running build", do you mean the situation when r-ing a PR whose status is pending?

[Manishearth]

Yes.

Actually, I think in this case the build wasn't running. Not sure.