| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
const range = document.createRange();
const selection = window.getSelection();
range.selectNodeContents(target);
range.collapse(false);
const textNode = document.createTextNode(text);
range.insertNode(textNode);
selection.removeAllRanges();
selection.addRange(range);
assert_greater_than( target.innerHTML.length, 0, 'The text should be inserted into the styled <strong> element' );How about adding a helper function for this?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
const range = document.createRange();
const selection = window.getSelection();
range.selectNodeContents(target);
range.collapse(false);
const textNode = document.createTextNode(text);
range.insertNode(textNode);
selection.removeAllRanges();
selection.addRange(range);
assert_greater_than( target.innerHTML.length, 0, 'The text should be inserted into the styled <strong> element' );How about adding a helper function for this?
Added!
Since these tests are supposed to be checking editing scenarios, it seems like it's going against the point if we replace them with DOM commands like inserting via Range.
Could we instead use https://web-platform-tests.org/writing-tests/testdriver.html#test_driver.send_keys, or this helper function: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/editing/include/editor-test-utils.js;l=38;drc=814df61549a8cc15c39ba6870a329aa324b50acf
That gets us closer to testing the actual user scenario of typing characters.
Since these tests are supposed to be checking editing scenarios, it seems like it's going against the point if we replace them with DOM commands like inserting via Range.
Could we instead use https://web-platform-tests.org/writing-tests/testdriver.html#test_driver.send_keys, or this helper function: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/editing/include/editor-test-utils.js;l=38;drc=814df61549a8cc15c39ba6870a329aa324b50acfThat gets us closer to testing the actual user scenario of typing characters.
+1
The test failed on headless_shell because document.execCommand() is
returning false for insertText commands, causing the expected andIs this expected? I believe `execCommand('insertText'` should be supported, so I'd expect it to work on headless also?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The test failed on headless_shell because document.execCommand() is
returning false for insertText commands, causing the expected andIs this expected? I believe `execCommand('insertText'` should be supported, so I'd expect it to work on headless also?
In the link-boundaries-insertion.html test, when we run the execCommand after placing the selection, the text is supposed to be inserted inside the anchor tag, but it ends up inside the paragraph tag instead. So, the execCommand is working but inserting at wrong position. This seems to be a bug.
For another test, where the caret is supposed to be placed in an empty selection and then insert the letter 'a', it fails to place the caret in a non-styled strong element because there's no layout. For styled elements, the caret gets placed because the style gives the element a defined width and height, allowing the text to be inserted. This issue occurs in all browsers with the click event. As per the test, it tries to click at the position of empty selection. But, if only selection is placed using range and selection API's and insertText is called, firefox behaves properly and inserts 'a' unlike webkit and chromium.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The test failed on headless_shell because document.execCommand() is
returning false for insertText commands, causing the expected andPranav ModiIs this expected? I believe `execCommand('insertText'` should be supported, so I'd expect it to work on headless also?
In the link-boundaries-insertion.html test, when we run the execCommand after placing the selection, the text is supposed to be inserted inside the anchor tag, but it ends up inside the paragraph tag instead. So, the execCommand is working but inserting at wrong position. This seems to be a bug.
For another test, where the caret is supposed to be placed in an empty selection and then insert the letter 'a', it fails to place the caret in a non-styled strong element because there's no layout. For styled elements, the caret gets placed because the style gives the element a defined width and height, allowing the text to be inserted. This issue occurs in all browsers with the click event. As per the test, it tries to click at the position of empty selection. But, if only selection is placed using range and selection API's and insertText is called, firefox behaves properly and inserts 'a' unlike webkit and chromium.
In the link-boundaries-insertion.html test, when we run the execCommand after placing the selection, the text is supposed to be inserted inside the anchor tag, but it ends up inside the paragraph tag instead. So, the execCommand is working but inserting at wrong position. This seems to be a bug.
Do we understand this bug? I'd like to avoid papering over a bug by changing the test to avoid it. It sounds like you've got a lot of context about what's going on, perhaps you could see why this bug exists? If not, I think it'd at least be a good idea to file a bug with these details so that we don't lose the context.
The test failed on headless_shell because document.execCommand() is
returning false for insertText commands, causing the expected andPranav ModiIs this expected? I believe `execCommand('insertText'` should be supported, so I'd expect it to work on headless also?
Mason FreedIn the link-boundaries-insertion.html test, when we run the execCommand after placing the selection, the text is supposed to be inserted inside the anchor tag, but it ends up inside the paragraph tag instead. So, the execCommand is working but inserting at wrong position. This seems to be a bug.
For another test, where the caret is supposed to be placed in an empty selection and then insert the letter 'a', it fails to place the caret in a non-styled strong element because there's no layout. For styled elements, the caret gets placed because the style gives the element a defined width and height, allowing the text to be inserted. This issue occurs in all browsers with the click event. As per the test, it tries to click at the position of empty selection. But, if only selection is placed using range and selection API's and insertText is called, firefox behaves properly and inserts 'a' unlike webkit and chromium.
In the link-boundaries-insertion.html test, when we run the execCommand after placing the selection, the text is supposed to be inserted inside the anchor tag, but it ends up inside the paragraph tag instead. So, the execCommand is working but inserting at wrong position. This seems to be a bug.
Do we understand this bug? I'd like to avoid papering over a bug by changing the test to avoid it. It sounds like you've got a lot of context about what's going on, perhaps you could see why this bug exists? If not, I think it'd at least be a good idea to file a bug with these details so that we don't lose the context.
Raised a bug with the link - https://crbug.com/409355663 to track.
Pranav Modi abandoned this change.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |