1896071 - huggingface.co -Phi-3 WebGPU - Page stuck in loading

Status: REOPENED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Andreea Zlata]

Tested on:
• Browser / Version: Firefox Nightly 127.0a1 (2024-05-09) / Firefox Release 125.0.3 / Chrome 124.0.6367.202
• Operating System: Mac OS

Steps to reproduce:

1. Enable webgpu from about:config
2. Navigate to: https://huggingface.co/spaces/Xenova/experimental-phi3-webgpu
3. Click on "Load mode!" button.
4. Observe the page.

Expected Behavior:
The chat should be displayed.

Actual Behavior:
The page is stuck in loading.

Notes:

• Reproducible on both Firefox Release and Nightly
• Not reproducible on Chrome.
• Reproducible regardless of settings of Enhanced Tracking Protection

Created from https://github.com/webcompat/web-bugs/issues/136839

Comment 1

[Andreea Zlata]

Attachment: 20240510_120022.mp4

Comment 2

[Maire Reavy [:mreavy]]

James -- WebGPU on mac isn't shipping yet, but this should be a blocker to ship. What should we do with this bug? Should we create a clone of this in Graphics and close this bug? Or just move it to Graphics?

Comment 3

[James Graham [:jgraham]]

I remember we had a discussion about this one at the time; it's not entirely clear in the process how to handle site breakage for that are not yet shipping but are expected to ship (compare with bugs that depend on e.g. privacy.resistFingerprinting which is unlikely to ever ship by default). We could mark them as configuration:rare but then we'd need a process to make sure the issues are re-triaged once the feature is ready to ride the trains. So marking them as configuration: general is the conservative and simple option, but it does mean we're overestimating the impact.

I think what probably makes sense in this case, and cases like it, is to mark the bug as webcompat:platform-bug depending on the feature bug (either a general meta, or a ship-by-default bug), and then assume that the team working on the feature will do whatever work (including diagnosis) is required to fix the issue before enabling the feature. That bug itself should also be marked as webcompat:platform-bug since it's implicated as the root cause of some breakage.

For WebGPU in particular I'm not sure which bug to block, but I found the triage list bug, and I hope someone from the graphics team can suggest which other bug would be best to use as the tracker for site issues that occur when WebGPU is enabled (or, even better, to figure out which specific WebGPU bug is causing the breakage identified here, and link it to that one).

Erich: are you the right person to ask about which WebGPU bug we should block this on?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Downgrading to P2 because we're not shipping WebGPU yet.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

This page is using onnxruntime. I suspect it can be reproduced with a standalone example.

Comment 6

[Erich Gubler [:ErichDonGubler] (he/him)]

:jgraham: I am a valid person to ask, yes! WebGPU on MacOS is currently not projected to be shipped this year. Therefore, I am downgrading the priority and severity to match our current triage guidelines.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Erich, does it work on Windows?

Comment 8

[James Graham [:jgraham]]

WebGPU on MacOS is currently not projected to be shipped this year.

Note that although this was originally reported on macOS, and that gets recorded in the report data, we don't have any reason to believe that it's mac-specific.

Also, moving this into a core component somewhat breaks the WebCompat bug workflow; we end up thinking that this bug is a root cause of webcompat breakage (because it's marked as webcompat:platform-bug) but that the breakage doesn't have any real world impact (because it doesn't block any Site Report bugs). That might be sort-of OK for this case because it's not a shipping feature, and we are working on it as fast as possible, but it does mean that we lose track of the webcompat impact of WebGPU in general. I think a better plan that would work for our workflow would be to move the dependencies of webgpu-apps corresponding to user-visible site breakage into the Site Reports component and triage them as site reports.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

This site doesn't work for me on Windows either. I get the same Unsupported device: "webgpu". Should be one of: wasm"

Comment 10

[Erich Gubler [:ErichDonGubler] (he/him)]

:jrmuizel: That is also what happens for me on my Windows machine.

Comment 11

[Erich Gubler [:ErichDonGubler] (he/him)]

:jgraham: I'm actually unfamiliar with WebCompat issue tracking. So, it's highly likely I may be misstepping WRT components classification. I definitely am open to being taught what's desired from our bug workflow here. 🙏🏻

Comment 12

[James Graham [:jgraham]]

I'm actually unfamiliar with WebCompat issue tracking.

Well it's changing a bit and some details are still being worked out :)

The main thing is that when we're scoring the compat impact of various core bugs we are currently only using bugs in the Web Compatibility :: Site Reports component as input. There's some documentation at https://docs.google.com/document/d/1u1QqTJgXhPLMdKuTpEQuCB_rSlnauWLO9Siw9Jvhbz0

If this turns out to be too much of a burden process wise we'll of course need to find a way to improve it, but for now I'm going to move this back into the site reports component.

Comment 13

[Erich Gubler [:ErichDonGubler] (he/him)]

With workers enabled via dom.webgpu.workers.enabled, the only easily identifiable blocker is bug 1829879:

WebGPU compilation info for shader module "MatMulNBits" (1 error(s), 0 warning(s), 0 info)

Shader validation error: Entry point main at Compute is invalid
   ┌─ MatMulNBits:73:13
   │
73 │             col_index += 1;
   │             ^^^^^^^^^^^^^^ naga::Expression [39]
   │
   = Expression [39] is invalid
   = Operation Add can't work with [38] (of type Scalar(Scalar { kind: Uint, width: 4 })) and [37] (of type Scalar(Scalar { kind: Sint, width: 4 }))

WebGPU compilation info for shader module "MatMulNBits" (1 error(s), 0 warning(s), 0 info)

Shader validation error: Entry point main at Compute is invalid
   ┌─ MatMulNBits:73:13
   │
73 │             col_index += 1;
   │             ^^^^^^^^^^^^^^ naga::Expression [39]
   │
   = Expression [39] is invalid
   = Operation Add can't work with [38] (of type Scalar(Scalar { kind: Uint, width: 4 })) and [37] (of type Scalar(Scalar { kind: Sint, width: 4 }))

Comment 14

[Erich Gubler [:ErichDonGubler] (he/him)]

Now that bug 1938659 is done (which is the portion of webgpu-workers that the page needed), the only remaining apparent blocker is, as before, bug 1829879:

WebGPU compilation info for shader module "MatMulNBits" (1 error(s), 0 warning(s), 0 info)

Shader validation error: Entry point main at Compute is invalid
   ┌─ MatMulNBits:73:13
   │
73 │             col_index += 1;
   │             ^^^^^^^^^^^^^^ naga::Expression [39]
   │
   = Expression [39] is invalid
   = Operation Add can't work with [38] (of type Scalar(Scalar { kind: Uint, width: 4 })) and [37] (of type Scalar(Scalar { kind: Sint, width: 4 }))

WebGPU compilation info for shader module "RotaryEmbedding" (1 error(s), 0 warning(s), 0 info)

Shader validation error: Entry point main at Compute is invalid
   ┌─ RotaryEmbedding:57:62
   │
57 │                 u32(i32(position_ids[position_ids_idx].x)) + select(0, bsnh[1], position_ids_idx == 0);
   │                                                              ^^^^^^ naga::Expression [43]
   │
   = Expression [43] is invalid
   = Expected selection argument types to match, but reject value of type Scalar(Scalar { kind: Sint, width: 4 }) does not match accept value of value Scalar(Scalar { kind: Uint, width: 4 })

Comment 15

[Erich Gubler [:ErichDonGubler] (he/him)]

I'm not sure that there's a WebGPU issue with this any more. I see the following console error now when I attempt to load this page:

TypeError: A float16 tensor's data must be type of function Float16Array() {
    [native code]
}

Comment 16

[Calin Tanase]

Retriaged, the issue no longer reproduces on the latest Nightly.

Tested with:

Browser / Version: Firefox Nightly 139.0a1 (2025-04-24)
Operating System: Windows 10/MacOS

Comment 17

[Stefan Fleiter (:sfleiter)]

For me this stops at Compiling shaders and warming up model... state and I also see the error mentioned in comment #15 with Firefox 139.0a1 (2025-04-24) (aarch64).
Does not look fixed to me.

Comment 18

[Erich Gubler [:ErichDonGubler] (he/him)]

The scope of this bug is the broken-ness of Firefox's WebGPU implementation; this appears to be resolved, particularly because the same error I noted in comment #15 happens in Chrome Beta. Breakages now seem to be due to incorrect application code, not Firefox's implementation of WebGPU.

Comment 19

[railioaie]

Verified as Reproducible using the RC Build

Tested with:

Browser / Version: Firefox 139.0-candidate build 1
Operating System: Mac Sequoia 15.5

Comment 20

[railioaie]

Attachment: Screenshot_305.png

Comment 21

[Erich Gubler [:ErichDonGubler] (he/him)]

This shouldn't be something we expect to work in RC or Stable yet; we only ship to early Beta right now.

Comment 22

[Calin Tanase]

@ErichDonGubler is there a target milestone for this? The issue keeps appearing in our RC verification list and its still reproducible with RC and Beta.

Comment 23

[Erich Gubler [:ErichDonGubler] (he/him)]

This should be resolved in Windows up to 141 and Nightly on all other platforms. Does that help?

Comment 24

[James Graham [:jgraham]]

This shouldn't have been marked fixed, since the site is still broken for end users. Once 141 for Windows is released it should be verified there and the bug updated so that it's only marked as affecting other platforms. It should also be marked as blocked on the bugs to ship to other platforms.

Comment 25

[Calin Tanase]

It works with Beta and RC 141 on Windows 10 but on MacOS works only on Nightly, it's still reproducible with Beta and RC 141.

Comment 26

[Calin Tanase]

Retriaged, works on Windows and Linux even on Release 141 now. On Mac works only on Nightly and Beta, still reproducible on Release. Should we close it as fixed, is it expected to ship on Mac on the RC 142 build?

Comment 27

[Erich Gubler [:ErichDonGubler] (he/him)]

(In reply to Calin Tanase from comment #26)

Retriaged, works on Windows and Linux even on Release 141 now.

Linux should not be shipping WebGPU yet. Can you confirm that the issue is resolved, and that the page is not running WebGPU, please?

On Mac works only on Nightly and Beta, still reproducible on Release. Should we close it as fixed, is it expected to ship on Mac on the RC 142 build?

This is expected, and what I was assuming would happen with Linux. WebGPU for macOS should ship soon, but not yet.

Comment 28

[Calin Tanase]

Checked again, it actually reproduces on Release on Linux.

Comment 29

[Raul Bucata]

Same observations as Calin discovered.

Comment 30

[Calin Tanase]

Still reproducible on Release (v145) on Mac.

Comment 31

[Raul Bucata]

This is still an issue, once everything is downloaded, you are stuck with "Compiling shaders and warming up model..." message, as per comment 17

Tested with:

Browser / Version: Firefox Nightly 158.0a1 (2026-09-14) (64-bit)
Operating System: Windows 10 PRO x64