Implement Document.readyState. Prevent iframes from notifying the compos...

[jdm]

...itor after the initial parse. Fixes #1720. Fixes #3738.

r? @Ms2ger or @Manishearth

[hoppipolla-critic-bot]

Critic review: https://critic.hoppipolla.co.uk/r/2938

This is an external review system which you may optionally use for the code review of your pull request.

In order to help critic track your changes, please do not make in-place history rewrites (e.g. via git rebase -i or git commit --amend) when updating this pull request.

[larsbergstrom]

Can either @Ms2ger or @Manishearth please take a look at this? I believe it's blocking a PR from @kmcallister which is in turn blocking a PR from @mbrubeck :-)

[Manishearth]

In a way #3776 blocks this one, lengthening the chain ;P

[Manishearth]

@mbrubeck You probably know this, but be a bit careful about the interactive ready state (scroll up) for #3721 once this merges.

[jdm]

r=Ms2ger

[bors-servo]

saw approval from Ms2ger
at jdm@539c21f

[bors-servo]

merging jdm/servo/readystate = 539c21f into auto

[bors-servo]

jdm/servo/readystate = 539c21f merged ok, testing candidate = 2df2363

[bors-servo]

all tests pass:
success: http://build.servo.org/builders/linux/builds/424
success: http://build.servo.org/builders/mac/builds/431

[bors-servo]

fast-forwarding master to auto = 2df2363

[hsivonen]

As noted in another PR, in the case of Gecko, I found that it would be beneficial to have state tracking across the navigation. If such a state tracking object existed, it would be logical for the true readyState to be kept on that object such that once Document is created, it would get a reference to the associated navigation tracking object and the Document's readyState could then call through to that object to ask for the state.