Closed Bug 1822404 Opened 2 years ago Closed 2 years ago

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)

defect

Tracking

()

RESOLVED FIXED
115 Branch
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

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.

Component: DOM: Core & HTML → Audio/Video: Playback
Blocks: media-triage
Severity: -- → S4

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.

Flags: needinfo?(htsai)

(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. :)

Flags: needinfo?(htsai)

Karl, you have some experience working with media elements. Can you take a look here see if there's something we can do?

Flags: needinfo?(karlt)
See Also: → 1825454
No longer blocks: media-triage

(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

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.

Flags: needinfo?(karlt)
Summary: New wpt failures in /html/semantics/embedded-content/the-video-element/intrinsic_sizes.htm → 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

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: nobody → karlt
Blocks: 449156
Status: NEW → ASSIGNED

so that the nsImageFrame can release a previous image and trigger reflow on
BROKEN state change when src is removed.

Attachment #9332144 - Attachment description: Bug 1822404 don't force image state for poster anonymous img r?emilio → Bug 1822404 don't force image state for poster anonymous img r=emilio
Pushed by ktomlinson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/999b5e7f86dc don't force image state for poster anonymous img r=emilio
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: