Open Bug 1680999 Opened 4 years ago Updated 2 years ago

www.bose.com - Instant browser crash

Categories

(Core :: Graphics, defect)

Unspecified
Android
defect

Tracking

()

Webcompat Priority P3
Tracking Status
firefox85 --- affected
firefox93 --- affected
firefox94 --- affected
firefox95 --- affected

People

(Reporter: karlcow, Unassigned)

References

(Depends on 1 open bug, )

Details

Not sure why this is happening.

  1. With Firefox Android Nightly 85
  2. Go to https://www.bose.com/en_us/products/headphones/over_ear_headphones/quietcomfort-35-wireless-ii.html#v=qc35_ii_black

Expected:
Load the page

Actual:
Instant browser crash

I tested on a Pixel 2, with Android 10.

See Also: → 1681001

This looks to be an OOM/ANR from a quick look. I can reproduce on a Pixel 3. A logcat and grabbing the tombstone file if it exists may be useful. https://github.com/mozilla-mobile/fenix/wiki/Logging-Crash-Information#reproducing-the-crash

Component: General → Stability
Product: Core → Fenix
Version: Firefox 85 → unspecified

Yes this is a OOM. Geckoview example crashes in the same manner so this is something in Core. Expect layerization or graphics are the problem here.

Component: Stability → Graphics
Product: Fenix → Core

I loaded the page on OSX Desktop and here's an excerpt from the about:memory report for the Bose process:

463.63 MB (100.0%) -- explicit
├──256.29 MB (55.28%) -- images
│ ├──256.05 MB (55.23%) -- content
│ │ ├──234.36 MB (50.55%) -- vector/used/progress=18f
│ │ │ ├──200.98 MB (43.35%) -- image(1680x2000, https://static.bose.com/etc/designs/bose/base2016/design/images/icons/GD_iconset.svg)
│ │ │ │ ├──175.64 MB (37.88%) -- unlocked/types=2000
│ │ │ │ │ ├───80.11 MB (17.28%) -- surface(4200x5000, svgContext:[ viewport=(2100x2500) ])
│ │ │ │ │ │ ├──80.11 MB (17.28%) ── decoded-nonheap

Maybe there's something similar going on for Fenix.

Blocks: gfx-triage
Flags: needinfo?(jnicol)

The page uses several large SVGs as spritesheets, which causes us to upload a huge amount of texture data.

On my pixel 2 I see images sized at 5479x6521, 5478x6522, 6636x7900, 2003x1878, 1680x2000, and 1962x4759

Bug 1673653 should help. This page seems to be the worst out of all the similar bugs we've seen (see the ones that bug is blocking). So it will be interesting to see how much it helps, and if further work is required afterwards. But in any case that is the first step.

Depends on: deferrable-blobs
Flags: needinfo?(jnicol)

Probably the same as bug 1650436, though I haven't tested the exact URL in that bug report.

See Also: → 1650436
Severity: -- → S3
No longer blocks: gfx-triage

I just encountered this in Firefox beta (88.0) on a PIxel 3.

Oh, and FWIW, it loads fine in chrome on the same device.

Since July 2020, The webcompat team had multiple reports about this.
https://github.com/webcompat/web-bugs/issues?q=is%3Aissue+%22bose+com%22+in%3Atitle

This is still happening in Firefox Android Nightly 95

See Also: → deferrable-blobs

This might be a little less severe because of the improvement of webrender BUT this still needs to be fixed.

The severity field for this bug is set to S3. However, this bug has a P1 WebCompat priority.
:bhood, could you consider increasing the severity of this web compatibility bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bhood)

I just tested this using Android 11 (OnePlus) using FF 100.1.1, and I get no crashing. The referenced page loads and scrolls smoothly.

Could you please verify this with current builds and see if the behavior persists? If not, please consider closing this report.

Flags: needinfo?(bhood) → needinfo?(karl+moz)

It may be that your device is too powerful to reproduce, since it's caused by OOM. Though when I tested previously on a reasonably powerful device it did not crash, but it wasn't smooth either, so perhaps it is indeed fixed.

aosmond's SVG blob work is what we planned would fix this, and I'm not sure what the current status of that is. I think some of it has landed (but perhaps some has been backed out too?)

Are you able to reproduce it with any of your devices, Jamie?

I wouldn't call it smooth, but it it's now usable on a few low end devices I just tested. No worse than Chrome (which also isn't great on these devices) Something has certainly changed for the better, not sure whether in gecko or the website.

The severity field for this bug is relatively low, S3. However, the bug has 5 See Also bugs.
:bhood, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bhood)

This no longer seem to cause any significant WebCompat pain, as mentioned in previous comments. I'll drop the WebCompat priority a lot.

Webcompat Priority: P1 → P3
Flags: needinfo?(karl+moz)
Flags: needinfo?(bhood)
You need to log in before you can comment on or make changes to this bug.