wpt subtest [default object size after poster is removed] in /html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm no longer also reports failure in other browsers
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox115 | --- | fixed |
People
(Reporter: wpt-sync, Assigned: karlt)
References
Details
(Whiteboard: [wpt])
Attachments
(1 file)
Syncing wpt PR 38995 found new untriaged test failures in CI
Tests Affected
Firefox-only failures
- /html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm [wpt.fyi]
- default object size after poster is removed:
FAIL
- default object size after poster is removed:
CI Results
Missing results from treeherder
GitHub PR Head
Notes
These updates will be on mozilla-central once bug 1822382 lands.
Note: this bug is for tracking fixing the issues and is not
owned by the wpt sync bot.
This bug is linked to the relevant tests by an annotation in
https://github.com/web-platform-tests/wpt-metadata. These annotations
can be edited using the wpt interop dashboard
https://jgraham.github.io/wptdash/
If this bug is split into multiple bugs, please also update the
annotations, otherwise we are unable to track which wpt issues are
already triaged. Resolving as duplicate or closing this issue should
be cause the bot to automatically update or remove the annotation.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 1•2 years ago
|
||
https://wpt.live/html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm
'default object size after src is removed'
'default object size after poster is removed'
Would video playback logic control element dimensions after a video stops playing or a poster is removed? These test failures really seem to be related to DOM vs. video playback. Happy to have playback engineer look at it but I'm not sure we're the right people to investigate.
Comment 2•2 years ago
•
|
||
(In reply to Jim Mathies [:jimm] from comment #1)
https://wpt.live/html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm
'default object size after src is removed'
'default object size after poster is removed'Would video playback logic control element dimensions after a video stops playing or a poster is removed? These test failures really seem to be related to DOM vs. video playback. Happy to have playback engineer look at it but I'm not sure we're the right people to investigate.
I moved the bug to " Audio/Video: Playback" according to the component description "for problems related to the HTML 5 media elements (<video> and <audio>)", though I have to admit that I am not sure where these two sub-tests are handled in the code. However, in general our team won't have bandwidth looking at media elements issues or HTMLVideoElement.* files, and we're not following there. Therefore, it's ideal for me that media elements experts can triage and analyze this further, narrow down the root cause, and then if it reveals a problem that requires a generic DOM implementation fix, we're happy to take another look. Does that make sense? Happy to have slack discussion if that helps. :)
Comment 3•2 years ago
|
||
Karl, you have some experience working with media elements. Can you take a look here see if there's something we can do?
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
(In reply to Web Platform Test Sync Bot (Matrix: #interop:mozilla.org) from comment #0)
Syncing wpt PR 38995 found new untriaged test failures in CI
Tests Affected
Firefox-only failures
- /html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm [wpt.fyi]
- default object size after poster is removed:
FAIL
This subtest has been failing in Firefox since the initial version of the test in 2018, but the changes in bug 1822382 likely mean that it is now passing in other browsers.
Assignee | ||
Comment 5•2 years ago
|
||
nsVideoFrame::CreateAnonymousContent()
forces image element state to neither BROKEN nor LOADING to avoid reframes of the nsImageFrame
, but nsImageFrame
depends on BROKEN element state changes to clear out a previous image. Without this, the necessary reflow is not triggered and the nsImageFrame
holds onto the image unnecessarily.
Changes in the LOADING state no longer reframe since https://hg.mozilla.org/integration/autoland/rev/3f1e9dae2467
and changes in the BROKEN state don't necessarily reframe since https://hg.mozilla.org/mozilla-central/rev/3f26214c64a46e20926bdb4ed277ab57b0d2bd61
Assignee | ||
Comment 6•2 years ago
|
||
so that the nsImageFrame can release a previous image and trigger reflow on
BROKEN state change when src is removed.
Updated•2 years ago
|
Comment 8•2 years ago
|
||
bugherder |
Description
•