Open Bug 1958495 Opened 19 days ago Updated 14 days ago

Tab crash after opening AnimeJS documentation in a new background tab from a different website

Categories

(Core :: JavaScript Engine, defect, P3)

Firefox 137
defect

Tracking

()

People

(Reporter: gacelperfinian, Assigned: allstars.chh)

References

(Blocks 2 open bugs)

Details

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

  1. Access this comment (https://news.ycombinator.com/item?id=43575905) which contains a link to an AnimeJS documentation (https://animejs.com/documentation/scope/)
  2. Open the link in the background on a new tab (by middle-clicking or using the right-click menu)
  3. Wait for the tab to finish loading (as indicated in the tab) and wait a few more seconds until the cursor has changed into a loading state (specifically called "Working in Background") and then returned to the default cursor
  4. Open the new tab

Actual results:

The tab crashed with the crash reporter shown instead of showing the documentation.

Expected results:

The tab loads normally in the background, like in Chrome version 135.0.7049.42.

The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Tabbed Browser
Component: Tabbed Browser → Site Reports
Product: Firefox → Web Compatibility

Gacel, can you please submit a crash report, then go to about:crashes, click "View" on the latest report, and share the link here?

Component: Site Reports → General
Flags: needinfo?(gacelperfinian)
Product: Web Compatibility → Firefox

(In reply to Dennis Schubert [:denschub] from comment #2)

Gacel, can you please submit a crash report, then go to about:crashes, click "View" on the latest report, and share the link here?

Flags: needinfo?(gacelperfinian)

Both reports point to bug 1849115, which indeed do spike a bit in the last couple of days. Moving this into the right component instead of just closing as a duplicate, in case we can get more info here.

Component: General → JavaScript Engine
Product: Firefox → Core

(In reply to Dennis Schubert [:denschub] from comment #4)

Both reports point to bug 1849115, which indeed do spike a bit in the last couple of days. Moving this into the right component instead of just closing as a duplicate, in case we can get more info here.

I was just able to repro'd this on Fenix Beta: https://crash-stats.mozilla.org/report/index/c2aad9f5-8a32-45ff-974d-a1b860250407

I am not sure what exactly triggers the crash, but some notes on the crash:

  • The documentation page uses WebGL heavily as a self-demonstration. This may be relevant to the second point.
  • The crash seems to trigger only if the page is loaded in the background (at least on my testing).
  • Sometimes the page loads appropriately even if it was loaded on background. I do not have precise numbers, but it seems that a crash is slightly less likely than a normal background load.
See Also: → 1849115

So, yesterday one of us could reproduce, but today we're having trouble. I'm wondering if they updated their site in a way that unbroke this. Gacel, can you still reproduce?

Severity: -- → S3
Flags: needinfo?(gacelperfinian)
Priority: -- → P3

Yoshi: looking at the stack does anything stand out that gives you a hypothesis? Apparently it was easy to reproduce yesterday. One possibility might be to email the author (https://github.com/juliangarnier) and see if he changed the docs site, and if we could get a test-deploy of the version from a couple of days ago to see if we can reproduce this crasher.

Flags: needinfo?(allstars.chh)

I can repro.
STR:

  1. Install and enable uBlock Origins
  2. Go to https://animejs.com/documentation/scope/
  3. ensure that ublock is enabled on the page (it should be, by default)
  4. Disable uBLock for the page by clicking on the ublock icon in the toolbar, and clicking on the big blue "power" button
  5. Reload the page by clicking on the reload button on the ublock icon
  6. Once the page reloads, enable ublock by clicking on the bug grey "power" button.
  7. Reload the page by clicking on the "reload" button in ublock

AR: crash
https://crash-stats.mozilla.org/report/index/cecdbc4e-a3f4-4a68-b1a1-ebb8e0250408#tab-bugzilla

Status: UNCONFIRMED → NEW
Crash Signature: [@ JS::Heap<T>::exposeToActiveJS ]
Ever confirmed: true

and i dont repro now
It repros intermittently... maybe it needs a browser restart each time you want to repro?

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #6)

So, yesterday one of us could reproduce, but today we're having trouble. I'm wondering if they updated their site in a way that unbroke this. Gacel, can you still reproduce?

I cannot reproduce today, but it seems that's because there was a fix deployed. It is still concerning, considering that a webpage shouldn't crash Firefox.

(In reply to Mayank Bansal from comment #8)

I can repro.
STR:

  1. Install and enable uBlock Origins

As shown in one of the crashdumps, this is reproducible in a clean browser.

Flags: needinfo?(gacelperfinian)

(In reply to Gacel Perfinian from comment #10)

I cannot reproduce today, but it seems that's because there was a fix deployed. It is still concerning, considering that a webpage shouldn't crash Firefox.

I had forgot to link to the website repo (which is also open source): https://github.com/juliangarnier/anime/commits/gh-pages/

THANK YOU.

With some work, I managed to redeploy the broken version and reproduced a crash.

https://mgaudet.github.io/anime-repro/documentation/scope/register-method-function crashes nicely for me on my current (slightly out of date) nightly, Built from https://hg.mozilla.org/mozilla-central/rev/242368641aa14af858be17a439854ca4bd19afc9 according to about:buildconfig

I'm building a debug linux browser now to hopefully be able to grab this in pernosco .

Ok, unfortunately I cannot reproduce in a local build of that revision on Linux. I'll let Yoshi take the next look; hopefully having a reproducer will be sufficient to get this fixed.

I have tried a few times but have not been able to reproduce that, I'll take the bug first.

Assignee: nobody → allstars.chh
Flags: needinfo?(allstars.chh)

This bug seems rather elusive on Linux, but I successfully triggered it once if it helps (although this is not as helpful as running it under rr): https://crash-stats.mozilla.org/report/index/99158a31-7d22-4ec6-81c5-2558d0250409

It's helpful that you were at least -able- to get it to fail on linux. Makes me wonder if I should try scripting this.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: