Bug 1765654 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

dshin, when you're writing tests to include in the patch here: the "testcase 2 / reference case 2" pair might be usable as a reftest (or WPT rendering test) here, though we should probably include a few additional versions (or a few additional lines in the test) with `canvas` and `video` at least, to have some coverage for this general codepath with at least a few different replaced elements (not just `audio`).

These tests could conceivably go in `testing/web-platform/tests/css/css-writing-modes`, maybe with files being named `abs-pos-replaced-vrl-001.tentative.html` or something like that.  The `.tentative` string is important, since it's not clear to me that our "reference case" behavior is truly correct...  As it happens, Chrome happens to "pass" my attached testcase 2 / reference case 2 pair-of-files (as does Firefox release and Firefox Nightly with your patch, I think); but WebKit does not, and I sort of think nobody is correct.

(I say that I think nobody is correct because: theoretically, `position:absolute` content (with default `top/right/bottom/left` properties) is supposed to be positioned at the same spot where it would be, if it didn't have `position:absolute`.  So if you disable/enable `position:absolute` in devtools on the attached "testcase 2", the position should not change, unless there's some writing-mode-specific special case that I'm forgetting about.  In current Nightly, we actually match that expectation of mine **specifically for <audio controls>** due to this bug. :) but we match my expectation for bad/broken reasons and it's inconsistent.)

Alternately: given that our tests' required-behavior is ~debatable, we could just put the tests in our own private reftests directory and not bother anyone else with them (though they may turn up interesting assertions/failures in other browsers, so it's kind-of nice to share them).
dshin, when you're writing tests to include in the patch here: my attached "testcase 2 / reference case 2"  files might be usable to get you started on a reftest (or WPT rendering test) here, though we should probably include a few additional versions (or a few additional lines in the test) with `canvas` and `video` at least, to have some coverage for this general codepath with at least a few different replaced elements (not just `audio`).

These tests could conceivably go in `testing/web-platform/tests/css/css-writing-modes`, maybe with files being named `abs-pos-replaced-vrl-001.tentative.html` or something like that.  The `.tentative` string is important, since it's not clear to me that our "reference case" behavior is truly correct...  As it happens, Chrome happens to "pass" my attached testcase 2 / reference case 2 pair-of-files (as does Firefox release and Firefox Nightly with your patch, I think); but WebKit does not, and I sort of think nobody is correct.

(I say that I think nobody is correct because: theoretically, `position:absolute` content (with default `top/right/bottom/left` properties) is supposed to be positioned at the same spot where it would be, if it didn't have `position:absolute`.  So if you disable/enable `position:absolute` in devtools on the attached "testcase 2", the position should not change, unless there's some writing-mode-specific special case that I'm forgetting about.  In current Nightly, we actually match that expectation of mine **specifically for <audio controls>** due to this bug. :) but we match my expectation for bad/broken reasons and it's inconsistent.)

Alternately: given that our tests' required-behavior is ~debatable, we could just put the tests in our own private reftests directory and not bother anyone else with them (though they may turn up interesting assertions/failures in other browsers, so it's kind-of nice to share them).

Back to Bug 1765654 Comment 6