Release 1.3.0 #1225
Merged
Release 1.3.0 #1225
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Upgrade to NUKE 9 and remove obsolete NET 6 and 9 targets
Also are included a couple of tests for targeting windows using _top and _parent. This is to ensure correct windows are targeted, as well as when adding support for targeting frames, targeting windows is not regressed.
This allows a `BrowsingContext` to know whether it is for a frame or a "top level window" so that predefined target values work as expected, specifically the `_top` and `_parent` target values.
When a window context targets either `_parent` or `_top`, it should instead target itself, even if it is a child window. Targeting `_top` should continue checking the parent until a window context is found. For this reason, when targeting `_top` or `_parent`, the context should be checked to determine if it is a frame context or a window context.
In order to allow targeting a frame by name, the child context needs the name of the iframe.
The document in the request is only updated when the `src` or `srcdoc` is updated. Navigation elements with named targets only update the named child `BrowsingContext` it is able to find, or creating a new one if one is not found. Thus, for an iframe's `CurrentDocument` to be updateable by a navigation element, it needs to use its nested context, rather than the request. Also, when the iframe is being set up, a nested context needs to be made and, if named, needs to be added to the parent context so that it is available for navigation elements targeting the iframe even if it does not have an intial document to load.
Targeting an named iframe works even if it is nested within an unnamed iframe. This is being added due to the previous design of nested browsing contexts where unnamed child browsing contexts are not added to the parent's collection of child brosing context, which prevents (or at least makes very difficult) to navigate from a parent browsing context to a child browsing context when attempting to find the target browsing context.
The helper method for generating data uris has been removed as the virtual requester is used for the tests instead. Also, added a language comment to the html raw string literals for editors that support this.
When multiple windows or iframes have the same name, only one can be the target. The new tests added perform checks to ensure the correct priority is used and the correct target is selected when there is a name collision.
When attempting to find a child browsing context by name, if one is not found for the current context, then all child contexts should be searched recursively. This allows a browsing context to be targeted even if it is deeply nested. In order to get all child browsing contexts, including annonymous browsing contexts, all attached browsing contexts on the active document is used.
After attempting recursively find a child target, should none be found, another attempt is made from the parent. This second level recursion ends once the topmost context is searched.
Adding new and modifying items in an interface is a breaking change, so remove that and check for the class directly when accessing new functionality.
Add support for targetting iframes
Feature/iframe target
After performing a recursive depth first search for a target on all browsing contexts starting from the first and continuing until the top-most, then all auxilary browsing context should be searched. Also, any new child context created which is not a frame context should be an auxilary browsing context, and added as a direct child of the top-most browsing context, rather than the browsing context attempting to create it. The order for searching auxilary browsing contexts is currently up to the implementation to decide, so long as it is consistent. The order chosen in this implementation is the order the auxilary browsing contexts were created.
Add support for finding targets in auxilary browsing contexts
This is something that I didn't even know could be done till I found an answer on StackOverflow detailing it, so I thought it might be helpful to put it right in the documentation.
This was a pitfall I encountered that I had to figure out myself. Hoping that documenting it can keep someone else from running into the same issue.
Form documentation enhancements
GetAttributeNode extension methods added to Element
… not a read-only property
INode.HasChildNodes is now exposed as a method to DOM
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Types of Changes
Prerequisites
Please make sure you can check the following two boxes:
Contribution Type
What types of changes does your code introduce? Put an
xin all the boxes that apply:Description
Release of 1.3.0 with some fixes and enhancements. Thanks a lot to @arekdygas, @TheJayMann, and everyone else for the contributions.