LadybirdBrowser
HTMLTrackElement blocks PNGs to be loaded
Summary
Hi there,
When there's a <track> element on the page, the PNGs on the page don't load. I noticed this on gnu.org homepage.
I strongly suspect this section blocks the PNG loading/rendering:
https://github.com/LadybirdBrowser/ladybird/blob/master/Libraries/LibWeb/HTML/HTMLTrackElement.cpp#L253-L257
Especially the first part of the && in spin_lock and the recursive start_the_track_processing_model_parallel_steps call. When I comment out those, I see both REDUCTION.html and gnu.org homepage loads fine.
Operating system
macOS
Steps to reproduce
- Visit https://www.gnu.org/
- See that the PNGs on the homepage don't load. There are many but you will quickly notice a few on the page header, such as GNU logo.
- Other pages are fine. I noticed this is due to
<track>element.
Expected behavior
The PNGs on https://www.gnu.org/ loads.
Actual behavior
Alt text is shown in places where there are PNG files.
URL for a reduced test case
N/A
HTML/SVG/etc. source for a reduced test case
<!DOCTYPE html> <html><!--
Page saved with SingleFile
url: https://www.gnu.org/
saved date: Wed May 07 2025 09:38:37 GMT+0200 (South Africa Standard Time)
-->
<body>
<img src="https://www.gnu.org/graphics/heckert_gnu.transp.small.png" height="48" width="49" alt=" [A GNU head] ">
<strong>GNU</strong> <span class=hide>Operating System</span>
<br><br>
<video width="512" height="288" controls="controls" crossorigin="anonymous">
<source src="https://static.gnu.org/nosvn/videos/escape-to-freedom/videos/escape-to-freedom-720p.webm" type="video/webm">
<track kind="subtitles" label="English" srclang="en" src="https://static.gnu.org/nosvn/videos/escape-to-freedom/captions/escape-to-freedom_en.vtt" default="default">
</video>
</body>
</html>
Log output and (if possible) backtrace
N/A
Screenshots or screen recordings
No response
Build flags or config settings
No response
Contribute a patch?
- [x] I’ll contribute a patch for this myself.
I marked I'll contribute a patch for this myself, but since I got stuck, I may need help. I am also happy if someone else picks up, so I can learn how to go about similar issues in the future. Ty ^-^
@sepeth @ADKaster @lypanov @seven1m @phsilva We have already fixed this issue (#4653) and we believe we can get most of your remaining issued fixed. Currently, we charge 1,000 USD / issue, and we can fix one issue within 24 hours. Please contact us via WhatsApp +86 13581705763, or by email [email protected]
@galoisgroupcn refrain from advertising your business in our bug tracker. I doubt that such behavior is on the up and up with the GitHub TOS.
bulk distribution of promotions and advertising prohibited by GitHub terms and policies;
You may not advertise in other Users' Accounts, such as by posting monetized or excessive bulk content in issues.
@sepeth @ADKaster @lypanov @seven1m
I'll do it for free this time. Check if we actually fix it.
Upon review, the problematic section is at the end of HTMLTrackElement::start_the_track_processing_model_parallel_steps, which recursively calls itself unconditionally (step 13: start_the_track_processing_model_parallel_steps(realm);). This causes perpetual event loop spinning and starves out other event loop tasks, including image loading and rendering, hence PNGs fail to load. According to the HTML spec, the "jump to top" should only occur if the readiness state is still "loading" or the track URL has changed, not unconditionally.
The correct fix is to only repeat the algorithm if one of the "wait" conditions actually changed. That is: after spinning for readiness state and track URL, only jump to the top if something changed that requires repeating, otherwise return. This avoids event loop starvation and unblocks PNGs.
I will update the function to only repeat if the relevant state really changed and otherwise exit.
Here's the pull requests: https://github.com/galoisgroupcn/ladybird/pull/1/commits/dc8590a061b3ce0b53208a41776c9160383b166b
@galoisgroupcn That so obviously does not fix the issue. We are not interested in your business, stop spamming our issue tracker.
