Skip to content
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

Merged
merged 4 commits into from
Jul 18, 2016
Merged

Conversation

domenic
Copy link
Member

@domenic domenic commented Jul 12, 2016

This is all progress on #1431, within the bounds of what is web compatible and which I've been able to somewhat easily test.


<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>
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right you are 😊

@annevk
Copy link
Member

annevk commented Jul 18, 2016

LGTM, assuming your testing is correct.

domenic added 4 commits July 18, 2016 13:30
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.
@domenic domenic force-pushed the entry-origin-checks branch from 7699b11 to a6a1b71 Compare July 18, 2016 17:31
@domenic domenic merged commit a6a1b71 into master Jul 18, 2016
@domenic domenic deleted the entry-origin-checks branch July 18, 2016 17:31
domenic added a commit that referenced this pull request Jul 21, 2016
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.
annevk pushed a commit that referenced this pull request Jul 21, 2016
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.
annevk pushed a commit that referenced this pull request Jul 25, 2016
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.
alice pushed a commit to alice/html that referenced this pull request Jan 8, 2019
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants