-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change a variety of entry settings object uses #1541
Conversation
|
||
<p class="note">Since this is neither a <span data-x="navigate">navigation</span> of the | ||
<span>browsing context</span> nor a <span data-x="traverse the history">history traversal</span>, | ||
it does not cause a <code data-x="event-hashchange">hashchange</code> event to be fired.</p> | ||
|
||
</li> | ||
|
||
<li><p>Let <var>targetRealm</var> be this <code>History</code> object's <span>relevant settings | ||
object</span>'s <span data-x="environment settings object's realm">Realm</span>.</p></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing this seems wrong. We could change it to use "relevant Realm" though as we've done for another instance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is actually just a redundant step. Earlier in the algorithm a very similar step already appears.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right you are 😊
LGTM, assuming your testing is correct. |
Since this is a same origin-domain check, we can use any settings object, as they are all same origin-domain. Part of #1431.
This updates the origin check in pushState/replaceState to use the origin of the document of the relevant History object, instead of that of the entry settings object. This more correctly matches 2/3 open source browsers: - https://chromium.googlesource.com/chromium/src/+/c21f0b11ac83ea970d0eaf6a0b223d48a32a4b32/third_party/WebKit/Source/core/frame/History.cpp#234 - https://github.com/WebKit/webkit/blob/0ee7b606dbf35d9688c15b19b1a83ec1ff242cd7/Source/WebCore/page/History.cpp#L150 (Gecko does no such security check). It also helps with #1431. While there, cleaned up some redundant steps and tightened wording.
The test at https://url-parsing-entry-gjqursujea.now.sh/entry/entry.html reveals that Firefox at least uses relevant for URL parsing. Boris says that Firefox does something nonsensical for the origin check and that he would prefer relevant or current. Code inspection reveals that Blink and WebKit use relevant for both URL parsing and origin checking: - https://chromium.googlesource.com/chromium/src/+/ee94bde91c72a046bec15436d56cfe32bb0e524c/third_party/WebKit/Source/modules/navigatorcontentutils/NavigatorContentUtils.cpp#71 - https://github.com/WebKit/webkit/blob/83624b838d4fa81df77060c51b09587169f8ff19/Source/WebCore/Modules/navigatorcontentutils/NavigatorContentUtils.cpp#L109 Edge does not support these methods. Helps with #1431.
Since this is a same origin-domain check, we can use any settings object, as they are all same origin-domain. Part of #1430.
7699b11
to
a6a1b71
Compare
In #1541, a few checks on the "currently-executing constructor" were added. The pull request review revealed that this phrase was not sufficiently precise, so it was replaced with "active function object", a term defined in the JavaScript specification. However, this was only done in one of the three places the imprecise term appears. This tidies up the other two.
In #1541, a few checks on the "currently-executing constructor" were added. The pull request review revealed that this phrase was not sufficiently precise, so it was replaced with "active function object", a term defined in the JavaScript specification. However, this was only done in one of the three places the imprecise term appears. This tidies up the other two.
In #1541, a few checks on the "currently-executing constructor" were added. The pull request review revealed that this phrase was not sufficiently precise, so it was replaced with "active function object", a term defined in the JavaScript specification. However, this was only done in one of the three places the imprecise term appears. This tidies up the other two.
In whatwg#1541, a few checks on the "currently-executing constructor" were added. The pull request review revealed that this phrase was not sufficiently precise, so it was replaced with "active function object", a term defined in the JavaScript specification. However, this was only done in one of the three places the imprecise term appears. This tidies up the other two.
This is all progress on #1431, within the bounds of what is web compatible and which I've been able to somewhat easily test.