Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign up"Legacy platform object" getOwnPropertyDescriptor returns undefined when it should be finding dynamic properties #25036
Comments
|
Relevant to getOwnPropertyDescriptor for legacy objects: servo/components/script/dom/bindings/codegen/CodegenRust.py Lines 5130 to 5228 in 54d88fd |
|
I don't understand that code very well. In the named getter case, where is it actually looking up the name? |
|
|
|
That seems entirely plausible, yes. |
Removing .get() from some property descriptor field assignments to see what happens This is towards #25036 and #25415; it could have far-reaching implications so I want to test it in isolation and see the results on the full test suite. A few lines of code had a FIXME(#11868) despite that issue being closed, and looking for the pattern that was marked that way, I found one other unmarked instance of it. It doesn't immediately crash, and maybe it will pass some tests or fail some tests in informative ways. --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [ ] These changes fix #___ (GitHub issue number if applicable) <!-- Either: --> - [ ] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
|
Removing the .get() gets us three asserts further down in this particular test (failing on desc.enumerable); if it doesn't break anything else, it's an improvement. |
|
What's the enumerable failure? The descriptor returned should be unconditionally enumerable based on the this line. |
|
The test wants it to not be enumerable: |
|
Aha, that comes from step 2.8 of https://heycam.github.io/webidl/#LegacyPlatformObjectGetOwnProperty, since HTMLFormElement is listed in https://heycam.github.io/webidl/#LegacyUnenumerableNamedProperties. |
|
I see how that happened. The build is set up to fail if that extended attribute's specified without a named getter, and HTMLFormElement didn't have one yet when the extended attribute was being handed out. Window will also need it once it gets a named getter, and HTMLAllCollection once it exists. |
|
Updated #25446 now that I know it will fix this and not break anything else. |
|
remaining WebIDL/ecmascript-binding/legacy-platform-object.html failures are HTMLSelectElement-specific and probably just its lack of an indexed setter, #25003 |
Make getOwnPropertyDescriptor hold the correct value for indexed/named properties This is towards #25036 and #25415; it could have far-reaching implications so I want to test it in isolation and see the results on the full test suite. A few lines of code had a FIXME(#11868) despite that issue being closed, and looking for the pattern that was marked that way, I found one other unmarked instance of it. It doesn't immediately crash, and maybe it will pass some tests or fail some tests in informative ways. EDIT: After adding an overlooked extended attribute to HTMLFormElement, this works very well indeed and seems to be worth merging! --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #25036 <!-- Either: --> - [X] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Make getOwnPropertyDescriptor hold the correct value for indexed/named properties This is towards #25036 and #25415; it could have far-reaching implications so I want to test it in isolation and see the results on the full test suite. A few lines of code had a FIXME(#11868) despite that issue being closed, and looking for the pattern that was marked that way, I found one other unmarked instance of it. It doesn't immediately crash, and maybe it will pass some tests or fail some tests in informative ways. EDIT: After adding an overlooked extended attribute to HTMLFormElement, this works very well indeed and seems to be worth merging! --- <!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: --> - [X] `./mach build -d` does not report any errors - [X] `./mach test-tidy` does not report any errors - [X] These changes fix #25036 <!-- Either: --> - [X] There are tests for these changes OR - [ ] These changes do not require tests because ___ <!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.--> <!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
WebIDL/ecmascript-binding/legacy-platform-object.html tests out various things "legacy platform objects" (https://heycam.github.io/webidl/#es-legacy-platform-objects) are expected to do, most of which involving pretending to be arrays or open-ended hashmaps in one way or another. Mutliple tests fail on getOwnPropertyDescriptor, which is not seeing the dynamic properties.
HTMLSelectElement insufficiently pretending to be an array is also in #25003; there is possibly overlap, if the reason getOwnPropertyDescriptor isn't working is that the property isn't even there to get.
Other failures are DOMTokenList with numeric properties and DOMStringMap with named ones.